0

我的 iOS 应用程序使用 CoreData 作为其数据存储，并且我添加了一个 watchOS 应用程序来配合它。目前 iOS 和 watchOS 应用之间的工作流程如下：

  1. watchOS 应用程序公开了一个菜单，该菜单表示 iOS 应用程序中可用的功能子集
  2. 选择其中一个选项会向 iOS 应用程序发送一条消息，告诉它选择了哪个选项
  3. iOS 应用程序通过将手表为该特定功能所需的任何数据打包到字典中并在回复处理程序中将其发送回手表来做出响应
  4. watchOS 应用程序向用户提供了一个界面，允许他们更改数据中的值
  5. 每次更改都会向 iOS 应用程序发送一条消息，该应用程序使用新值更新核心数据存储

这工作正常，但显然需要在使用应用程序的整个过程中将手机连接到手表才能工作。我想知道是否可以使用以下模型：

  1. 如上
  2. 如上
  3. 如上3a。手表将数据存储在本地
  4. 如上
  5. 每次更改都会更新手表应用的本地数据副本
  6. 用户可以稍后将数据检入到 iOS 应用程序中，然后将其合并到核心数据数据库中

我可以保证冲突不会成为问题，因为用户永远无法修改已经在手机上创建的数据（应用程序不需要这样做）。

所以我的问题是，后一种情况是否允许 watchOS 应用程序独立于 iOS 应用程序运行，但传输数据除外，这是否比我目前处理的方式更可取？

4

1 回答 1

0

手表应用依赖手机会更简单。独立于手机运行更复杂。只有您才能回答为支持真正的独立性而增加的复杂性是否值得，因为您是必须实现、支持和维护所需的任何额外代码的人。

这些更改是否使手表应用程序独立？

不，他们不让手表应用程序独立运行，因为手表仍然必须在步骤 2 和 3 期间从手机请求/接收数据。

为了让手表应用程序在远离手机时完全独立，它必须查询手机根据需要更新的数据的本地副本，而不是要求手机发送手表需要的任何远程数据。

这种改变更可取吗？

不是现在这样。您提出的推迟更新手机的更改（即使它仍然可以访问）可能需要很多不必要的代码，这些代码与当前本地存储数据以及将来将更新合并回手机有关。

此外，虽然您承诺目前没有要处理的合并冲突，但不能保证您将来对应用程序所做的任何修改都不会导致发生冲突的可能性。

如果您选择建立两个持久存储，那么现在实施合并策略将使您的应用程序不那么脆弱，以避免在未来发生冲突时您的更新完全无法保存。

真正的问题...

远离手机（数小时）操作的自由是否值得向用户展示陈旧（或可能误导）的数据？

除非您还提供显示手机刷新数据的时间的指示，否则用户可能会认为显示的信息是最新且准确的，即使它可能是数小时前的。

这增加了手表应用程序在面向用户的 UI 中或在幕后处理陈旧数据的复杂性。

供您参考，Apple Watch 的天气应用程序在无法从手机获取当前天气数据时根本不显示任何数据（因为用户想知道当前温度和降水机会）。

于 2016-04-19T17:31:41.507 回答