Mobile Zone is brought to you in partnership with:

Programmed Macs since Inside Mac came in 3-ring binders; programmed iPhones since the first day the SDK was downloadable. 51 apps in the App Store to date, and always looking for new and interesting contracts! Alex is a DZone MVB and is not an employee of DZone and has posted 142 posts at DZone. You can read more from them at their website. View Full User Profile

A New Solution for CoreData Sync: ZumeroIncrementalStore

10.30.2013
| 1997 views |
  • submit to reddit

So, you may remember our post a little while ago on the not-so-simmering discontent with the then current state of CoreData sync, and a couple since on other cloud technologies to be aware of; but today we’d like to draw your attention to a new solution from Joel Grasmeyer who, after surveying the landscape himself, decided to - what else? - write a new NSIncrementalStore to solve everybody’s problems!

Introducing ZumeroIncrementalStore

What Is It?

ZumeroIncrementalStore is an NSIncrementalStore subclass that lets you use Core Data with the Zumero SDK to sync data between iOS and Mac apps. Zumero is a “replicate and sync” technology based on SQLite that allows apps to be fully functional offline and sync in the background when they’re online.

What does that mean?

It means that you can add syncing to your Core Data app by swapping out Apple’s NSPersistentStore with ZumeroIncrementalStore, and as far as the app knows, it’s just using Core Data with a local data file. Then whenever you want your app to sync, you call a sync method in the Zumero SDK, and sync happens in the background…

If you’d managed, like us, to overlook the existence of Zumero so far, here’s the long form of “‘replicate and sync’ technology based on SQLite”:

Zumero asks (and answers): “What if that local database was all the mobile application had to worry about?” You update your database, and trust that it’s being updated as needed when the outside world changes. Zumero…

…makes sure the server has your latest changes.

…makes sure you have the latest changes from the server and from other mobile users.

…handles merges and conflicts in one place. By the time Zumero sends you new data, it’s already sorted out.

…worries about re-sending updates that didn’t go through earlier.

Did we mention speed?

In addition to reliability and simplicity, this approach can make your mobile apps significantly faster from the users’ point of view. No more waiting for a server call that never finishes (or at least feels that way). No stalls while data updates are processed, vetted, merged. Your database is small, fast and local, just like your app.

What do I need to learn?

Not much. We provide the tools to do this on your mobile platform of choice: native iOS and Android; Xamarin; PhoneGap; Windows 8.

Dealing with a Zumero database is just like dealing with any SQLite database, plus an extra line or two of initialization, and a “sync” call that probably happens in a background method that you write once and ignore thereafter…

Well, that certainly makes it sound like a pretty much optimal choice from the cross-platform architecture standpoint; and pricing appears reasonable too.

From the non-cross-platform architecture standpoint, flipping through the sample project that’s up at

grasmeyer / ZumeroIncrementalStore

does indeed look like it integrates into the accustomed Core Data workings just pretty much as smoothly as you could ask for. Not only that, it also addresses the memory issues with using Core Data for mass operations:

Bypass Core Data for Direct SQL Access

Brent Simmons wrote a blog post about using Core Data for the Vesper app where he mentioned that he likes many of the features of Core Data, but he is concerned about an edge case of updating 30,000 notes quickly without pulling them all into memory. I think ZumeroIncrementStore might be a solution to this issue. You can use Core Data for most of your in-memory object management, but if you ever need to “update a single value on 30,000 items”, you can always call reset the Core Data Managed Object Context, change the values directly in SQLite via the Zumero SDK, and then fault the objects again as needed for the UI…

So, looks like we’ve got a pretty good contender here to fix all the serious issues people have with the iCloud + Core Data stack, without giving up … well, anything, really. Next time you’re designing out a cloud data layer, give it a shot!

Published at DZone with permission of Alex Curylo, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)