Under the Sheets With iCloud and Core Data

Drew McCormack:

I’ve spent the last 3-4 months integrating Core Data syncing over iCloud into Mental Case for Mac. It is not in the wild yet, but we have started beta testing with a limited audience.

To say it has been a challenge would be an understatement — it has probably been one of the hardest tasks I have ever undertaken for a Mac or iOS app.

Update (2012-05-17): Part 2:

In other words, where with MobileMe there was a single truth database in the cloud, there is now just a collection of transaction logs from different devices, and a number of clients doing their best to independently reconcile those logs. As long as the updates are reasonably distinct, it works well, but when changes overlap considerably, you can get quite tricky situations. A lot of the discussion in this series of posts revolves around working around the conflicts that can arise.

Update (2012-05-26): Part 3:

For a start, any objects inserted while iCloud is disabled, and other changes made to the data, will not appear on other devices, even after iCloud is re-engaged. That means the user will see two distinct sets of data. They will wonder why the objects they see on one device are not appearing on the other. But that will likely be the least of the problems…

Update (2012-05-29): Part 4:

Having covered Core Data syncing via iCloud from a high level, in this post I want to introduce a simple test app, which will be extended over the coming weeks. The app should eventually contain most of the code snippets you will need to get your own app up and running with iCloud.

Update (2012-06-08): Part 5:

One solution to these problems is to add a file or files to the iCloud container to track which devices have contributed to the transaction logs. When a device starts syncing, an entry is made in the container. When the device stops syncing, the device entry is left in place as a record that it contributed to the iCloud logs.

Update (2012-06-16): Part 6:

The import takes place in a private context using a private persistent store coordinator, but it still makes use of your managed object classes, and uses key-value coding (KVC) to access properties. That means that if you have any side effects in your custom accessor methods, you could end up undermining the import.

[…]

Your app’s source can influence the import process in another way too. The validation rules of your entity model are applied during the import, as are validation checks in your managed object classes. If any fail, the import fails, and will never recover, leaving the app’s data in an inconsistent state across devices.

1 Comment RSS · Twitter

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ