面向Apple Watch应用的开发

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