プッシュ通知に関するよくある質問

ブラウザを閉じるとプッシュが機能しないのはなぜですか？

この質問はかなり増えます。その理由は、推論と理解を困難にするシナリオがいくつかあるためです。

Android から始めましょうAndroid OS は、プッシュ メッセージをリッスンし、メッセージを受信すると、アプリが閉じているかどうかにかかわらず、プッシュ メッセージを処理する適切な Android アプリを復帰させるように設計されています。

これは Android のどのブラウザでもまったく同じです。プッシュ メッセージを受信するとブラウザは起動し、ブラウザは Service Worker を復帰させてプッシュ イベントをディスパッチします。

デスクトップ OS ではより微妙な違いがあり、Mac OS X ではさまざまなシナリオの説明に役立つインジケーターが表示されるため、説明が最も簡単です。

Mac OS X では、ホルダーにあるアプリアイコンの下に表示されるマークで、プログラムが実行中かどうかを確認できます。

次のドックの 2 つの Chrome アイコンを比較すると、左側の Chrome アイコンは動作しています（アイコンの下にマークが表示されます）。一方、右側の Chrome は動作していないため、アイコンの下にマークは表示されません。

OS X の例

パソコンで push メッセージを受信する場合は、ブラウザの実行中に（アイコンの下にマークが付いている）ときにメッセージを受信します。

つまり、ブラウザはバックグラウンドで実行されているため、ブラウザでウィンドウが開いておらず、Service Worker でプッシュ メッセージを受信します。

プッシュを受信できないのは、ブラウザが完全に閉じたとき（まったく実行されていない（マークがない）とき）のみです。Windows の場合も同様ですが、Chrome がバックグラウンドで実行されているかどうかを判断するのは少し厄介です。

ホーム画面のウェブアプリをプッシュで全画面表示にするにはどうすればよいですか？

Chrome for Android では、ウェブアプリをホーム画面に追加して、ホーム画面から開いたときに、以下に示すように URL バーのない全画面モードで起動できます。

ホーム画面のアイコンから全画面表示に変更

このエクスペリエンスの一貫性を保つため、デベロッパーは、通知がクリックされたときにもウェブアプリを全画面で開くようにしたいと考えています。

Chrome はこれを「ある程度」実装していますが、信頼性が低く、判断が難しい場合があります。関連する実装の詳細は次のとおりです。

つまり、ユーザーがホーム画面アイコンから定期的にサイトを訪問しない限り、通知は通常のブラウザ UI で開きます。

この問題には引き続き対応する予定です。

これが WebSocket より優れているのはなぜですか。

ブラウザ ウィンドウを閉じると、Service Worker を起動できます。ウェブソケットは、ブラウザとウェブページが開いている間だけ存続します。

GCM、FCM、Web Push、Chrome ではどう扱われますか？

この質問にはさまざまな側面があります。ウェブプッシュと Chrome の歴史を順を追って説明するのが、最も簡単です。（短いですので、ご安心ください）。

2014 年 12 月

Chrome で初めてウェブプッシュが実装されたとき、サーバーからブラウザへのプッシュ メッセージの送信には Google Cloud Messaging（GCM）が使用されていました。

これはウェブプッシュではありません。Chrome と GCM のこの初期セットアップが「本物」のウェブプッシュではなかった理由はいくつかあります。

  • GCM では、デベロッパーが Google Developers Console でアカウントを設定する必要があります。
  • Chrome と GCM では、メッセージを正しく設定するために、特別な送信者 ID をウェブアプリで共有する必要がありました。
  • GCM のサーバーが、ウェブ標準以外のカスタム API リクエストを受け入れました。

2016 年 7 月

7 月に、ウェブプッシュの新機能として Application Server Keys（仕様として知られている VAPID）がリリースされました。Chrome でこの新しい API のサポートが追加されたとき、メッセージ サービスとして GCM ではなく Firebase Cloud Messaging（FCM）が使用されていました。これは、次のような理由で重要です。

  • Chrome と Application Server Keys は、Google または Firebase での設定にいかなるプロジェクトも必要としません。きちんと機能します。
  • FCM はウェブプッシュ プロトコルをサポートしています。これは、すべてのウェブプッシュ サービスでサポートする API です。つまり、ブラウザが使用している push サービスに関係なく、同じ種類のリクエストを行うだけでメッセージが送信されます。

なぜ混乱を招くのですか？

現在、コンテンツはウェブ push のトピックで記述されており、その多くは GCM または FCM を参照しているため、多くの混乱が生じています。コンテンツが GCM を参照している場合、古いコンテンツであるか、Chrome に重点を置いていることを示す兆候として扱う必要があります。（以前の投稿で何度も同じことをしています）

ウェブプッシュは、プッシュ サービスを使用してメッセージの送受信を管理するブラウザで構成され、プッシュ サービスは「ウェブ push プロトコル」リクエストを受け入れます。これらの用語について考える場合は、どのブラウザとどの push サービスを使用しているかを無視して作業を開始できます。

このガイドでは、ウェブプッシュの標準的なアプローチに焦点を当て、それ以外は意図的に無視しています。

Firebase には JavaScript SDK が含まれています。内容とその理由

Firebase Web SDK を見つけ、JavaScript 用のメッセージング API があることに気付いた方々は、ウェブ push とどのように違うのか疑問に思われるかもしれません。

メッセージング SDK（Firebase Cloud Messaging JS SDK）には、ウェブプッシュを簡単に実装できるように、裏でいくつかのトリックがあります。

  • PushSubscription とそのさまざまなフィールドについて考慮する代わりに、FCM トークン（文字列）について考慮するだけで済みます。
  • 各ユーザーのトークンを使用して、独自の FCM API で push メッセージをトリガーできます。この API では、ペイロードを暗号化する必要はありません。POST リクエストの本文で書式なしテキストのペイロードを送信できます。
  • FCM 独自の API は、FCM Topics などのカスタム機能をサポートしています（ウェブでも機能しますが、あまりドキュメント化されていません）。
  • 最後に、FCM は Android、iOS、ウェブをサポートしているため、チームによっては既存のプロジェクトでの作業が容易になります。

これは背後でウェブプッシュを使用していますが、その目的は抽象化することです。

前の質問で述べたように、ウェブプッシュを単なるブラウザとプッシュ サービスと見なすと、Firebase の Messaging SDK をウェブプッシュの実装を簡素化するためのライブラリと考えることができます。

次のステップ

Codelab