使用缓存清单和大量的故障排除,我能够可靠地缓存整个应用程序;请注意,这是一个仅包含少量单独文件资源的单页应用程序。
作为进一步的增强,我一直在试图修改基于
window.applicationCache状态DOM
通知有关更新的用户,即:
点击此处申请更新
如果可能,我可以交换缓存
window.applicationCache.swapCache();
这将允许我交换更新的缓存,然后重新启动页面以提供简化的更新机制。
可能比苹果商店的应用程序更加精简。
我怀疑applicationCache API被苹果阻碍,因为这个原因阻碍了web应用程序。话虽如此,我相信在移动设备上支持“html5”API的水平是苹果Safari浏览器中最强大的功能之一。
以下是我目前注意到的一些问题,没有特别的顺序。请注意,这不是一个全面的错误列表。
我从来没有得到'更新准备'事件;此警报行从不运行:
window.applicationCache.addEventListener('updateready', function(e) {
alert('updateready event status=' + window.applicationCache.status);
}, false);
我无法手动检查更新。下面的代码给我一个例外
try{
window.applicationCache.update();
}catch (err){
alert('exception:\n' + err);
}
看来,只要我开始与缓存状态在所有互动,缓存停止工作。这些错误是难以捉摸的;锁定&隔离任何一个问题都会花费大量时间,尤其是因为所有代码都在其他浏览器(chrome)上完美运行。
现在这是一个很好的例子: 我怀疑,如果您将应用程序固定到主屏幕,iCloud会“备份”资源并在您首次从主屏幕运行应用程序后进行恢复。为避免此问题,您有时可能需要重命名文件。我已经证明,苹果通过
从我的应用程序服务器
完全删除它们删除从主屏幕
的固定网络应用程序清除所有缓存
打开应用程序,使得废弃部件的离散备份safari中的网址
验证其最新版本
pin to home
验证固定应用程序的最新版本
关闭它再次
运行 - 和它回到旧的,不再是你的服务器上。
最后,如果您在手机处于飞行模式时运行固定的应用程序,iCloud将无法恢复过时的文件。这证明它来自空中。
我即将设计一个应用程序就像这样,我们的用户在现场发生的这种想法是......不好。 – 2010-06-25 20:05:21