在我的服务器上检查新版本的plist

时间:2013-08-02 03:14:06

标签: iphone ios objective-c

我已经尝试了几种方法,看看我是否需要更新用户的UITableView数据源,只有当服务器更新时。在过去的几年里,我已经完成了以下这些场景:1:有一个单独的.txt文件,其中包含一个字符作为版本#,然后只需通过代码比较它们并下载新的.plist,然后将.txt保存到用户的NSDocumentDirectory中使用.plist将来再次进行比较,以及2:实际上检查服务器的文件修改日期,哪个更好,因为没有.txt文件和.plist一起下载(下载的东西越少越好)

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

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

我很抱歉这篇文章很长,感谢你的帮助!

1 个答案:

答案 0 :(得分:1)

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

<强>更新

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

您可以在构建时将data_source.plistlast_modified.plist一起添加到http://server.com/data_source.plist,您可以将哈希,上次修改以及所需的任何其他元数据设置为起点。

检查更新可能类似于:

  1. 发送Last-Modified
  2. 的HEAD请求
  3. 从响应标题中提取hash(以及last_modifed.plist,如果可以发送)
  4. 根据data_source.plist
  5. 中的相应值进行验证
  6. 如果需要,下载更新last_modifed.plist
  7. 如果下载成功,请使用新的元数据更新{{1}}(最后修改并具有,请务必从实际的下载响应标头中提取)。
  8. 这样,用户就可以开始使用,应用程序可以在需要时下载资源。

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