向 Chrome 发送推送通知

Question

我正在编写一个允许人们聊天的简单单页应用程序。该应用将主要在移动设备上使用（主要是Android，但也有一些iOS，虽然Android是主要焦点）。

在通知方面，我倾向于https://github.com/primus/primus。但是，我的主要问题是我需要在用户关闭手机或没有访问特定页面的情况下发送通知。

所以，我也在研究服务工作者和推送通知——我想知道我是否应该将它们用于一切而忘记 Primus。

所以...问题：

问题：

• 我应该选择混合架构（Primus + 使用 Web Worker 的推送通知），还是应该坚持使用一种？

• 按照 Service Worker 的方式，如果不使用 Firebase 等，我将如何处理？也就是说，Service Worker 会是什么样子？推送代码（节点/服务器和客户端）是什么样的？

• 再次就服务工作者而言，如果用户重新启动手机，或者无论出于何种原因服务工作者没有在其客户端上运行，服务器是否有办法知道这一点？ （在这种情况下，我会发送短信或电子邮件...）

• 或者，移动网站是否有可能获取查看页面的设备 ID，并转而采用移动推送架构？

Answer 1

我应该选择混合架构（Primus + 使用 Web Worker 的推送通知），还是坚持使用一个？

您不应在 Web Push API 之上构建 RTC 系统。这不是 Web Push 的预期目的，而是提供一种通知用户timely events 的机制。

当您无法建立 RTC 连接以让用户重新打开您的 SPA 并重新连接时，您可以使用 Web Push。

按照 Service Worker 的方式，如果不使用 Firebase 等，我该如何做？也就是说，Service Worker 会是什么样子？推送代码（节点/服务器和客户端）是什么样的？

如果你想在 Android 中接收 Web Push 通知，你不能避免 Firevase，因为你需要 GCM（现在是 Firebase Cloud Messaging）。

再次就 Service Worker 而言，如果用户重新启动手机，或者无论出于何种原因 Service Worker 未在其客户端上运行，服务器是否有办法知道这一点？ （在那种情况下，我会发送短信或电子邮件......）

老实说，我不知道。但是您可以构建自己的 ack 系统。如果您在合理的时间范围内没有收到确认，您可以认为设备没有收到通知。

或者，移动网站是否有可能获取查看页面的设备 ID，并转而采用移动推送架构？

也许有特定的浏览器扩展，但不是以标准和跨浏览器支持的方式。