Best practices for passing NSManagedObjectContext around to UITabBarController child view controllers?

Question

So it seems to me like there's a Catch-22 situation here. Note the following widely (and smartly) held stances on application architecture:

1. Apple (and most alpha devs) recommend not using a singleton or accessing the app delegate singleton for retrieving a NSManagedObjectContext. Rigidity, poor design, etc. OK-- I agree!
2. Iterating over a UITabbarController's child view controllers and giving each child VC a reference to the context (dependency injection) is also stupid, because you are loading every tab in your application at application launch time, just to pass a reference. This also goes against everything Apple recommends for application architecture.

How do you resolve this? Do you use NotificationCenter to post a notification when a view controller awakes from a nib, and have the app delegate pass in the context reference then? That's about the only way I can think of that jives with both #1 and #2, but it also feels like some contortion to me.

Is there a more elegant way?

Edit: doing a notification when initializing a view controller can be a race condition, since if you're doing things with Storyboard, your tabbar's child view controllers tend to be initialized (though sans-view loading) at launch. So you'd have to do such a notification in viewDidLoad, which is a bad idea vis-a-vis MVC convention. It also ties your hands from doing anything with data models (like pre-caching for performance) before the user does anything view-related.

Answer 1

When you pass NSManagedObject instances to a view controller, that view controller can retain those objects. It can then get to the NSManagedObjectContext through those managed objects by calling

-[NSManagedObject managedObjectContext]

I'm not sure if this will work in your particular case, but often it will. The app delegate or the root view controller creates a context and then passes along managed objects.

Update

If you need to use the context in multiple places, there's another pattern that I've found useful:

Subclass NSManagedObjectContext:

@interface MyManagedObjectContext : NSManagedObjectContext

+ (MyManagedObjectContext *)mainThreadContext;

@end

i.e. a singleton context for the UI / main thread. This is cleaner than using the App delegate, since other classes won't have to get to the App delegate, but can use this class directly. Also the initialization of the store and model can be encapsulated into this class:

@implementation MyManagedObjectContext

+ (MyManagedObjectContext *)mainThreadContext;
{
   static MyManagedObjectContext *moc;
   static dispatch_once_t onceToken;
   dispatch_once(&onceToken, ^{
       moc = [[self alloc] initWithConcurrencyType:NSMainQueueConcurrencyType];
       // Setup persistent store coordinator here
   });
   return moc;
}

@end

Answer 2

I see that some time has passed since you posted your question, but I have a different approach that I would like to share with you and everybody else.

I assume that you want to inject the managed object context in all/some of the view controllers that are shown as tabs of the UITabViewController and that you are using a Storyboard with a UITabBarController as the rootViewController.

1. In your AppDelegate header make your AppDelegate to implement the UITabBarControllerDelegate protocol.

   @interface AppDelegate : UIResponder <UIApplicationDelegate, UITabBarControllerDelegate>
   ...

2. In your AppDelegate implementation add the following UITabBarControllerDelegate method. It will take care of setting the managed object context in any view controller that has the property.

   - (BOOL) tabBarController:(UITabBarController *)tabBarController
   shouldSelectViewController:(UIViewController *)viewController {
   if ([viewController respondsToSelector:@selector(setManagedObjectContext:)]) {
       if ([viewController performSelector:@selector(managedObjectContext)] == nil) {
           [viewController performSelector:@selector(setManagedObjectContext:) withObject:self.managedObjectContext];
       }
   }
   return YES;
   }

3. In your application:didFinishLaunchingWithOptions: set self as the UITabBarController delegate.

   UITabBarController *tabBarController = (UITabBarController *) self.window.rootViewController;
   tabBarController.delegate = self;

4. Sadly the first view controller to be loaded is not ready at that time (in tabBarController.selectedViewController), and doesn't invoke the delegate either. So the easiest way to set the first one is to observe the selectedViewController property of the TabBarController

   [tabBarController addObserver:self forKeyPath:@"selectedViewController"
                         options:NSKeyValueChangeSetting context:nil];

   and set it there.

   - (void) observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
   [object removeObserver:self forKeyPath:@"selectedViewController"];
   UIViewController *viewController = [change valueForKey:NSKeyValueChangeNewKey];
   if ([viewController respondsToSelector:@selector(setManagedObjectContext:)]) {
       if ([viewController performSelector:@selector(managedObjectContext)] == nil) {
           [viewController performSelector:@selector(setManagedObjectContext:) withObject:self.managedObjectContext];
       }
   }
   }

Answer 3

I would create a core data provider class, which is a singleton. This class could either just provide the persistent store so that each view controller can create it's own context if needed. Or you could use the provider class more like a manager and return new (if needed) context. It should of course also setup a merge notification to each context so that you can listen to changes between threads.

With this setup each view controller can ask the provider/manager for the context and the provider/manager will handle everything internally and return a context for the view controller.

What do you think?

Answer 4

IMHO I find it more elegant not to do Core Data heavy lifting in a ViewController. I'd suggest that you encapsulate data manipulation into an object and let the object reference/encapsulate your Core Data stack.

When your application and datamodel grows, you want to be really strict with how you pass MOCs. This becomes even more important if youre using concurrency and have to deal with multiple MOCs. Besides, your ViewControllers only need a MOC for FetchedResultsControllers. In most other cases youre fine passing ManagedObjects.