App與Extensions間通信共享數據

 　　最近玩了玩Watch開發，而目前Watch的主要邏輯處理都是放在WatchKit Extension。真正的Host App，也就是WatchKit App只是用來在界面上顯示數據的。於是實踐了下containing app與app extension之間的通信和數據共享。

　　App Groups & Framework

　　這兩樣兵器大家都很熟悉。想要共享數據就需要開啟App Groups，給group起一個風騷的名字，這樣無論是NSUserDefaults還是NSFileManager都能通過App Groups共享持久層數據了。Core Data也需要NSFileManager提供存儲的URL支持，而存取Core Data中的數據需要大量的模板代碼，在持久層文件共享之後，代碼也應該做到共享，所以將能夠重用的代碼打包成Framework就顯得尤為重要。(除非是為了做畢設湊代碼量)

　　還是以HardChoice為例，我新建了一個類型為Cocoa Touch Framework的target，名字叫DataKit。新建一個DataAccess.swift文件並將以前AppDelegate.swift中自動生成的Core Data模版代碼轉移過來。得益於Swift1.2的改進，構造一個線程安全的單例模式變得無比簡單：

　　private static let instance = DataAccess()

　　public class var sharedInstance : DataAccess {

　　return instance

　　}

　　需要注意Swift的權限控制問題，我們需要在暴漏給框架使用者的公開接口和屬性前加上public關鍵字修飾。

　　為了實現Core Data持久層共享，需要修改原先的applicationDocumentsDirectory屬性：

　　lazy var applicationDocumentsDirectory: NSURL = {

　　// The directory the application uses to store the Core Data store file. This code uses a directory named "com.yxy.iCloudCoreDataTest" in the application's documents Application Support directory.

　　// let urls = NSFileManager.defaultManager().URLsForDirectory(.DocumentDirectory, inDomains: .UserDomainMask)

　　// return urls[urls.count-1] as! NSURL

　　var sharedContainerURL:NSURL? = NSFileManager.defaultManager().containerURLForSecurityApplicationGroupIdentifier(appGroupIdentifier)

　　return sharedContainerURL ?? NSURL()

　　}()

　　在這裡containerURLForSecurityApplicationGroupIdentifier方法起到了至關作用。

　　同樣能夠共享的代碼就是Model層，它們都是NSManagedObject的子類，用於存儲Core Data中的數據實例。在把它們從原來的位置拖拽過來時別忘了更改下文件的target：”File inspector”->”Target Membership”，選中DataKit。

　　在處理iCloud與Core Data同步數據時，我對NSPersistentStoreCoordinatorStoresWillChangeNotification、NSPersistentStoreCoordinatorStoresDidChangeNotification和NSPersistentStoreDidImportUbiquitousContentChangesNotification這三個數據更新的通知進行了觀察和處理，但是寫在了persistentStoreCoordinator計算屬性的get方法中。現在使用lazy關鍵字進行惰性加載，導致對這三個數據更新通知的觀察延後，這會引發嚴重的錯誤。所以需要將那三個addObserverForName(name, object, queue, usingBlock)方法挪到init()方法中，在第一時間觀察通知。

　　最後在AppDelegate.swift中添加import DataKit，替換掉中的application(application, didFinishLaunchingWithOptions) -> Bool方法中controller.managedObjectContext = managedObjectContext為controller.managedObjectContext = DataAccess.sharedInstance.managedObjectContext，也就是不再使用以前的模板代碼中的上下文實例，而是用DataAccess單例中的managedObjectContext。

　　同理，applicationWillTerminate(application)方法中的saveContext()也要替換成DataAccess.sharedInstance.saveContext()。

　　於是我們也可以在App Extensions中import進來DataKit，進行地存取Core Data中的數據啦。而且用的是同一段代碼，同一塊數據。簡直是同一個世界，同一個夢想啊。

　　Container app 與 Extension的通信

　　要知道之前做的共享數據只能是主動獲取數據，並不能在數據變化時實時獲取通知。如果用戶在iPhone上更改了數據，我們需要在Watch上實時更改界面上數據的顯示。這點NSNotificationCenter是做不到的，因為它只在App內部工作而不會在兩個App之間發通知。同樣KVO也無能為力，自己手寫委托什麼的更是別想了(因為我試過了)。直到我在這篇文章找到了救世主，問題迎刃而解：

　　CFNotificationCenterGetDarwinNotifyCenter

　　這是CoreFoundation庫中一個系統級的通知中心，蘋果的系統自己也在用它，看清了”Darwin”了沒有?哈哈!看了下CFNotificationCenter相關的API，跟NSNotificationCenter有點像。需要用到Toll-Bridge的知識與CoreFoundation相關的類進行橋接，這雖不常用但也不難。還需要注意下個別參數的使用。

　　MMWormhole

　　更有趣的是幾乎同時我也發現了MMWormhole這個開源庫，它專門用於在Container app 與 Extension間傳遞消息。我讀了下它的代碼，雖然只有一個類，但是依然學到了很多。雖然在我的HardChoice上完全可以只用CFNotificationCenter進行通知就可以了，完全不需要使用MMWormhole來持久化數據和傳遞數據。但我覺得以後還可能會用到MMWormhole，於是我用Swift1.2重新寫了一個Wormhole.swift，放在了DataKit裡。

　　Swift與CoreFoundation

　　原來OC寫的兩百多行的MMWormhole被我用150行“清新優雅”的Swift代碼取代。之所以打上引號是因為Swift與CoreFoundation之間的橋接有些不愉快。因為CoreFoundation中都是C的API，C中的指針和類型轉換很出格，有安全隱患。Swift是一門安全的語言，但為了調用由歷史原因造成的不安全的C的API，Swift中引入了很多類型來映射C中的類型，參考Interacting with C APIs

　　Swift中不用像OC那樣使用__bridge和類型轉換、內存管理交接，因為這些全都交給Swift了：如果Swift中存在類型映射到C的API所需的參數類型，那麼可以直接將其傳入API。此外內存管理也歸Swift中的ARC統一管理。於是Swift大大簡化了與CoreFoundation打交道的過程。

　　我們最關心的是指針，UnsafePointer對應了const CType *，UnsafeMutablePointer對應了CType *。當然SwiftType與CType也是對應的：

　　更多的轉換規則，在上面提到的官方文檔有很詳細的描述，這裡只說三個tips：

　　在Swift中將self轉成UnsafePointer(也就是const void *)只需用這個函數：unsafeAddressOf(self)

　　CoreFoundation庫中後綴為”Ref”的類在Swift中已經去掉後綴。

　　Swift中函數指針被表示為CFunctionPointer，Type就是函數的類型，但還不允許你將Swift寫的函數或閉包轉化成CFunctionPointer，也就是干脆沒提供建立CFunctionPointer實例的方法，只能通過外部引入C的函數。這就涉及到了Swift與OC混編，請戳Swift and Objective-C in the Same Project

　　在Framework中混編OC

　　我之所以需要做這種破壞工程純潔性的事兒，是因為要用到下面這個方法來對通知進行觀察：

　　1func CFNotificationCenterAddObserver(center: CFNotificationCenter!, observer: UnsafePointer, callBack: CFNotificationCallback, name: CFString!, object: UnsafePointer, suspensionBehavior: CFNotificationSuspensionBehavior)

　　除了類型為CFNotificationCallback的參數，其余的都好說：

　　1typealias CFNotificationCallback = CFunctionPointer Void)>

　　於是就回到了CFunctionPointer這塊蛋疼地上了，只好在OC裡寫C函數然後調用之：

　　static NSString * const WormholeNotificationName = @"WormholeNotificationName";

　　@implementation HelpMethod

　　- (instancetype)init

　　{

　　self = [super init];

　　if (self) {

　　_callback = wormholeNotificationCallback;

　　}

　　return self;

　　}

　　void wormholeNotificationCallback(CFNotificationCenterRef center,

　　void * observer,

　　CFStringRef name,

　　void const * object,

　　CFDictionaryRef userInfo) {

　　NSString *identifier = (__bridge NSString *)name;

　　[[NSNotificationCenter defaultCenter] postNotificationName:WormholeNotificationName

　　object:nil

　　userInfo:@{@"identifier" : identifier}];

　　}

　　@end

　　然後在Swift中這樣寫就可以了：

　　1CFNotificationCenterAddObserver(center, unsafeAddressOf(self), helpMethod.callback, identifier, nil, CFNotificationSuspensionBehavior.DeliverImmediately)

　　在Swift中使用OC寫的類本來是一件很easy的事兒，但是到了Framework中就變得不尋常。我在DataKit中新建了HelpMethod類，並建立”DataKit-Bridging-Header.h”文件，