Core Data by Florian Kugler & Daniel Eggert

Author:Florian Kugler & Daniel Eggert [Kugler, Florian]
Language: eng
Format: azw3
Publisher: objc.io
Published: 2015-12-21T16:00:00+00:00

Organization and Setup

We will use CloudKit as our backend for the example app. That’s mainly because the purpose of the example is to showcase Core Data and not to write a backend. Using CloudKit, we can share Mood instances between all users of the app without having to write our own backend. Plus we can keep our focus on Core Data. However, the architecture and code we describe here will work for more complex situations as well. Toward the end of this chapter, we will further discuss some ways to expand the shown setup depending on your needs.

All the CloudKit-specific code is encapsulated in the CloudKitRemote struct, which implements the MoodyRemoteType protocol. This protocol exposes all the domain-specific functionality we need to communicate with the remote. For the sake of simplicity, we’ll mostly ignore the MoodyRemoteType abstraction and just talk about CloudKit as our remote.

The sample project uses a dummy remote by default, which only logs to the console (ConsoleRemote). This makes it easier to get the project running, because you don’t have to worry about app entitlements and provisioning profiles. The steps to enable the CloudKit remote are described in the sample project’s README file.

As for the CloudKit code in the sample app, we do not intend this to be a state-of-the-art CloudKit implementation. In fact, we are skipping a lot of CloudKit details, as our focus is clearly on the Core Data side of the sync architecture. Please keep this in mind when browsing through the complete code on GitHub.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.