我应该如何处理 pushsubscriptionchange 事件? [英] How should I handle the pushsubscriptionchange event?

查看:73
本文介绍了我应该如何处理 pushsubscriptionchange 事件?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

根据规范pushsubscriptionchange 事件表示推送订阅已失效,或即将失效".处理此事件的最佳做法是什么?

According to the spec, a pushsubscriptionchange event indicates that "a push subscription has been invalidated, or will soon be invalidated." What are the best practices for handling this event?

推荐答案

  1. 完全在 Service Worker 内处理重新订阅.在事件被触发时可能没有与 Service Worker 关联的客户端(即打开的页面)——不要使用 postMessage() 触发客户端重新订阅.
  2. 实现可能会在一段时间(可能是几天)内兑现旧订阅.虽然规范没有做出这样的保证,但实现很可能会同时支持某些减少/消除消息被丢弃的机会的时间,因为所涉及的客户端或服务器之一没有收到新"密钥.
  3. 截至 2016 年 4 月,Chrome 和 Firefox 均未触发此事件.但是,由于它在规范中,为了确保用户继续接收消息,您应该确保正确处理它.
  1. Process the re-subscription entirely within the service worker. There may be no client (i.e. open pages) associated with the service worker at the point the event is fired--do not use postMessage() to trigger a re-subscription from the client.
  2. Implementations are likely to honour the old subscription for a period of time (probably days). Whilst the spec makes no such guarantee, it is likely that implementations will support both old and new keys for some time to reduce/eliminate the chance of messages being dropped because one of the clients or servers involved hasn't received the "new" key.
  3. As of April 2016 neither Chrome nor Firefox fires this event. However, since it's in the spec, to ensure users continue to receive messages, you should make sure you handle it correctly.

这篇关于我应该如何处理 pushsubscriptionchange 事件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆