2009-12-01 4 views
2

J'essaie de trouver la bonne façon d'utiliser NSManagedObjectContexts lorsque vous visualisez, modifiez et créez des NSManagedObjects. Je pense que la documentation et les exemples ont expliqué comment les utiliser dans les cas les plus basiques, mais je ne suis pas sûr de savoir quelles sont les méthodes appropriées dans une configuration un peu plus complexe.Quelle est la bonne utilisation de NSManagedObjectContexts lors de la modification/création de nouveaux objets (iPhone)?

La configuration:

  • 3 écrans principaux: une liste d'objets, un écran d'objets d'édition, et un nouvel écran d'objet.
  • Un autre thread consiste à télécharger des objets à ajouter à la liste en arrière-plan.

Les exigences:

  • L'écran de liste utilise un MOC et un NSFetchedResultsController pour obtenir toutes ses objets.
  • Les écrans d'édition et de nouvel objet utilisent des MOC pour enregistrer/supprimer des objets ET utilisent NSFetchedResultsControllers pour les relations.
  • Les objets téléchargés nécessitent un MOC pour enregistrer ses objets dans les données de base (sur le thread principal).

Les questions:

  • Combien de MOCs ai-je besoin?
  • Comment dois-je manipuler ces MOC?

Réponses possibles:

  • l'avez MOC "View" qui n'a jamais été modifié et est utilisé dans l'écran de liste. Utilisez des MOC distincts pour l'édition, les nouveaux écrans d'objet et les téléchargements. Lorsque ces MOCs enregistrent, fusionnez les modifications au MOC "View". De cette façon, les modifications n'affectent pas le MOC "View" tant qu'elles ne sont pas sauvegardées. C'est ce que j'ai fait. il ne semble pas fonctionner aussi bien que je l'espérais. Il y a une déconnexion entre l'édition et la visualisation et au lieu d'être capable de vérifier les choses quand je sais qu'elles peuvent être modifiées, je dois attendre que les méthodes du délégué NSFetchedResultsController soient terminées et vérifier toutes les choses qui auraient pu changer. Cela rend également difficile la modification de certaines données dans la vue de liste.

  • Avoir un MOC pour tout. C'est ce que j'ai d'abord essayé, mais je ne savais pas comment gérer l'édition et la création. Maintenant que je comprends un peu plus, je suppose que je pourrais juste éditer l'objet ou créer un objet et rollBack sur annuler. Sur cimgf, j'ai vu un post qui semblait similaire qui disait de créer un undoGrouping autour de l'edit/create et undo lors de l'annulation. Ensuite, je suppose que je pourrais utiliser un MOC séparé sur les objets téléchargés car il pourrait finir et enregistrer pendant que l'utilisateur édite dans le MOC principal.

  • De toute façon, le fait est que je ne connais pas la méthode appropriée. Pouvez-vous m'aider?

Exemple Disconnect pour première réponse possible

  1. Création d'un objet (1) dans l'édition moc. Enregistré. Fusionné avec view moc par notification.
  2. Créé un nouveau moc car je télécharge des objets en arrière-plan. Mise à jour de certains objets liés à (1). Enregistré. Fusionné avec view moc par notification.
  3. Modifier (1) dans le champ d'édition. Enregistré. Fusionné avec view moc par notification.
  4. PROBLEME: Comme le moc d'édition n'a jamais été modifié par le nouveau moc, lorsqu'il l'enregistre, il supprime tous les nouveaux changements moc qu'il affecte.
  5. SOLUTION: Je me rends compte que je pourrais également fusionner les changements au moc d'édition ou utiliser toujours un nouveau moc pour éditer des choses. Cependant, je continue à courir dans de petites choses comme ça et à devoir trouver des solutions, alors ça me laisse croire que ce n'est pas la meilleure réponse.

Répondre

2

Vous devez avoir au moins un MOC par thread (ils ne sont pas thread-safe). Vous pouvez donc avoir un MOC pour le téléchargeur (dans le thread d'arrière-plan) et un autre pour l'activité dans la liste principale des threads, modifier et nouveau.

Lorsque vous dites qu'il y a une déconnexion, pouvez-vous être plus précis? Utilisez-vous des notifications (NSManagedObjectContextDidSaveNotification) et faites mergeChangesFromContextDidSaveNotification lorsque vous recevez cette notification. Rappelez-vous, que mergeChangesFromContextDidSaveNotification devrait être effectuée sur le thread principal.

Dans votre contrôleur de vue avec NSFectchedResultsController gérez-vous correctement tous les cas de NSFetchedResultsControllerDelegate?

+0

Merci de répondre. Oui, j'utilise des notifications pour mettre à jour la vue moc dans le fil principal. Oui, je gère correctement les cas NSFetchedResultsControllerDelegate. J'ai ajouté un exemple de déconnexion à la question. Jusqu'à présent, cela semble être la meilleure solution: - Utilisez 1 moc pour autant que vous le pouvez. - Si vous ne pouvez pas utiliser le moc principal, créez-en un nouveau * à chaque fois * vous avez besoin de changer quelque chose pour éviter d'économiser sur les modifications effectuées ailleurs. Ou fusionner les changements à ce moc aussi bien si vous le pouvez. - Tous les mocs autres que le principal doivent fusionner les changements au principal. Est-ce ce que vous avez trouvé? – jasongregori

+0

Quelque chose comme ça. J'avais un moc principal qui était utilisé par le NSFetchedResultController. L'activité d'arrière-plan (empaquetée dans NSOperations) avait son propre moc. Toutes les modifications apportées à ces moc ont été transmises à l'aide de notifications au moc principal et fusionnées. Donc, essentiellement, le principal moc était en lecture seule. Ce truc est délicat et il a fallu du temps pour le faire correctement. Beaucoup d'essais et d'erreurs. – lyonanderson

Questions connexes