面向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
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
