iOS Core Data - ManagedContext Question

[CBX]

As my application is more of a scratch pad rather than something that was designed I'm now looking at added Core Data support.

Instead of try to plumb it straight in I created a new project (this time checking the use core data option) to see the 'default' code thats generated.

Doing some quick reading I'm fine with creating the model and then entity side of things. And to some degree I understand the Managed Object Context.

However, what I don't get at this stage is that the MoC etc is created in the App Delegate. My app is using storyboarding, so I have dropped a TableViewController on it and embedded it a Navigation Controller. This TableViewController is linked to a subclass of UITableViewController I create.

So my storyboard looks like:

->Nav Controller->TVC

The generated code created and setup the MoC in the AppDelegate, so how do I access it in my TVC?

Does it have to be passed along to my TVC (how??) or is it used like a global variable?

If I add another view to my storyboard e.g.:

->Nav Controller->TVC->ViewController

does it have to be pushed down the chain (again how??) or as before is it used like a global variable?

 

[seepel]

In my opinion (and I've seen others that share my view), putting the Core Data boiler plate in the App Delegate is a horrible way to go. You really need Core Data stuff to be thread isolated, which the App Delegate isn't necessarily.

I recommend looking at MagicalRecord, it's a great package that I've been using.

 

[Scott90]

In my opinion (and I've seen others that share my view), putting the Core Data boiler plate in the App Delegate is a horrible way to go. You really need Core Data stuff to be thread isolated, which the App Delegate isn't necessarily.

I recommend looking at MagicalRecord, it's a great package that I've been using.

How would you go about passing the MOC to other VC's in say a Tab Bar Controller then? If I create an MOC in tab 1 and then switch to tab 2, I want to use the same MOC, but there isn't really an easy way to pass the MOC then. If you create it in the App Delegate, you could always make sure you're using the right thread by calling performBlock on the MOC...

 

[MattInOz]

As I understand it...

The Apple design pattern is to "pass the batten". In that any Object (ie ViewController) that needs the MOC(ManagedObjectContext) should have a property to hold it. This property should be set by object that creates it. So in the case of the core data templet the AppDelegate manages the core data stack and holds a MOC that then (in theory*) gets past to the first view controller. If further ViewControllers in the stack will need the MOC then it gets past to them in the same fashion. The is meant to allow not just for threading but also for things like cancelling changes made in a ViewController. As you could pass a sub-MOC and changes made in that sub-MOC don't get committed up the chain until you save both the sub-MOC then it's parent-MOC.

I'll have to check out Magical Record before I next jump in to CoreData stuff looks interesting.

*It seems there is a bug in which the viewController has been created and tries to work with the MOC before it's been passed to it. So the VeiwController sends the messages to Nil and you gets lots of errors telling the Entity for name can't be found for context. Which was really frustrating because first up I though it was a human typing error. If your hitting this problem do a search for the latest version of the fix at the Apple Developer Forums, but it generally involves grabbing the MOC from the AppDelegate.

 

[seepel]

How would you go about passing the MOC to other VC's in say a Tab Bar Controller then? If I create an MOC in tab 1 and then switch to tab 2, I want to use the same MOC, but there isn't really an easy way to pass the MOC then. If you create it in the App Delegate, you could always make sure you're using the right thread by calling performBlock on the MOC...

Before I switched to using Magical Record I would typically make a category on NSManagrdObjectContext with factory style functions that I could grab a common "main thread" context or create a new context for a background thread. MagicalRecord basically does the same thing with a lot more bells and whistles to boot.

 

[Scott90]

As I understand it...

The Apple design pattern is to "pass the batten". In that any Object (ie ViewController) that needs the MOC(ManagedObjectContext) should have a property to hold it. This property should be set by object that creates it. So in the case of the core data templet the AppDelegate manages the core data stack and holds a MOC that then (in theory*) gets past to the first view controller. If further ViewControllers in the stack will need the MOC then it gets past to them in the same fashion. The is meant to allow not just for threading but also for things like cancelling changes made in a ViewController. As you could pass a sub-MOC and changes made in that sub-MOC don't get committed up the chain until you save both the sub-MOC then it's parent-MOC.

That sounds about right. As far as I know, the only way to have a tab bar controller with multiple view controllers that use the same MOC, is by creating the MOC in the App Delegate which can then pass it to all the view controllers that need it.

One question: when creating an MOC and passing that to a different view controller, I don't have to pass the MOC back to the original view controller when the second one goes off screen, right? This could be the case where I have a modal view controller that needs an MOC.

 

[CBX]

To get core data in my app working wasn't to hard for a new, but I'm not sure if I feel comfortable with the design I have so its good to hear peoples (who have more experience) thoughts on this.

 

[dejo]

Besides the "pass-the-baton" approach, Apple also stresses the use of singletons.

P.S. the appDelegate is a singleton.