0

我已经尝试了几种方法来查看是否仅在服务器更新时才需要更新用户的 UITableView 数据源。在过去的几年里，我做过这些场景： 1：拥有一个单独的 .txt 文件，其中一个字符作为版本 # 然后简单地通过代码比较它们并下载新的 .plist，然后将该 .txt 保存到用户的 NSDocumentDirectory与 .plist 将来再次比较，以及 2：实际检查服务器的文件修改日期，效果更好，因为没有 .txt 文件与 .plist 一起下载（下载的东西越少越好）

但是，现在我想尝试一种不同的方式来说明我在 App Bundle 中发布了一个 .plist 文件这一事实。由于 .plist 文件的创建日期总是晚于新用户的服务器日期，因此他们不会获得新的 .plist 文件，而应用程序的老用户会获得新文件。当然，在第一个应用程序启动时，我可以获取服务器的修改日期并覆盖应用程序，因为我将它从主包复制到 NSDocumentDirectory，但我不认为我想走那条路，因为我从来不喜欢检查发射计数。

基本上，它需要在网络请求时间上继续保持轻量级，并且像我一样可靠。我正在考虑在我的 .plist 中创建一个版本 # 键，并简单地将其与本地 .plist 进行比较，但我非常怀疑这将是轻量级的，因为我必须先将整个 .plist 下载到 NSDictionary 中才能下载比较关键值。

真的很抱歉这篇文章很长，感谢您的帮助！

4

1 回答 1

1

为什么不发布没有data_source.plist文件的应用程序并在第一次启动时下载它，或者在磁盘上不存在的任何其他时间（你永远不知道）。之后，您可以发送 HEAD 请求并检查修改日期（甚至可能是电子标签），并根据需要下载。

更新：

根据您对服务器的控制程度，您可以在 Last-Modified 旁边将文件的哈希添加到响应标头（如注释中所述：MD5，SHA*）。

您可以data_source.plist在构建时将其添加到包中，以及last_modified.plist您可以设置哈希、上次修改和任何其他您想要的元数据的位置作为起点。

检查更新可能类似于：

  1. 发送 HEAD 请求http://server.com/data_source.plist
  2. 从响应标头中提取Last-Modified（hash如果可以发送）
  3. 对照中的相应值进行验证last_modifed.plist
  4. data_source.plist如果需要，下载更新
  5. 如果下载成功，则last_modifed.plist使用新的元数据进行更新（最后修改并已，请务必从实际下载响应标头中提取）。

这样，用户就有了一些东西可以开始，应用程序可以在需要时下载资源。

HEAD请求的优点是重量轻，因为没有消息正文，但返回与 GET 请求相同的响应标头。这是检查资源是否已更新的常用方法。您的方案的诀窍是在构建时获取设备的起点。

于 2013-08-02T03:25:41.460 回答