AFIncrementalStore: Core Data with AFNetworking, Done Right
github.com
github.com
Full offline functionality is pretty important to us so I wonder if there is a nice way to make the NSIncrementalStore wrap a regular old SQLLite CoreData store and fault out to the network if something isn't found locally and conversely, store any new calls that need to be made until network is available.
The two solutions would be A) make a NSManagedObject proxy class that actually proxies between the two NSManagedObject instances in different contexts (and maybe handle the replication here as well), or B) use two different NSPersistantStores in one context - but I cannot, for the life of me figure out how CoreData resolves conflicts between different Stores (network and sqlite) in the same Coordinator (NSMergeConflict doesn't seem to discuss this case).
Does anyone have experience using multiple stores and actually understand how NSPersistentStoreCoordinator handles conflicts?
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.
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.