This question has been asked many times on StackOverflow. You ask if you should pass the ManagedObjectContext
from view to view. The official answer from Apple is yes:
When you create a view controller, you pass it the context it should use. You pass an existing context, or (in a situation where you want the new controller to manage a discrete set of edits) a new context that you create for it. It’s typically the responsibility of the application delegate to create a context to pass to the first view controller that’s displayed.
A view controller typically shouldn’t retrieve the context from a global object such as the application delegate—this makes the application architecture rigid. Neither should a view controller create a context for its own use (unless it’s a nested context). This may mean that operations performed using the controller’s context aren’t registered with other contexts, so different view controllers will have different perspectives on the data.
This is called dependency injection. Whether you choose to use it or not is up to you. Relying on the AppDelegate
or creating a separate singleton to access the managedObjectContext
makes your code more "rigid", as they say, and down the road it can cause problems.
That being said, lots of people use singletons for this kind of thing. It is temptingly easy and the costs aren't immediately apparent. In addition to the SO link that I posted above a Google search for "dependency injection" will explain the advantages better than I can in a few words here.