core data Core Data by tutorials 笔记（五）

原文出处: http://chengway.in/post/ji-zhu/core-data-by-tutorials-bi-ji-wu

我们继续来看《Core Data by Tutorials》这本书的第七章 Syncing with iCloud，本章所讨论的是iOS 8和Yosemite最新释出的iCloud Drive，至于iCloud Drive与iCloud的区别可以看这里，调试本章code需要一个开发者帐号：）

Chapter 7: Syncing with iCloud

一、CloudNotes

iCloud是基于Core Data的，之前几个版本确实做的比较烂，不过苹果也在不断地改进。本章的代码其实就是在第六章代码的基础上改为Cloud版本。

二、Enabling iCloud

iCloud对core data store同步其实使用的是ubiquity containers（无处不在的容器），这个无处不在的容器存在你应用的sandbox中，并由iOS系统替你管理。如同向NSFileManager请求应用的 Documents directory，对于iCloud来说，请求的是一个ubiquity container URL。

Core Data通过这个ubiquity container URL保存应用程序的数据，他和通过URL保存到Documents没什么区别。唯一不同的就是iCloud后台进程监视着ubiquity container里面文件的变化，时刻准备上传到云端，而这一切都是系统自动完成的。

这里需要注意的是，iCloud的运行机制有点类似与Git，每次同步的其实是transaction logs，而不是data store本身。而与Git不同的是，commit的时候，Git经常需要处理冲突。但iCloud的commit change是“atomic”的，意味着，要么数据全部有效，要么全部丢弃。

作者这里用伦敦桥搬家举了一个很形象的例子，把桥拆成一砖一砖，然后搬到目的地再按照log记录的正确顺序重组。iCloud的工作机制也差不多。

在Xcode中将Capabilities中的iCloud启用。这里可以使用默认的ubiquity container，也可以自定义。

三、The cloud stack

为.addPersistentStoreWithType方法的参数**option数组增加一个成员NSPersistentStoreUbiquitousContentNameKey**，同样地在stack的初始化中设置。

lazy var stack : CoreDataStack = { 
    let options = [NSPersistentStoreUbiquitousContentNameKey: "CloudNotes",
        NSMigratePersistentStoresAutomaticallyOption: true,
        NSInferMappingModelAutomaticallyOption: true]
    let stack = CoreDataStack(modelName: "CloudNotesDataModel", 
        storeName: "CloudNotes",
        options: options)
    return stack 
}()

使用NSPersistentStoreUbiquitousContentNameKey的值CloudNotes，在ubiquity container中来唯一标识该应用的persistent store。

到此为止，已经为该APP完全开启了iCloud同步，很简单吧。但Core Data在背后还是做了一些工作的，其中一项就是设置了一个fallback store，用于在iCloud离线时保存数据。不过开发者完全不用担心这些东西。

四、Testing iCloud

至于测试则需要拥有一个开发者帐号，登录itunesconnect，依次选择Users and Roles >> Sandbox Testers 新建一个测试用户，这里注意的是，新建完的测试帐号需要在真机设备上激活一下。

具体的测试也很简单，现在模拟器上运行起来，可以看到目前所有添加的数据，然后切换target device（并不按下停止键）选择真机设备Run一下，此时模拟器和真机会同时运行。此时在模拟器上创建新的记录，并选择DebugTrigger iCloud Sync来触发同步，不久应该就能看到新添加的记录在真机上出现。作者还展示了iCloud gauge的方式来查看具体的同步记录。

现在可以来总结一下设置iCloud的基本步骤了，主要有三步：

1. 启用iCloud并且设置ubiquity containers。
2. 通过设置persistent store的options来启用 iCloud-Core Data同步。
3. 当app运行时，设置app响应新的变化。

前两步已经说过了，现在来看第3点。

五、Responding to iCloud changes

该实例程序使用的是fetched results controller，而fetched results controller主要又依赖的是NSManagedObjectContext。但是iCloud更新是直接在persistent store级别的，不会经过Context。因此也不会触发fetched results controller的代理方法来更新UI。

既然如此，我们需要知道iCloud何时更新可以通过监听广播的方法来实现，通过监听NSPersistentStoreDidImportUbiquitousContentChangesNotification广播，来刷新context（通过mergeChangesFromContextDidSaveNotification（notification））

六、Switching iCloud accounts

当前账户登出的话，Core Data会删除当前数据（都安全保存在云端，会在用户重新登录时同步回来）。帐号切换时，Core Data会发送如下两个通知：

• NSPersistentStoreCoordinatorStoresWillChangeNotification
• NSPersistentStoreCoordinatorStoresDidChangeNotification

the notification会包含具体要被adding/added或removing/removed的NSPersistentStore objects

1. 当Core Data发出NSPersistentStoreCoordinatorStoresWillChangeNotification时，Core Data stack会保存当前所有数据到当前store中，这样用户帐号登出了不会丢失任何数据。接着重置managed object context。
2. 当Core data发出“did change” notification时， the notes list controller需要重为新登录的帐号的或本地存储的数据源刷新View。

先处理 “will change” notification：

func persistentStoreCoordinatorWillChangeStores( notification: NSNotification){
    var error : NSErrorPointer = nil if context.hasChanges {
        if context.save(error) == false { 
            print("Error saving (error)")
        } 
    }
    context.reset() 
}

再处理“did change” notification

func persistentStoreCoordinatorDidChangeStores(notification:NSNotification){
    notes.performFetch(nil)
    tableView.reload()
}