Question

Hey, I’m working on the model layer for our app here.

Some of the requirements are like this:

1. It should work on iPhone OS 3.0+.
2. The source of our data is a RESTful Rails application.
3. We should cache the data locally using Core Data.
4. The client code (our UI controllers) should have as little knowledge about any network stuff as possible and should query/update the model with the Core Data API.

I’ve checked out the WWDC10 Session 117 on Building a Server-driven User Experience, spent some time checking out the Objective Resource, Core Resource, and RestfulCoreData frameworks.

The Objective Resource framework doesn’t talk to Core Data on its own and is merely a REST client implementation. The Core Resource and RestfulCoreData all assume you talk to Core Data in your code and they solve all the nuts and bolts in the background on the model layer.

All looks okay so far and initially I though either Core Resource or RestfulCoreData will cover all of the above requirements, but… There’s a couple of things none of them seemingly happen to solve correctly:

1. The main thread should not be blocked while saving local updates to the server.
2. If the saving operation fails the error should be propagated to the UI and no changes should be saved to the local Core Data storage.

Core Resource happens to issue all of its requests to the server when you call - (BOOL)save:(NSError **)error on your Managed Object Context and therefore is able to provide a correct NSError instance of the underlying requests to the server fail somehow. But it blocks the calling thread until the save operation finishes. FAIL.

RestfulCoreData keeps your -save: calls intact and doesn’t introduce any additional waiting time for the client thread. It merely watches out for the NSManagedObjectContextDidSaveNotification and then issues the corresponding requests to the server in the notification handler. But this way the -save: call always completes successfully (well, given Core Data is okay with the saved changes) and the client code that actually called it has no way to know the save might have failed to propagate to the server because of some 404 or 421 or whatever server-side error occurred. And even more, the local storage becomes to have the data updated, but the server never knows about the changes. FAIL.

So, I’m looking for a possible solution / common practices in dealing with all these problems:

1. I don’t want the calling thread to block on each -save: call while the network requests happen.
2. I want to somehow get notifications in the UI that some sync operation went wrong.
3. I want the actual Core Data save fail as well if the server requests fail.

Any ideas?

Answer 1

You should really take a look at RestKit (http://restkit.org) for this use case. It is designed to solve the problems of modeling and syncing remote JSON resources to a local Core Data backed cache. It supports an offline mode for working entirely from the cache when there is no network available. All syncing occurs on a background thread (network access, payload parsing, and managed object context merging) and there is a rich set of delegate methods so you can tell what is going on.