Recipes to pass NSManagedObjects amongs UIViewControllers

Question

Within an application it's possible to have different UIViewControllers that need to share the same NSManagedObject. I'm usually do the following:

@interface CustomController : UIViewController

@property (nonatomic, retain) ProductNSManagedObject* productManaged;

@end

Then when I istantiate CustomController I inject it like the following:

customController.productManaged = ....

once done, CustomController is responsible to release it.

This approach works well (I don't know if is it correct), but what to do when a controller need that object but it's not a direct child of the controller that has that object? e.g.

MainController -> ChildController -> SubChildController -> ....

where MainController has the managed object.

Do I have to create a lot of intermediary properties or do I need to execute a fresh NSFetchRequest or something else?

The same aspect could be applied to the NSManagedObjectContext. Searching around I've found that the context can be grabbed from the application delegate that posseses it (if any). But this approach lacks of flexibility as Marcus Zarra wrote in passing-around-a-nsmanagedobjectcontext-on-the-iphone.

Any suggestions? Thank you in advance.

Answer 1

I create a singleton object that contains the managed object context that will be used throughout the application. I put any supporting code related to the data (e.g., persistent store coordinator) inside this singleton and keep all of the view and controller information separated from it.

In one case, I need a managed object context for another thread. It became apparent that it would be useful to refactor and put that context inside the same singleton. Then merging between the two contexts can be done inside the singleton.

This has helped me manage my code. You might consider it.

Answer 2

This is a very common question (see here and here for related ones). As I wrote in the answers for the related questions, you should stay away from singletons and create a separate object that will take care of object instantiation, of creating the object graph for your application. This separate object can hold references to all shared objects and supply them to the objects being built, so that none of your regular objects has to keep a reference to something just to pass it as a dependency to other objects. See this blog post for more rationale against singleton misuse and for further pointers, especially the articles by Miško Hevery.

I have created a sample Xcode project that shows how to wire an app without singletons, keeping the coupling low and resolving other singleton issues. It’s very simple at the moment, I will add more common use cases later.