

AFIncrementalStore: Core Data with AFNetworking, Done Right  - matttthompson
https://github.com/AFNetworking/AFIncrementalStore

======
newhouseb
Woah, who knew NSIncrementalStore has been exactly what so many of us have
been looking for. After a quick scan through, this looks like it completely
replaces, not wraps, the default SQLLite store, yes? In other words, if the
network is down, you can't save anything that would be synched later or
request any queries that weren't cached? Or maybe I'm just not reading things
right.

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.

~~~
cloudmike
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.

~~~
newhouseb
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.

~~~
cloudmike
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.

------
shawnwall
As a long time Obj-C/iOS dev, web service interaction frameworks and/or best
practices have been lacking for some time now. While RestKit works, it's
learning curve is a tad steep and the sheer size of it can be a tad
frightening in terms of 3rd party component reliance. If AFIncrementalStore is
as great to work with as AFNetworking itself devs may have found themselves a
new standard.

~~~
frankdenbow
is there any good central repository for these kinds of frameworks / best
practices?

~~~
matttthompson
All of the best Objective-C libraries can be found on CocoaPods
(<https://github.com/CocoaPods/specs/>)

