iOS Core Data Architecture tips wanted

Question

I just want to get a few pointers on the best way to architect my first Core Data app, and the main objects and interactions I will require.

The data is stored remotely and I will need to access it via HTTP and it will respond in JSON format. I want to cache this on the device using Core Data. Each day there will be new data on the server, so I need to access this and update the Model accordingly.

Are there any SDK classes I can use to help me with this, or am I going to hand roll it?

I guess I'm looking at a Model Controller that I call to get the data, it will return the core data cached data and maybe make a background call to the web service to get latest data too and then notify the view that there is new data. When I get the data from web service in JSON format - i will need to map this to ManagedObjects an add to my core data context.

Answer 1

Thanks dtuckernet, here is what I did do - gathering info from lots of sources, which I believe is the best solution. Anyone feel free to criticise (constructively)....

1. I have my Core Data stack in CoreDataStack.h (singleton) - not entirely necessary, but it unclutters my app delegate class.
2. I have a base CoreDataBackedTableViewController : UITableViewController
3. Each of my table view screens extends CoreDataBackedTableViewController and have an ivar to a ModelController class.
4. An example ModelController class has a - (NSFetchedResultsController *) getData method which constructs the NSFetchedResultsController (also keeps a ref to it) and returns it to the view controller which also stores it in CoreDataBackedTableViewController (which listens for updates and edits to the data). Having the ModelController class allows me to encapsulate my data access to potentially have 2 different view controllers use this (iPhone and iPad perhaps)
5. In getData - i make a call to my backend webservice asynchronously. Using delegates for callbacks
6. The backend is using SBJSON for parsing and NSHttpConnection and a hand rolled HttpService class.
7. When the backend returns with data, it calls the delegate on the ModelController which updates core data - and my fetchedResultsController knows about this and automatically updates my interface ! How cool is this bit - not a lot of effort involved on my part. I have to do some detection on whether i've already downloaded the data before or not to avoid duplicates.
8. Ready to roll this out to the rest of my app....

If anyone wants any clarification on any of the steps, just let me know.

Answer 2

There are a lot of different pieces at play here. Allow me to make some suggestions:

1. For fetching the data from the server, I would look at ASIHTTPRequest. This is a good solution for managing your HTTP requests (whether you are using JSON, XML, or whatever..). http://allseeing-i.com/ASIHTTPRequest/
2. For JSON translation, I would look at SBJSON. The site has documentation on how to get started: http://code.google.com/p/json-framework/
3. For your overall architecture, I would implement a delegate pattern that wraps your service calls. In this delegate, you would handle the translation of the JSON data to actual Objective-C classes before the data gets passed to the rest of the application.
4. Once the data is parsed and placed into Objective-C objects (and I would have these objects be subclasses of NSManagedObject which ties to your data model directory), I would perform a save.
5. I would then use an NSNotification to inform the needed views that the data has changed.

Answer 3

You absolutely, definitely want to use RESTKit. This is a direct connection from your RESTful web service to Core Data. Define your data model using Xcode's built-in tool, define a mapping layer for your web service using RESTKit, and let the library do the heavy lifting. It's wonderful.