Modèle de conception pour l'application Core Data pour iPhone

Question

Je suis en train de créer une application qui utilisera un modèle Core Data. Je suis assez nouveau pour Objective C et mes modèles de conception habituels ne s’appliquent pas vraiment aux données de base et à Objective C, du moins je ne trouve pas d’exemples qui confirment leur intention.

J'ai consulté les exemples de développeurs Apple et différentes sources sur les intertubes.

Il semble que pour exploiter les données de base, je dois passer le managedObjectContext à chacun de mes viewControllers, demander à viewController de mettre en œuvre NSFetchedResultsControllerDelegate, puis de mettre en œuvre chacune des méthodes permettant d'effectuer une extraction, puis de mettre en œuvre

NSFetchedResultsChangeInsert

NSFetchedResultsChangeDelete  NSFetchedResultsChangeMove  NSFetchedResultsChangeUpdate

Ceci ajoute environ 100 lignes de code dans chaque viewController et correspond à 90% au même code que celui que j'écris encore et encore. De plus, je dois tout transmettre et garder une trace de son empreinte mémoire.

Dans d’autres langues, je construisais un modèle singleton de quelques classes contenant des méthodes de maintenance et de fourniture de données sur demande, disponibles à partir de n’importe où. Il semble que je ne puisse pas adopter cette approche dans l’objectif C. Si je construisais une classe statique qui prenait un managedObjectContext et me renvoyait ce dont j'avais besoin, je devrais quand même faire passer le managedObjectContext à chaque vue et ce ne serait pas le cas. de manière asynchrone, comme lorsque j'implémente des méthodes de délégation qui sont simplement appelées lorsqu'un résultat est prêt.

J'espère que cela a du sens et que quelqu'un peut soit confirmer qu'il n'y a pas d'autre moyen raisonnable de le faire, soit m'aider à me guider dans la bonne direction pour clore ceci d'une manière satisfaisante.

Merci :))

Answer 1

Les données de base ne sont pas aussi compliquées que vous le décrivez.

En règle générale, une application iPhone possède un "principal". contexte d'objet géré, qui appartient généralement au délégué de l'application. Tant que vous pouvez obtenir le délégué de l'application (conseil: [délégué [UIApplication sharedApplication]]] ), vous avez accès au contexte de l'objet géré. J'aime définir une variable globale statique pour contenir une référence à mon délégué d'application afin de vous simplifier la vie.

Il existe généralement une correspondance un à un entre les instances NSFetchedResultsController et les instances UITableView . Outre le remplissage des vues de table, il est extrêmement rare que vous ayez besoin d'un NSFetchedResultsController . Si vous disposez d'un certain nombre de vues similaires (par exemple, une barre d'onglets vous permettant d'afficher les mêmes données de différentes manières par rapport à l'application iPod), il vous incombera de créer une classe de base unique configurant le NSFetchedResultsController et dérivez vos contrôleurs de vue spécifiques.

Désormais, lorsque vous créez des contrôleurs de vue pour éditer un objet, il est généralement conseillé de le faire dans un contexte d'objet géré distinct. Si l'utilisateur annule, vous supprimez simplement le contexte et les modifications disparaissent. Encore une fois, vous n'avez pas vraiment besoin d'un NSFetchedResultsController pour cela car ces vues ne concernent qu'un seul objet.

Une fois vos modifications terminées, vous enregistrez: le contexte de l'objet géré. Les objets qui gèrent vos autres contextes d'objet géré doivent implémenter les méthodes NSFetchedResultsControllerDelegate afin de maintenir la vue tabulaire synchronisée. Là encore, cela peut être implémenté dans une classe de base afin que vous puissiez généraliser cette fonctionnalité pour les contrôleurs de vue associés.

Answer 2

Devez-vous absolument utiliser un modèle CoreData ou un système utilisant NSCoder (NSArchiver, NSKeyedArchiver, etc.) fonctionnerait-il? J'ai constaté que CoreData était excessif pour la plupart des applications.

Aussi, pourriez-vous préciser pourquoi vous ne pouvez pas adopter une approche utilisant des singletons? J'ai utilisé des usines singleton dans un certain nombre d'applications sans problèmes. Il est assez facile de définir des méthodes au niveau classe qui fonctionnent sur une instance partagée (singleton).