I've been looking at the documentation on Core Data and trying to figure out how to arrange the Core Data Stack so it's accessible to all of my UITableViewControllers. All the examples provided by Apple show this to be implemented on the AppDelegate yet the documentation doesn't recommend this approach because it's too ridged! See link.
(Why this isn't mention on the iPhone SDK documentation is another mystery)
My problem is that I've repeated the design pattern as per the Core Data example shown in TopSongs to retrieve a ManagedObjectContext Entity for a child Table View and the following error is produced… could not locate an NSManagedObjectModel for entity name 'Song'. Strangely this can be found it on the parent Table View so I presume it's because the Core Data stack on the AppDelegate has been dealoc.
Does anyone know a good example that follows a different design pattern to the ones created on Recipies, CoreData Books and Locations? All these follow the same pattern.
All I want to do is retrive the original data and sort is with a different criteria in the chid tableview.
Best Answer
There is significant discussion about where people favor placing the Core Data stack in this question. I tend to place the stack within a singleton (as I indicate there). This gives you convenient access to the stack wherever you need it within your application.
As far as your problem, I find it highly unlikely that the elements of your Core Data stack have been deallocated. For one thing, you'd be crashing on sending a message to your context or model, rather than getting back the report you are now. If you can access the "Song" entity from somewhere else in your application, my bet is that you're not passing the model ot context properly to the instance that needs it.