Quel pattern pour un view controller avec un mode édition
Bonjour,
Je tourne un peu en rond car je n'arrive pas à trouver le meilleur pattern pour faire un view controller qui propose un mode édition et qui peut être affiché modalement ou via un push de navigation controller. Typiquement si on prend le fiche contact de l'application Contacts :
- quel viewcontroller serait responsable de créer un context spécifique pour l'édition, le view controller Contact ou le view controller qui le crée ?
- quel viewcontroller serait responsable de sauver ou libérer le context pour l'édition ? Le même que la question ci-dessus j'imagine.
- quel viewcontroller serait responsable de configurer les boutons dans la barre de navigation ?
- du coup quel serait l'interface publique du view controller Contact ?
J'espère que ma question n'est pas trop floue.
Je vous remercie d'avance,
Quentin
Réponses
Je crois que ça dépend de l'application. Dans mon cas précis, j'ai rapidement exclu d'utiliser plusieurs classes parce que je n'avais pas deux modes, mais quatre. Je n'allais clairement pas créer 4 classes qui auraient eu beaucoup de code redondant, que j'aurais certes pu factoriser.
La solution pour moi fut de transférer une grosse partie de la logique dans les cellules, auxquelles j'ai ajouté une propriété "éditable" et qui changeaient leur apparence selon.
Si tu n'as que deux modes, je pense que cette solution se discute beaucoup... avec deux classes, le code est plus simple.
Pour ce qui est de la gestion de la barre de navigation, etc., c'est du ressort du view controller de consultation/édition. C'est lui qui sait le mieux quels boutons doivent s'afficher et dans quel état. Il communiquera son résultat à son view controller parent par l'habituelle délégation.
La raison en est simple : Principe d'encapsulation et réduire les interdépendances des classes.
Merci pour vos retours. Du coup, suite à un petit refactoring j'arrive à une classe QAContactViewController qui fonctionne selon 3 modes : consultation, édition et création. Ces modes sont définis selon l'appel à une des trois méthodes ci-dessous :
via la propriété "managedObjectContext" du NSManagedObject) ?
D'autant qu'en faisant ainsi ton API n'est pas claire, tu ne dis pas à quelle entité doit correspondre ton ID, et en + tu peux finir par passer n'importe quoi en paramètre (genre des choses pas consistantes entre elles)
Comme ça dans ton ViewController parent, tu n'as pas besoin de te poser la question de quel contexte je dois passer, savoir à quoi correspond le NSManagedObjectID que je dois passer, etc... Tu n'as pas non plus à créer le contexte fils dans le VC appelant/parent. Non, rien de tout ça.
Si ton VC parent par exemple c'est un UITableViewController qui liste tes contacts, bah dans le "tableView:didSelectRowAtIndexPath:" tu récupères le contact de la même manière que tu le récupères dans ton "tableView:cellForRowAtIndexPath:" pour remplir ta cellule... et tu passes ce contact (NSManagedObject) directement au EditViewController. Sans autre forme de procès (sans avoir à le convertir en NSManagedObjectID d'un côté, à passer un MOC de l'autre en 2ème paramètre, ni à créer un contexte fils toi-même ni quoi que ce soit).
Tu récupères le NSManagedObject* contact de ton NSArray ou autre qui te sert de dataSource (ou de ton NSFetchedResultsController par exemple) comme tu le fais pour "cellForRowAtIndexPath:", tu instancies ton EditViewController, et tu appelles "editContact:" dessus en lui passant ce contact en paramètre. Point barre.