I’m working on an iOS project that synchronizes a lot of data between a web service and an iPad app. We’ve relied on the advice and research in the fantastic issues of objc.io on Core Data and Syncing Data along with performance recommendations from Florian Kugler’s research into Core Data stack configuration and overall the solution is working pretty well for us at this point, but it hasn’t been without its challenges.
Throughout the project I’ve been trying to follow industry news and research to keep up with best practices, interesting sync experiments, and usage of Core Data in iOS 7. A recurring question in much of this is whether to use Core Data at all, and if not what you give up and what can you possibly gain in the process?
Brent Simmons’ series of Vesper Sync Diary posts (linked to below) cover this design and decision process in incredible detail and are well worth the read, culminating with his Hard Core post where he ultimately decides to go ahead with a SQLite based solution instead of using Core Data. When using SQLite the go to solution for Mac or iOS is Gus Mueller’s excellent fmdb framework, however another SQLite based solution with a higher level API and different approach has emerged that is well worth a look too, called YapDatabase. (more…)
Last time I wrote about doing imports of large data sets when using AFIncrementalStore to handle server synchronization I thought I had made an end-run around it, finding a technique which was compatible but faster. I was wrong.
Before I begin, this is not a knock on AFIncrementalStore which does its job well overall. It was my first use of this library, and I have no trouble recommending it for certain uses cases.
After my last post, when I started to test more thoroughly and use the imported data, I saw strange things. Mostly that meant my objects relationships were not what I expected. I’m fairly sure I had seen these relationships created as they should be, but in the fog of the battle which was my work on this feature, I can’t say for certain. My bad. (more…)
Before taking this advice, please see my follow-up.
AFIncrementalStore (AFIS) is a brilliant bit of open source code from Mattt Thompson. It is a great help in synchronizing a remote data source and local data storage handled with Core Data. Its magic is turning the Core Data API into a single interface to both what is on the device and on the server. Data consumers need not worry where the data resides before asking for the data. Just perform a fetch request, and AFIncrementalStore will query both the local store and the remote side to make sure that all data returned is up to date as best as it can.
There is a use case where this model fails, but that’s not a problem if you know how to deal with it.
Migrating between Core Data models is simple – until you need to make changes more complex than adding an entity or attribute. A migration step like deriving data from two columns for a new attribute (such as combining firstName and lastName into normalizedName for faster searches) not only requires a custom migration policy, but prevents a simple invocation of lightweight migration between other models.
the migration from model 1 to 2 only adds a new attribute, and can therefore use lightweight migration
the migration from model 2 to 3 requires a custom migration class
then migrating from model 1 to 3 using a single call to the Core Data API is impossible without a custom migration class from 1 to 3
Writing (n – 1) migrations when creating your nth model is clearly untenable. (more…)
It’s no secret that Apple’s implementation of iCloud syncing for Core Data has issues. Check out episode 12 of Debug for a great discussion and check out the show notes for a number of links to blogs that go into even more detail.
With WWDC around the corner, we can hope for some fixes in iOS 7 and OS X 10.9, but until then a few interesting alternatives have been released. Here’s a look at four of the most promising frameworks for syncing your app’s data.