> 原文出處: http://chengway.in/post/ji-zhu/core-data-by-tutorials-bi-ji-wu
我們繼續來看[《Core Data by Tutorials》](http://www.raywenderlich.com/store/core-data-by-tutorials)這本書的第七章 Syncing with iCloud，本章所討論的是iOS 8和Yosemite最新釋出的iCloud Drive，至于iCloud Drive與iCloud的區別可以看[這里](http://www.v2ex.com/t/139804)，調試本章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](https://itunesconnect.apple.com/)，依次選擇**Users and Roles**?>>?**Sandbox Testers**?新建一個測試用戶，這里注意的是，新建完的測試帳號需要在真機設備上激活一下。
具體的測試也很簡單，現在模擬器上運行起來，可以看到目前所有添加的數據，然后切換target device（并不按下停止鍵）選擇真機設備Run一下，此時模擬器和真機會同時運行。此時在模擬器上創建新的記錄，并選擇Debug\Trigger 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()
}
~~~
