ブラウザを閉じるとプッシュが機能しないのはなぜですか？
この質問はよく寄せられます。その主な理由は、推論や理解が難しいシナリオがいくつかあるためです。
まずは Android から始めましょう。Android OS は、プッシュ メッセージをリッスンし、受信すると、アプリが閉じているかどうかにかかわらず、適切な Android アプリを起動してプッシュ メッセージを処理するように設計されています。
これは Android のどのブラウザでもまったく同じです。プッシュ メッセージを受信するとブラウザが起動し、ブラウザがサービス ワーカーを起動して push イベントをディスパッチします。
デスクトップ OS の場合は、もう少し複雑です。Mac OS X には、さまざまなシナリオを説明するのに役立つ視覚的なインジケーターがあるため、Mac OS X で説明するのが最も簡単です。
Mac OS X では、Dock のアプリアイコンの下にあるマークで、プログラムが実行されているかどうかを確認できます。
次のドックにある 2 つの Chrome アイコンを比較すると、左側のアイコンは実行中（アイコンの下にマークが表示されている）ですが、右側の Chrome は実行されていないため、下にマークが表示されていません。
パソコンで push メッセージを受信する場合、ブラウザが実行されているとき（アイコンの下にマークが表示されているとき）にメッセージを受信します。
つまり、ブラウザでウィンドウが開かれていなくても、ブラウザがバックグラウンドで実行されているため、サービス ワーカーでプッシュ メッセージを受信できます。
プッシュ通知が届かないのは、ブラウザが完全に閉じている（つまり、まったく実行されていない）場合のみです（マークなし）。Windows の場合も同様ですが、Chrome がバックグラウンドで実行されているかどうかを判断するのは少し複雑です。
プッシュ通知からホーム画面のウェブアプリを全画面表示で開くにはどうすればよいですか？
Android 版 Chrome では、ウェブアプリをホーム画面に追加できます。ウェブアプリをホーム画面から開くと、以下のように URL バーなしの全画面表示モードで起動できます。
このエクスペリエンスの一貫性を保つため、デベロッパーは、クリックされた通知でもウェブアプリを全画面表示で開くことを望んでいます。
Chrome はこれを「ある程度」実装していますが、信頼性が低く、理由を説明するのが難しい場合があります。関連する実装の詳細は次のとおりです。
つまり、ユーザーがホーム画面のアイコンからかなり定期的にサイトにアクセスしていない限り、通知は通常のブラウザ UI で開きます。
この問題については、今後さらに対応を進めてまいります。
ウェブソケットよりも優れているのはなぜですか？
サービス ワーカーは、ブラウザ ウィンドウが閉じられたときに起動できます。ウェブソケットは、ブラウザとウェブページが開いている間のみ存続します。
GCM、FCM、ウェブプッシュ、Chrome の関係
この質問にはさまざまな側面があり、最も簡単に説明するには、ウェブプッシュと Chrome の歴史をたどることです。（短いのでご安心ください）。
2014 年 12 月
Chrome でウェブプッシュが初めて実装されたとき、Chrome は Google Cloud Messaging（GCM）を使用して、サーバーからブラウザへのプッシュ メッセージの送信を強化しました。
これはウェブプッシュではありませんでした。この初期の Chrome と GCM のセットアップが「真の」ウェブプッシュではなかった理由はいくつかあります。
- GCM を使用するには、デベロッパーが Google Developers Console でアカウントを設定する必要があります。
- Chrome と GCM では、メッセージを正しく設定するために、ウェブアプリで共有される特別な送信者 ID が必要でした。
- GCM のサーバーは、ウェブ標準ではないカスタム API リクエストを受け入れていました。
2016 年 7 月
7 月に、ウェブプッシュの新しい機能であるアプリケーション サーバーキー（仕様では VAPID と呼ばれます）がリリースされました。Chrome でこの新しい API のサポートが追加されたとき、メッセージング サービスとして GCM ではなく Firebase Cloud Messaging（FCM）が使用されました。これは、次の理由から重要です。
- Chrome とアプリケーション サーバーキーでは、Google または Firebase でプロジェクトを設定する必要はありません。問題なく動作します。
- FCM は、すべてのウェブプッシュ サービスがサポートする API であるウェブプッシュ プロトコルをサポートしています。つまり、ブラウザが使用するプッシュ サービスに関係なく、同じ種類のリクエストを行うだけでメッセージが送信されます。
なぜ混乱が生じているのか
ウェブプッシュのトピックについて書かれたコンテンツの多くが GCM または FCM を参照しているため、現在、大きな混乱が生じています。コンテンツで GCM が参照されている場合は、古いコンテンツであるか、Chrome に重点を置きすぎている可能性があります。（私も、古い投稿の多くでこれを行っていました）。
代わりに、ウェブプッシュは、プッシュ サービスを使用してメッセージの送受信を管理するブラウザで構成され、プッシュ サービスは「ウェブプッシュ プロトコル」リクエストを受け入れると考えてください。この観点から考えると、使用しているブラウザやプッシュ サービスを無視して作業を進めることができます。
このガイドは、ウェブプッシュの標準的なアプローチに焦点を当てて作成されており、それ以外のものは意図的に無視しています。
Firebase には JavaScript SDK があります。概要と目的
Firebase ウェブ SDK を見つけて、JavaScript 用のメッセージング API があることに気づいた方は、ウェブプッシュとの違いが気になるかもしれません。
メッセージング SDK（Firebase Cloud Messaging JS SDK）は、ウェブプッシュの実装を容易にするために、バックグラウンドでいくつかの処理を行います。
PushSubscriptionとそのさまざまなフィールドについて心配する必要はなく、FCM トークン（文字列）についてのみ心配する必要があります。- 各ユーザーのトークンを使用して、独自の FCM API でプッシュ メッセージをトリガーできます。この API では、ペイロードを暗号化する必要はありません。POST リクエストの本文で書式なしテキストのペイロードを送信できます。
- FCM 独自の API は、FCM トピックなどのカスタム機能をサポートしています（ウェブでも機能しますが、ドキュメントが不十分です）。
- 最後に、FCM は Android、iOS、ウェブをサポートしているため、一部のチームでは既存のプロジェクトで作業する方が簡単です。
これはバックグラウンドでウェブプッシュを使用しますが、その目的はウェブプッシュを抽象化することです。
前の質問で述べたように、ウェブプッシュをブラウザとプッシュ サービスと見なす場合、Firebase の Messaging SDK はウェブプッシュの実装を簡素化するライブラリと見なすことができます。
次のステップ
- ウェブプッシュ通知の概要
- プッシュの仕組み
- ユーザーの登録
- 権限の UX
- ウェブプッシュ ライブラリを使用したメッセージの送信
- ウェブプッシュ プロトコル
- push イベントの処理
- 通知の表示
- 通知の動作
- 一般的な通知パターン
- プッシュ通知に関するよくある質問
- 一般的な問題とバグの報告