プッシュ通知
expsh13プッシュ通知
種類
- ローカル通知
ローカル通知は、既に起動している (もしくは起動していた) アプリケーションからプッシュ通知を送るものです。これは、インターネットに接続していなくても利用できます。身近なものだと、アラームアプリで時間になったら通知されるのがこれにあたります。 - リモート通知
リモート通知は、インターネットに接続していなければ受け取れません。
身近なものだと、チャットのメッセージ通知がこれにあたります。
リモート通知の仕組み
リモート通知を送りたい場合、端末と直接コネクションを貼るのではなく、Apple や Google が提供するプッシュ通知サーバーに対してプッシュ通知を送信することを依頼します。Apple は APNs (Apple Push Notification service)、Google は GCM/FCM というサービス名でプッシュ通知サービスを提供しています。APNs や GCM/FCM は端末との TCP コネクションを貼っており、プッシュ通知の配信を一括して代行しています。
Apple や Google が提供するこれらのサービスを直接利用する方法がひとつの方法です。他には、これらのプッシュ通知のサーバーを一段ラップした API を提供するサービスを使う方法があります。
Firebase によるリモート通知
リモート通知を行うには、Google が公式に提供している Firebase Cloud Message (FCM) を使うのが便利です。Android に対しては直接プッシュ通知を配信、iOS 端末に対しても APNs 経由で配信ができます。
要素
APNs
Appleが提供しているPush通知基。
ユーザー端末へのPush通知の送信はここを介して行われる
Production環境とSandbox環境がある
Production環境からは、本番用証明書で配布されたアプリにのみ通知を送信できる
開発時はSandbox環境を用いることで、誤送信のリスクを最小化することができる
デバイストークン
プッシュ通知の送信対象端末を一意に識別するもの
クライアントアプリからAPNsに対してリクエストを行うことで取得できる
下記の特徴があるため、サーバーサイドではユーザーに対して複数紐付けられるようにしておくのが良い
端末が変わると別のトークンになる
アプリやOSの再インストールによって別のトークンになる
バックアップからの復元時に別のトークンになる
ログアウト済みユーザーに間違って通知を送ってしまうことを避けるため、ログアウト時にはトークンの削除も必要
証明書 or 暗号化キー（トークン）
APNsにプッシュ通知の送信をリクエストする際に必要となるもの
Apple Developerアカウントかから作成することができ、以下のような違いがある
証明書
アプリごとに生成
1年に1度更新が必要
交換によるダウンタイムなし（複数の証明書を作成可能であるため）
暗号化キー（トークン）
チームで共通（全アプリで共通）
更新が必要ない
交換によるダウンタイムあり（再生成時にダウンタイムが生まれる）
現在は暗号化キーを用いた方式が推奨されている
フロー
-
クライアントアプリ側で通知の許諾ダイアログを表示する。通知APIを使用して行う。これにより、OS の通知システムを使用した通知の表示が可能になる。
※ あくまで「表示」の許諾なので、バックグラウンドプッシュだけを利用する場合は必要ない -
APNsへのデバイス登録を行い、デバイストークンを受け取る
-
デバイストークンをバックエンドサーバーに送信しユーザーに紐づける
-
バックエンドサーバーは通知を送信したいタイミングで、ユーザーに紐づくデバイストークンを用い、APNsに通知の送信リクエストを行う
※ この際、アプリのBundleIDやAPNsの環境（production/sandbox）などを指定することで、通知対象をコントロールできる
expsh13PWA
プログレッシブウェブアプリ (Progressive web apps, PWA) は、ウェブプラットフォーム技術を使用して構築されたアプリですが、プラットフォーム専用のアプリのような使い勝手を提供します。
PWA はウェブサイトのように、単一のコードベースから複数のプラットフォームや端末で動作することができます。プラットフォーム専用のアプリのように、端末にインストールし、オフラインやバックグラウンドで処理し、端末や他にもインストールされているアプリと統合することができます。
PWA は通常、プラットフォーム専用のアプリのように見え、ブラウザー UI がない状態で表示されますが、技術的にはウェブサイトです。これは、Chrome や Firefox のようなブラウザーエンジンが管理し実行する必要があるということです。プラットフォーム専用のアプリでは、プラットフォーム OS がアプリを管理し、実行する環境を提供します。PWA では、ブラウザーエンジンは通常のウェブサイトと同じように、このバックグラウンドの役割を果たします。
少なくとも 1 枚の HTML ページがあり、おそらくいくらかの CSS と JavaScript を読み込んでいます。
それに加えて、PWA にはいくつかの追加機能があります。
- ウェブアプリマニフェストファイル。少なくとも、ブラウザーが PWA をインストールするために必要な情報（アプリ名やアイコンなど）を提供します。
- オプションとして、オフライン操作を提供するサービスワーカー。
PWAにサービスワーカーをインストールすることは必須ではありませんが、少なくとも最低限のオフライン操作を提供するために、PWAと共にサービスワーカーが使用されることがよくあります。
サービスワーカーは、アプリのページ、つまりウェブサイトの従来の部分がユーザーインターフェイスを実装し、サービスワーカーがオフラインとバックグラウンド処理に対応するバックエンドを実装するアーキテクチャを推奨しており、PWA をウェブサイトよりもアプリに近い挙動にします。これは、サービスワーカーが必要な時に（例えばプッシュ通知を処理するために）バックグラウンドでブラウザーによって開始できるからです。
https://developer.mozilla.org/ja/docs/Web/Progressive_web_apps