このページは Cloud Translation API によって翻訳されました。

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

Matt Gaunt

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

この質問はよく寄せられます。主な理由は、推論や理解が難しいシナリオがいくつかあるためです。

まず Android から説明します。Android OS は、プッシュメッセージをリッスンするように設計されており、メッセージを受信すると、アプリが閉じているかどうかにかかわらず、適切な Android アプリを起動してプッシュメッセージを処理します。

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

デスクトップ OS では、状況がより微妙になり、Mac OS X では、さまざまなシナリオを説明する視覚的なインジケーターがあるため、説明が最も簡単です。

Mac OS X では、ドックのアプリアイコンの下にマークが表示されることで、プログラムが実行されているかどうかを確認できます。

次のドックに表示されている 2 つの Chrome アイコンを比較すると、左側のアイコンは実行中であることがアイコンの下のマークで示されていますが、右側の Chrome は実行中ではありませんため、下のマークがありません。

パソコンでプッシュメッセージを受信する場合、ブラウザが実行中（アイコンの下にマークがある）ときにメッセージが届きます。

つまり、ブラウザのウィンドウを開いていなくても、ブラウザはバックグラウンドで実行されているため、サービスワーカーでプッシュメッセージを受け取ることができます。

プッシュが受信されないのは、ブラウザが完全に閉じている場合（実行されていない、マークなし）のみです。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 に重点を置きすぎていることを示す兆候として扱う必要があります。（私は古い投稿でこのことを何度もやりました。）

代わりに、ウェブプッシュはブラウザで構成されていると考えてください。ブラウザは push サービスを使用してメッセージの送受信を管理します。push サービスは「ウェブプッシュプロトコル」リクエストを受け入れます。このように考えれば、使用しているブラウザやプッシュサービスは気にせず、すぐに作業を開始できます。

このガイドは、ウェブプッシュの標準的なアプローチに焦点を当てて作成されており、他の方法については意図的に無視しています。

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 を、ウェブプッシュの実装を簡素化するライブラリと見なすことができます。