This again avoids rigidity because the view controller that represents the entity does not need to call up to a parent object or the `UIApplication` delegate. Therefore we can easily retrieve the `NSManagedObjectContext` from the `NSManagedObject` and create the new Type entity and pass it to the modal child or whatever our design calls for.
The `NSManagedObject` retains a reference to its `NSManagedObjectContext` internally and we can access it. Fortunately this solution is easy to fix. In this case we have passed in an entity (the recipe) but not a reference to the `NSManagedObjectContext`.
Perhaps it is a detail view of a recipe and the user wants to add a new recipe type (perhaps she is a vegan and just discovered there is no vegan type in the list). In these cases there are a few different options.įollowing our example above, lets say that view controller C needs to create a new object. Perhaps a child view, for whatever reason needs to access information that cannot be directly passed into it every time. What happens when we don’t have a typical navigation controller design? Perhaps a child view can pop up a modal view that displays different information. None of them care what their parent view controller is. The child views only get the items it cares about passed into it. The root gets the `UIFetchedResultsController` passed into it. How does this break rigidity? Each view controller, from the root on down, only knows what is passed into it. The Core Data Recipes example provided by Apple illustrates this design quite well. In this design, however, instead of passing around a context, you would hand off just the entity that the child view controller needs to know about. The other advantage is that your least detailed view (the root most likely) can listen as the delegate of the `UIFetchedResultsController` for changes and update itself. The advantage is that the `UIFetchedResultsController` is designed to work with tables. This controller can be considered a thin layer between the view controllers and the Core Data bits. In this case then the best solution is to use a `UIFetchedResultsController`. The left most (or root) view controller contains the most vague information and the right most (or deepest) view controller contains the greatest detail. This is the trap that the documentation is trying to help new developers avoid.Īgain using a standard/normal navigation controller design, it is expected that the detail flows from left to right. It is nearly impossible to either move view controller B to another location in the stack or to reuse view controller B somewhere else. While there is nothing technically wrong with this design, it is very rigid.
In that design, it would be common to see view controller B call methods or call back (to its delegate) view controller A. When this design, it is common to code each view controller and make it “aware” of its parent. !( “Standard Navigation Controller Design”) Take the following navigation controller design: It is fairly common when designing a Cocoa Touch application to “hard code” everything. Once a view controller is pushed onto the screen it should ideally be its own master. It should not rely on its parent, nor should it rely on the Application Delegate. Ideally, each view controller should be an island on its own. The idea behind this section is the issue of rigidity. It’s typically the responsibility of the application delegate to create a context to pass to the first view controller that’s displayed. 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. > When you create a view controller, you pass it a 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. Neither should a view controller typically create a context for its own use. This tends to make the application architecture rigid. > A view controller typically shouldn’t retrieve the context from a global object such as the application delegate. One particular section seems to be the most confusing, specifically: The documentation on Core Data for the iPhone has lead to some confusion about how best to use Core Data on a Cocoa Touch device. **This article is reprinted from the MDN**