我正在考虑使用服务人员将我的应用程序离线。我已经通过缓存资源获得了令人满意的结果,但我还必须检查 onfetch 我是否连接到互联网,如果没有 - 存储请求,并将其推送到同步。
我了解,未来的 onsync 将对此有所帮助,但我需要 - 甚至是临时的 - 解决方案。
我尝试将请求存储在工作人员内的数组中,但它不是持久的 - 计算机重新启动后不起作用(而 SW 工作并提供离线内容)。
什么是好的方向 - 以某种方式将其存储在缓存中的文件中?还是使用 IndexedDB / SimpleDB(在 ServiceWorker 中访问 indexedDB。竞争条件)?
问问题
6670 次
1 回答
23
https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker/offline-analytics有一个使用服务工作者来检测某些类型请求失败的示例(在这种情况下,Google Analytics ping通过 HTTP GET
),并使用IndexedDB
. 每次服务工作者启动时都会检查队列,如果可以成功“重播”请求(因为网络现在可用),则将其从队列中删除。虽然无法保证 Service Worker 何时启动(后台同步事件将来会对此有所帮助),但您可以放心地假设,如果有人正在积极使用您的 Web 应用程序,则 Service Worker 将自行恢复。
这可以推广到其他类型的请求,比如 HTTP POST
,但是有几点需要考虑:
- 确保您的用户知道他们的 HTTP
POST
正在排队并且将被重放。由于 HTTPPOST
通常会修改服务器端状态,因此您不希望在由于 X 小时前的重放请求而发生某些变化时让用户感到惊讶。 - 根据您调用的服务,HTTP
POST
可能需要有效的Authorization
标头。如果您使用 OAuth 2 进行授权,它可能会使用寿命有限的访问令牌。以前有效的授权令牌可能会在您重播请求时过期。 IndexedDB
对您的请求进行排队是一个不错的选择,因为它提供了存储任意数据的灵活性,并且应该可以在POST
不做太多工作的情况下存储 HTTP 的主体。如果你不能使用IndexedDB
(你说它不支持使用Cordova),那么我能想到的唯一其他选择是尝试使用Cache Storage API创建一个新的“队列”缓存,失败Request
s 为键和空Response
对象作为值。在服务工作者启动时,您可以使用keys()
“队列”缓存上的方法来获取所有 的列表Requests
,并为每个queuedRequest
调用fetch(queuedRequest)
重播它。我以前没有尝试过这种方法,但我认为它应该有效。
于 2015-04-28T14:49:09.763 回答