我已经尝试了几种方法,看看我是否需要更新用户的UITableView数据源,只有当服务器更新时。在过去的几年里,我已经完成了以下这些场景:1:有一个单独的.txt文件,其中包含一个字符作为版本#,然后只需通过代码比较它们并下载新的.plist,然后将.txt保存到用户的NSDocumentDirectory中使用.plist将来再次进行比较,以及2:实际上检查服务器的文件修改日期,哪个更好,因为没有.txt文件和.plist一起下载(下载的东西越少越好)
但是,现在我想尝试一种不同的方式来解释我在App Bundle中发送.plist文件这一事实。由于.plist文件创建日期总是晚于新用户的服务器日期,因此它们不会获得新的.plist文件,而应用程序的旧用户将获得新文件。当然,在第一个应用程序启动时,我可以获取服务器的修改日期并覆盖应用程序,因为我将它从主包复制到NSDocumentDirectory,但我不认为我想要去那条路,因为我从来没有喜欢检查发射计数。
基本上,它需要在网络请求时间内继续保持轻量级,并且像我一样可靠。我正在考虑在我的.plist中创建一个版本#key,并简单地将它与本地.plist进行比较,但我非常怀疑这将是轻量级的,因为我必须首先将整个.plist下载到NSDictionary中。比较关键值。
我很抱歉这篇文章很长,感谢你的帮助!
答案 0 :(得分:1)
为什么不发送带有data_source.plist
文件的应用程序,并在第一次启动时下载它,或者在磁盘上不存在任何其他时间(你永远不知道)。之后,您可以发送HEAD请求并检查修改日期(甚至可能是电子标签),并根据需要下载。
<强>更新强>:
根据您对服务器的控制程度,您可以将文件的哈希值添加到响应标头中(如注释中所述:MD5,SHA *),并在Last-Modified旁边。
您可以在构建时将data_source.plist
与last_modified.plist
一起添加到http://server.com/data_source.plist
,您可以将哈希,上次修改以及所需的任何其他元数据设置为起点。
检查更新可能类似于:
Last-Modified
hash
(以及last_modifed.plist
,如果可以发送)data_source.plist
last_modifed.plist
这样,用户就可以开始使用,应用程序可以在需要时下载资源。
HEAD请求的优点是重量轻,因为没有消息体,但返回与GET请求相同的响应头。检查资源是否已更新是一种常用方法。您的方案的诀窍是在构建时获取设备的起始点。