PWA が公開されています。ブラウザから使用するユーザーと、アプリをインストールするユーザーがいます。アプリをアップデートする際は、問題を回避するためのおすすめの方法を実践することが重要です。
以下を更新できます。
- アプリのデータ] をタップします。
- アセットがすでにデバイスにキャッシュされている。
- Service Worker ファイル、またはその依存関係。
- マニフェスト メタデータ。
各要素のベスト プラクティスを確認しましょう。
データを更新する
IndexedDB に保存されているデータなどのデータを更新するには、Fetch API、WebRTC、WebSocket API などのツールを使用できます。アプリがオフライン機能をサポートしている場合は、その機能をサポートするデータも常に更新しておく必要があります。
互換性のあるブラウザでは、ユーザーが PWA を開いたときだけでなく、バックグラウンドでもデータを同期できます。オプションは次のとおりです。
- バックグラウンド同期: 失敗したリクエストを保存し、Service Worker からの同期を使用してリクエストを再試行します。
- ウェブの定期的なバックグラウンド同期: データをバックグラウンドで定期的に（特定の時間に）同期します。これにより、ユーザーがまだアプリを開いていない場合でも、アプリは更新されたデータを提供できます。
- バックグラウンド取得: PWA が閉じている場合でも、サイズの大きいファイルをダウンロードします。
- ウェブプッシュ: サーバーからメッセージを送信し、Service Worker を復帰させ、ユーザーに通知します。これは一般に「プッシュ通知」と呼ばれます。この API にはユーザーの権限が必要です。
これらの API はすべて、Service Worker のコンテキストから実行されます。現在のところ、Chromium ベースのブラウザ、Android、パソコンのオペレーティング システムでのみご利用いただけます。これらの API を使用すると、Service Worker スレッドでコードを実行できます。たとえば、サーバーからデータをダウンロードしたり、IndexedDB データを更新したりできます。
アセットの更新
アセットの更新には、アプリのインターフェースのレンダリングに使用するファイル（HTML、CSS、JavaScript、画像など）に対する変更が含まれます。たとえば、アプリのロジックの変更、インターフェースの一部である画像、CSS スタイルシートの変更などです。
更新パターン
以下に、アプリのアップデートを処理する一般的なパターンを示します。ただし、このプロセスは必要に応じていつでもカスタマイズできます。
- 完全更新: たとえ小さな変更であっても、すべての変更でキャッシュ コンテンツ全体が置き換えられます。このパターンは、デバイス固有のアプリによる更新の処理方法を模倣しています。このため、帯域幅の消費が増え、処理に時間がかかります。
- 変更されたアセットの更新: 前回の更新以降に変更されたアセットのみがキャッシュで置き換えられます。多くの場合、Workbox などのライブラリを使用して実装されます。これには、キャッシュされたファイルのリスト、ファイルのハッシュ表現、タイムスタンプの作成が含まれます。この情報を使用して、Service Worker はこのリストとキャッシュに保存されたアセットを比較し、更新するアセットを決定します。
- 個々のアセットの更新: 各アセットは、変更されると個別に更新されます。配信のチャプターで説明されている「古い再検証戦略」は、アセットを個別に更新する例です。
更新のタイミング
もう 1 つのおすすめの方法は、アップデートを確認して適用するのにおすすめの方法です。次のような選択肢があります。
- Service Worker が復帰したとき。この時点でリッスンするイベントはありませんが、ブラウザは起動時に Service Worker のグローバル スコープ内のコードを実行します。
- PWA のメイン ウィンドウのコンテキストで、ブラウザがページを読み込んだ後に、アプリの読み込みが遅くならないようにします。
- PWA がプッシュ通知を受信したり、バックグラウンド同期が開始されたりしたときなど、バックグラウンド イベントがトリガーされたとき。キャッシュを更新すると、ユーザーが次にアプリを開いたときにアセットの新しいバージョンが表示されます。
リアルタイムの最新情報
アプリが開いている（ライブ）ときや閉じているときにアップデートを適用するかどうかも選択できます。アプリを閉じるアプローチでは、アプリが新しいアセットをダウンロードしても、変更が加えられることはなく、次の読み込みでは新しいバージョンが使用されます。
ライブ アップデートでは、キャッシュでアセットが更新されるとすぐに、現在の読み込みで PWA によってアセットが置き換えられます。これは複雑なタスクであり、このコースでは説明しません。この更新の実装に役立つツールとして、livereload-js や CSS アセット更新 CSSStyleSheet.replace() API があります。
Service Worker の更新
Service Worker またはその依存関係が変更されると、ブラウザによって更新アルゴリズムがトリガーされます。ブラウザは、キャッシュされたファイルとネットワークから送られるリソースをバイト単位で比較して更新を検出します。
Service Worker の章で説明されているように、ブラウザは新しいバージョンの Service Worker をインストールしようとし、新しい Service Worker は待機状態になります。新しいインストールでは、新しい Service Worker の install イベントが実行されます。そのイベント ハンドラでアセットをキャッシュに保存している場合、アセットも再キャッシュに保存されます。
Service Worker の変更の検出
新しい Service Worker の準備ができてインストールされたことを検出するには、Service Worker 登録の updatefound イベントを使用します。このイベントは、新しい Service Worker がインストールを開始すると発生します。statechange イベントで状態が installed に変わるまで待つ必要があります。以下をご覧ください。
async function detectSWUpdate() {
const registration = await navigator.serviceWorker.ready;
registration.addEventListener("updatefound", event => {
const newSW = registration.installing;
newSW.addEventListener("statechange", event => {
if (newSW.state == "installed") {
// New service worker is installed, but waiting activation
}
});
})
}
強制オーバーライド
新しい Service Worker はインストールされますが、デフォルトではアクティベーションを待機します。この待機により、新しいバージョンと互換性のない古いクライアントが新しい Service Worker に引き継がれるのを防ぐことができます。
推奨されませんが、新しい Service Worker はこの待機時間をスキップして、すぐにアクティベーションを開始できます。
self.addEventListener("install", event => {
// forces a service worker to activate immediately
self.skipWaiting();
});
self.addEventListener("activate", event => {
// when this SW becomes activated, we claim all the opened clients
// they can be standalone PWA windows or browser tabs
event.waitUntil(clients.claim());
});
controllerchange イベントは、現在のページを制御する Service Worker が変更されると起動されます。たとえば、新しいワーカーが待機をスキップして、新しいアクティブ ワーカーになったとします。
navigator.serviceWorker.addEventListener("controllerchange", event => {
// The service worker controller has changed
});
メタデータの更新
また、主にウェブアプリ マニフェストで設定されているアプリのメタデータを更新することもできます。たとえば、アプリのアイコン、名前、開始 URL を更新するか、アプリのショートカットなどの新機能を追加します。 では、古いアイコンのアプリをデバイスにすでにインストールしているすべてのユーザーはどうなりますか？アップデートはいつ、どのように提供されますか？
その答えはプラットフォームによって異なります。利用可能なオプションを見ていきましょう
Safari（iOS、iPadOS、Android ブラウザ）
このようなプラットフォームでは、新しいマニフェスト メタデータを取得する唯一の方法は、ブラウザからアプリを再インストールすることです。
をご覧ください。Android 版 Google Chrome（WebAPK）
ユーザーが WebAPK を有効にした状態で Google Chrome を使用して Android に PWA をインストールすると（ほとんどの Chrome PWA インストール）、アルゴリズムに基づいて更新が検出され、適用されます。詳しくは、マニフェストの更新に関する記事をご覧ください。
このプロセスに関するその他の注意事項:
ユーザーが PWA を開かない場合、WebAPK は更新されません。 サーバーがマニフェスト ファイルを返さない場合（404 エラー）、ユーザーが PWA を開いても少なくとも 30 日間は更新の確認が行われません。
Android 版 Chrome で about:webapks にアクセスして、「更新が必要」のステータスを確認します更新をリクエストします。このデバッグツールの詳細については、ツールとデバッグの章をご覧ください。
Android 版 Samsung インターネット（WebAPK）
手順は Chrome のバージョンと同様です。この場合、PWA マニフェストの更新が必要な場合、24 時間以内に更新された WebAPK を作成した後、Wi-Fi 上で WebAPK が更新されます。
パソコンの Google Chrome と Microsoft Edge
デスクトップ デバイスでは、PWA の起動時に、ブラウザが最後にローカル マニフェストの変更をチェックした時刻を確認します。ブラウザが最後に起動してからマニフェストが確認されていない場合、または過去 24 時間以内にマニフェストがチェックされていない場合、ブラウザはマニフェストに対してネットワーク リクエストを行い、ローカルコピーと比較します。
選択した宿泊施設が更新されると、すべての時間枠が終了した後に更新がトリガーされます。
ユーザーへのアラート
一部の更新戦略では、クライアントからの再読み込みまたは新しいナビゲーションが必要になります。更新が待機中であることをユーザーに知らせるとともに、ユーザーが最も都合が良いときにページを更新できるようにします。
お客様に伝えるには、次の方法があります。
- DOM または canvas API を使用して、画面に通知を表示します。
- Web Notifications API を使用する。この API は、オペレーティング システムで通知を生成する push 権限の一部です。サーバーからプッシュ メッセージング プロトコルを使用していない場合でも、使用するにはウェブプッシュ権限をリクエストする必要があります。PWA が開いていない場合は、これが唯一の選択肢となります。
- Badging API を使用して、PWA のインストール済みアイコンでアップデートが利用可能であることを示します。
。
Badging API の詳細
Badging API を使用すると、PWA のアイコンにバッジ番号または対応ブラウザ上のバッジドットをマークできます。バッジドットは、インストール済みのアイコン内にある小さなマークで、アプリ内で何かが待っていることを表します。
バッジ番号を設定するには、navigator オブジェクトの setAppBadge(count) を呼び出す必要があります。これは、ユーザーにアラートを通知する更新があることがわかっている場合に、ウィンドウまたは Service Worker のコンテキストから実行できます。
let unreadCount = 125;
navigator.setAppBadge(unreadCount);
バッジを消去するには、同じオブジェクトで clearAppBadge() を呼び出します。
navigator.clearAppBadge();