今回は有名どころのWebフロントエンドフレームワークにおけるPWAの導入方法です。結論から言えば、新規アプリであれば導入は難しくなさそうです。
Angular
Angular CLIを使うのが基本です。まずAngular CLIをインストールします。
ついでAngularアプリを作成します。
そして作成したAngularアプリの中で、 @angular/pwa を追加します。
これでPWA対応が完了します。なお、開発用サーバの時点ではmanifest.jsonは確認できません。 ng build でビルドする必要があります。
React
幾つかのテンプレートがPWAに対応しています。一番手軽なものとしては、 create-react-app コマンドによるものです。
これで使えるようになる create-react-app コマンドで作ったReactアプリはPWAに対応しています。
これでPWAが使えるReactアプリができあがっています。なお、yarn start 、 yarn build のどちらでもmanifest.jsonが生成されています。
他にもpaulhoughton/react-pwaやpaulhoughton/preact-pwa、localnerve/react-pwa-referenceといったテンプレートが作られています。
Vue
VueはVue CLIを使ってアプリを作成することが多いでしょう。
まずプロジェクトを作成します。
プロジェクト内で vue add を実行します。
これでPWA対応が完了です。なお、Vueアプリの場合も開発サーバではmanifest.jsonが確認できません。ビルドした際だけ表示されます。
最近のWebフレームワークであれば、PWA対応はとても簡単になっています。バージョンが古いこともある既存のプロジェクトにおいては導入は難しそうですが、新規開発であればPWAの導入はさほど難しくないでしょう。
PWAで一番厄介な問題と言えばキャッシュではないでしょうか。開発中などで、キャッシュを更新したい時にできなかったり、キャッシュを読み込んでしまって修正が反映されずにバグ解決に時間を取られるかも知れません。
そこでちょっとしたTipsを紹介します。
Service Worker登録時の工夫
それは registration.onupdatefound を仕込んでおくということです。このメソッドはService Workerが更新されているかどうかを検知してくれます。もし更新されている場合は、updateメソッドを使って更新できます。
ボタンで更新する
キャッシュをクリアしたい時のためにボタンを用意しておきましょう。unregisterメソッドを使えば一旦Service Workerを解除してくれるので、再読み込みすれば改めて登録し直してくれます。
キャッシュされているスクリプトなどを更新する
Service Workerを使っている場合、JavaScriptやスタイルシートの変化を検知してアップデートする方法は恐らくなさそうです。何らかのアクションが必要になります。
例えばボタンを使う場合には以下のように、Service Worker側にメッセージを送ります。
そしてService Worker側でキャッシュを取得し直します。やっていることはインストール時と同じです。
これでキャッシュの読み込み直しが完了します。ボタンを押さなくとも強制的に取得し直すといった仕組みでも良いかと思いますが、特定のURL（コンテンツなど）に限ったり、Service Workerが更新された時に限ると言った工夫は必要でしょう。
キャッシュによって表示を高速化するService Workerですが、使い方を間違えるとユーザビリティが大きく損なわれる可能性があります。キャッシュすべきコンテンツとしない方が良いコンテンツを見極めて、上手に運用しましょう。
サイトがPWAに正しく対応しているかどうか計測する際にはGoogle Chrome拡張のLighthouseを使うのが基本です。今回はProgressive Web App Checklistで提示されているPWAのチェックリストに沿って、どういった項目がチェックされているのかを紹介します。
HTTPSになっているか
WebサイトがHTTPSに対応しているか、さらにHTTPにアクセスした際にリダイレクトするかチェックします。
タブレットやスマートフォンに対してレスポンシブに対応しているか
スマートフォン向けにデザインを変えるのではなく、レスポンシブWebデザインであることが基本です。
アプリに関係するURLがすべてオフラインに対応しているか
トップページだけPWAといった状態ではなく、クリック先も含めてPWA対応しているかが問われます。
Add to Home Screenに対応したメタ情報が指定されているか
いわゆるmanifest.jsonに絡んだ話です。アプリ名やアイコンなどが指定されている必要があります。
3G環境でも10秒以内に表示されるか
遅いサイトはPWAとして不向きです。3G環境でもユーザにストレスを与えない速度での表示が求められます。
クロスブラウザで動作するか
Google Chromeだけでなく、Firefox/Safari/Edgeにも対応している必要があります。
ページ遷移がネットワークをブロックしていないか
ページ遷移時のアニメーションによって表示がもたつかないことを求められます。
すべてのページがURLを持っているか
URLがユニークになっており、そのURLにアクセスした際に適切な情報が表示されることが望まれます。
高度な制約
さらに細かく見ていきます。これらはLighthouseでチェックできないものもあります。
サイトがGoogleでインデックス化されているか
Googleのインデックス状況をチェックして、すべてのページが望ましくインデックス化されている必要があります。
Schema.orgで定義されているメタデータが設定されているか
インデックス化に関係しますが、必要なメタデータが設定されていなければなりません。
FacebookやTwitterなどのOpen Graphが設定されているか
シェアされる際に必要なOGPが設定されているか確認されます。
Canonical URLが設定されているか
pwaでは独自のクエリ、ハッシュタグを設定することがあります。そのためCanonical URLによってシェアするURLが指定されていることが望ましいです。
History APIを使っているか
ページ遷移に物理ボタンやキーボードショートカットでも対応するHistory APIが使われている必要があります。
ページ遷移が滑らかに行われているか
ページ読み込みが再度全コンテンツのレンダリングではなく、スムーズなアニメーションによって行われているのが望ましいです。
リストページから詳細ページに移動してバックボタンを押した時、リストを再現して表示されるか
History APIに関連しますが、リストの最上部に戻るのではなく、クリックした場所に戻ってくるのが望ましいです。
キーボードがテキスト入力欄を覆ってしまわないか
ソフトウェアキーボードを表示した際に入力欄を隠してしまわないように注意しましょう。
コンテンツが容易にシェアできるか
Web Share APIを使ったりして、コンテンツのシェアが手軽にできるのが望ましいです。
アプリのインストールプロンプトが過剰ではないか
PWAとしてアプリインストールは必要ですが、それが過剰になっているとユーザビリティが下がります。
キャッシュが使われてるか
Service Workerによるキャッシュを効率的に使って、高速な表示を実現します。
プッシュ通知の送る内容などをユーザに提示しているか
プッシュ通知はスマートフォンアプリと同様、否応なく表示されるべきではありません。
プッシュ通知の有効化を過度に求めていないか
こちらも上記と同様です。
プッシュ通知は関連性があり、タイムリーかつ正確なものになっているか
送る内容に関する注意喚起です。
プッシュ通知をオフにする方法を提供しているか
オフにする方法が提示されていないことが多く、ユーザを混乱させるでしょう。
Credential Management APIを提供しているか
認証のAPIです。
Payment Request APIを提供しているか
決済のAPIです。Eコマースなどでは必須でしょう。
ここに挙げたものはベースラインとなっています。プッシュ通知などは運用にまで踏み込んだ内容になっています。ぜひ全体をチェックリストとして、ユーザビリティの高いPWAを目指してください。
PWA（Progressive Web App）では manifest.json というファイルが肝になります。このファイルの有無と Service Worker 、そして manifest.json の記述内容によってアプリとしてインストールできるようになります。
今回は manifest.json の中でも、ぜひ知っておきたい設定を紹介します。
テーマカラーが指定できる
アドレスバーの部分をブランドに合わせたカラーリングにできます。
metaタグで <meta name="theme-color" content="#317EFB"/> といった形で指定するか、 manifest.json で theme_color を指定します。
最初に表示するURLを指定できる
manifest.json にて start_url として最初に表示するURLを指定できます。例えば index.html?pwa=true として、JavaScriptでパラメータを読み込むことで、PWA専用の画面構成に作り替えるといった操作もできます。
起動時のスプラッシュスクリーンが指定できる
manifest.json にて background_color を指定し、かつ 512x512pxのアイコン（PNG）を指定することで、起動時にスプラッシュスクリーンが表示できます。
ホーム画面にアイコンを設置できる
manifest.json の icons にて192x192pxのアイコンを用意するのがベストとされています。Webサイトをアプリのようにインストールすると、その際のアイコンとして使われます。
背景色が指定できる
manifest.json の background_color にてコンテンツが表示されるまでの背景色を指定できます。起動時にはスプラッシュスクリーンが表示され、その後最初の表示が行われるまでの画面遷移がスムーズになります。
アプリ名が決められる
manifest.json の name にてアプリとしてインストールされた際の名前を指定できます。なお、iOSでは名前はデフォルトであり、ユーザが変更できます。 name が長い場合には short_name を代替として利用します。
起動方法を指定できる
manifest.json の display にてアプリの立ち上げ方を決められます。 fullscreen 、 standalone 、 browser の3パターンがあります。
manifest.json の設定によって、インストールされる際の細かな挙動を変更できます。よりアプリらしく、よりユーザビリティの高い仕組みを提供するためにカスタマイズしてください。
新しく追加された構文のfor/ofですが、for/inとの違いが分かりづらく、間違えてしまう人は多いのではないでしょうか。そこで実行結果を含めて使い分ける場面を紹介します。
ハッシュの場合
ハッシュの場合、ofは使えません。そのため、inだけです。
このようにデータを取り出せます。返ってくるのはキー部分になります。
どうしても of を使いたい場合は Object.keys を使う方法があります。
配列の場合
配列はin/of両方使えますが、返ってくる値が異なるので注意が必要です。
inだとキーが返ってきます。
of だと値が返ってきます。
昔ながらのやり方は以下のような感じでしょう。
さらに forEach も用意されています。こちらは of と同じ挙動です。
もしキーと値を両方取りたい時には ary.entries() が使えます。
of は本来、イテレーションを順番に実行するためのものです。配列もイテレーションですが、in/ofの使い分けが難しいので使わない方が安全かも知れません。安全な使い方としては、配列もハッシュもinを使ってキーを受け取りつつ、yieldを使った明確なイテレーションのみofを使うといった使い分けになるでしょう。
現在のHTML5ではvideoやaudioタグを使って動画、音楽などを再生できるようになっています。しかし、これらのデータはストリーミングで流したり、getUserMediaを使って取得することしかできませんでした。
そこで登場したのが Recording a media elementです。これは video/audioタグの内容をレコーディングし、ファイルとしてダウンロードもできるAPIになります。
使い方
まずHTMLを記述します。videoタグを使います。 #startButton を押すとWebカメラの映像をストリーミングで流します。
さらに記録した内容を表示するDOMを用意します。
JavaScriptの処理
まず必要なDOMを変数化します。最後の recordingTimeMS は録画を行うタイミングで、今回は5秒ごとにしています。細かければ動画が滑らかになりますが、CPU負荷も大きくなります。
開始した際の処理
まず開始時の処理について解説します。最初はgetUserMediaを使ってWebカメラにアクセスします。そして、映像を #preview に表示します。そして、 preview.captureStream を使って記録を開始します。
レコーディング中は非同期処理になるので startRecording という関数の中で処理を行っています。 MediaRecorder のインスタンスにWebカメラの映像を指定し、 start メソッドを実行するとレコーディングが開始されます。レコーディング内容は ondataavailable メソッドで呼び出されるので、これを変数に残し続けます。
レコーディングが終わると onstop が呼ばれます。今回は lengthInMS で自動的に停止するようにしています。
また、プレビューを停止する場合には次のように実装することもできます。
デモ
ここまでの実装をJSFiddleにてデモできます。なお、執筆時点ではChromeとMozillaでしか動作しません。
動画リソースはWebカメラに限らず使えるでしょう。そうした時に特定の場所だけキャプチャするといった用途でも使えそうです。動画を編集するという目的にしてはCPU負荷が大きそうですが、動画コンテンツをより扱いやすくしてくれそうです。
PWAは幾つかの技術要素で構成されますが、その基本とも言えるのがService Workerです。Service Workerがなければオフライン対応もアプリとしてのインストール、プッシュ通知もできません。なお、Service WorkerはWebブラウザとは別なプロセスのJavaScriptとして実行されます。
今回はそんなService Workerとフロントエンド側とでメッセージを送受信する方法を紹介します。
WebブラウザからService Workerを呼び出し
Service WorkerはWebサイトにアクセス時にインストールされます。次に訪問した際に更新されているかチェックするのですが、1日程度はキャッシュされるようです。そのためキャッシュする内容を逐次変えたいと言った時にハードコーディングされていると不便です。
そこでWebブラウザからメッセージを送る方法を覚えておきましょう。port2に送るのがコツです。
Service Worker側では message イベントとして呼び出されます。
Service WorkerからWebブラウザを呼び出し
プッシュ通知を受け取った際など、Webブラウザ側にメッセージを送ることで表示を変えると言った効果が考えられます。
まず Service Worker側でメッセージを送りますが、Service Workerの場合はイベントが発生しないと実行できません。例えば push イベント時にメッセージを送る場合です。
そしてWebブラウザ側では port1 にメッセージが届きます。
WebブラウザからService Workerに対してメッセージを送る場合には port2 、逆の場合は port1 に来ると覚えておくと良いでしょう。Service Workerをよりダイナミックに活用したい時に覚えておくと良さそうです。
