views:

614

answers:

3

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.

A: 

THe problem you have here is because you have not declared an entity named songs in your object model...The pattern you are following has nothing to do with it...I suggest you read up on core data and the object model here. Hope that helps you

Daniel
A: 

IIRC the Apple examples initialize the Core Data stack in the App Delegate but they actually setup properties on the view controller to reference the ManagedObjectContext and set those on application load - what Apple's docs is referring to as I read it is that you should do something similar rather than trying to load the ManagedObjectContext directly from the App Delegate.

If you post some code it will be a lot easier to help you figure out what is going on with your error. The first thing I'd check is that the reference to the ManagedObjectContext in your controller is not nil.

paulthenerd
Thanks this makes sense. I take it can call a new ManagedObjectContext again a subsequent viewController?
Jim
+1  A: 

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.

Brad Larson
Brad I like the singleton approach too I already tend to use a singleton for application state handling in most of my apps anyway - Apple's examples don't make it seem as simple as it can be.
paulthenerd
Putting the Core Data on a singleton is exactly what my what my intuition has been telling me. Apple's examples of putting it on the app delegate seem overly complicated to manage from anything other than the first view controller. Thanks. I'm sure that restructuring the project will sort this out.
Jim
I have just done an implementation following Apple's design guidelines, but it does not feel right. Next time I am going for a singleton approach too.
mvexel