Usually in a single threaded application, the main managed object context would reside in the AppDelegate, and we’d access it via appDelegate.mainMOC. But now that Apple’s introduced nested contexts (parent and child), they’re recommending the “pass the baton” approach:
Nested contexts make it more important than ever that you adopt the
“pass the baton” approach of accessing a context (by passing a context
from one view controller to the next) rather than retrieving it
directly from the application delegate.
But I don’t really see how introducing nested contexts make it “more important than ever”. Why can’t I just have three contexts in the AppDelegate (masterMOC, mainMOC, extraMOC)? What would be the problem with that, and why is Apple recommending against that approach?
Having all that in the app delegate was a bad idea in the first place. It breaks all kinds of software design rules.
Having said that, the idea is that you do not want to have to write code all over the place that must know exactly which context things like in. With your proposed solution, all code will have to know to use moc1, moc2, or moc3. That is very brittle.
Ideally, you will pass a MOC to code, and that code uses the MOC it was given. If it needs to create a scratch, it can create a child of the MOC passed to it (assuming, of course, that the MOC is not confinement-type).
One approach is to pass objects, and don’t worry about the exact MOC. Simply query the managedObjectContext property of the managed object when necessary.
Note, that keeping stuff in the app delegate means you are using it as a “kitchen sink” and is, in some ways, just glorified global variables.
BTW, it’s “more important than ever” because the newer threading policies are more strict and your code is pretty much guaranteed to die a horrible death if you get threading wrong.