In addition to AFIncrementalStore and the other suggestions in this thread, you should check out Simperium (http://simperium.com). Our iOS/OSX library watches your existing Core Data context and handles syncing transparently, with full support for offline use. Unlike other solutions, we use persistent connections and operational transforms to send only the data that changes, allowing many conflicts to be resolved automatically.
We've already been down the path of using a more traditional RESTful approach to syncing data with earlier versions of our app Simplenote. I agree it seems like it should be easy to just cache some offline data locally and send it up to a server at first opportunity. And you can write a prototype of that system pretty quickly. But in our experience at least, conflicts, errors, duplicates, etc. arise a lot more often than you might think and it's very hard to make a system like that reliable, not to mention scaling and maintaining it.
Hi Mike, I went to your talk at CocoaHeads a month or so ago - I'm a big fan.
Correct me if I'm wrong, but, a big part of the point of NSIncrementalStore is that you don't need the entire database locally to perform queries against it (hence, Incremental and not Atomic). If somebody wanted to go parading around someone else's data (imagine clicking around through a bunch of YouTube videos) that would require interfacing with Simperium's query API's on other people's buckets, and then maybe saving that to your own local CoreData store, right? As I understand it Simperium hooks into context change notifications to figure out locally performed OT and then periodically pulls from the network to find OT on the bucket performed elsewhere. Maybe a good next step for you guys would be to build in a NSIncrementalStore for querying outside of the synchronized bucket to other people's stuff.
Your analysis is accurate. Actually, one of the features we're preparing to launch is sharing/collaboration/groups, which will allow data in Simperium to flow across users the same way it currently flows across devices. But you're right in that having more ways to perform queries outside of a known data set would be useful too.
Comments
In addition to AFIncrementalStore and the other suggestions in this thread, you should check out Simperium (http://simperium.com). Our iOS/OSX library watches your existing Core Data context and handles syncing transparently, with full support for offline use. Unlike other solutions, we use persistent connections and operational transforms to send only the data that changes, allowing many conflicts to be resolved automatically.
We've already been down the path of using a more traditional RESTful approach to syncing data with earlier versions of our app Simplenote. I agree it seems like it should be easy to just cache some offline data locally and send it up to a server at first opportunity. And you can write a prototype of that system pretty quickly. But in our experience at least, conflicts, errors, duplicates, etc. arise a lot more often than you might think and it's very hard to make a system like that reliable, not to mention scaling and maintaining it.
Hi Mike, I went to your talk at CocoaHeads a month or so ago - I'm a big fan.
Correct me if I'm wrong, but, a big part of the point of NSIncrementalStore is that you don't need the entire database locally to perform queries against it (hence, Incremental and not Atomic). If somebody wanted to go parading around someone else's data (imagine clicking around through a bunch of YouTube videos) that would require interfacing with Simperium's query API's on other people's buckets, and then maybe saving that to your own local CoreData store, right? As I understand it Simperium hooks into context change notifications to figure out locally performed OT and then periodically pulls from the network to find OT on the bucket performed elsewhere. Maybe a good next step for you guys would be to build in a NSIncrementalStore for querying outside of the synchronized bucket to other people's stuff.
Oh, hey!
Your analysis is accurate. Actually, one of the features we're preparing to launch is sharing/collaboration/groups, which will allow data in Simperium to flow across users the same way it currently flows across devices. But you're right in that having more ways to perform queries outside of a known data set would be useful too.