面向Apple Watch应用的开发

更新时间:2015-01-20 10:02:01点击次数:2468次

摘要:软件工程师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

本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责,本站只提供参考并不构成任何投资及应用建议。本站是一个个人学习交流的平台,网站上部分文章为转载,并不用于任何商业目的,我们已经尽可能的对作者和来源进行了通告,但是能力有限或疏忽,造成漏登,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息