摘要：軟件工程師Curt Clifton為我們描述了面向Apple Watch的開發是什么樣的，其中首要考慮的是WatchKit 1.0呈現的視圖，其次是手機和手表之前的數據同步，在開發過程中開發者也會遇到諸如WatchKit只提供setter等挑戰。
Omni Group公司的軟件工程師Curt Clifton在近的一次西雅圖Xcoders Meetup上為我們描述了面向Apple Watch的開發是什么樣的，討論了表應用的概念模型、手機和手表之間的數據通信以及一些挑戰。
概念模型
我們應該考慮的件事是，在WatchKit 1.0中，代碼運行于一個捆綁iPhone應用的擴展中。手表本身不會運行代碼，但它可以作為圖像和編譯腳本的“宿主”，圖像可以動態生成并輸送到手表，雖然對圖像而言有20MB的緩存可用，但緩慢并且不太可靠。
WatchKit框架依然非常小，主要是通過創建代理類在手表上呈現視圖。此外，這些類將主要提供專門的setter方法，而沒有getter。
同步選項
自從iOS擴展運行在一個單獨的進程中，擴展讓app之間的數據交互成為可能。這讓兩者之間的數據同步成了關鍵，常見可用的同步機制有：
NSFileCoordinator
Groups entitlement和user defaults
Shared CoreData/SQLite database
Seed file and callbacks
后一個是Curt Clifton用于他示例應用的解決方案，這里有詳細的描述：
iPhone主機應用編寫一個種子文件，通過JSON負載等方式用于一個共享的應用容器。
手表擴展讀取種子文件數據，然后，當其反饋一些用戶操作到父應用程序時，其將調用openParentApplication:reply——一種能喚醒主機后臺應用的方式。當父應用準備好時，它將調用收到的回復塊。
主機應用可以更新數據到種子文件中，然后運行回復塊，這可以用于將新的數據更新到擴展中。
此時手表不再需要讀取種子文件，它只是在內存中更新其回復塊收到的數據。
挑戰
正如我們之前提到的，WatchKit只提供setter，所以個挑戰是發送命令到不活躍的控件。這可能會導致數據的不一致，并且無論是否活躍，都需要通過每個類追蹤其控件狀態來處理這一問題，在示例應用中是通過_updateDisplay* set方式來實現的。
不支持自動布局，而是被group所取代，允許你從左到右、從上到下進行填補，你可以在group的內部添加group，并建立非常復雜的UI，不過這是一個完全不同的模型。
后，我們還不知道手表的接口會是什么樣子，同時我們也不清楚處理來自手表的通知的方式。
原文來自：InfoQ
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
