コンテンツへ移動

for in/ofの使い分け

新しく追加された構文のfor/ofですが、for/inとの違いが分かりづらく、間違えてしまう人は多いのではないでしょうか。そこで実行結果を含めて使い分ける場面を紹介します。

ハッシュの場合

ハッシュの場合、ofは使えません。そのため、inだけです。

このようにデータを取り出せます。返ってくるのはキー部分になります。

どうしても of を使いたい場合は Object.keys を使う方法があります。

配列の場合

配列はin/of両方使えますが、返ってくる値が異なるので注意が必要です。

inだとキーが返ってきます。

of だと値が返ってきます。

昔ながらのやり方は以下のような感じでしょう。

さらに forEach も用意されています。こちらは of と同じ挙動です。

もしキーと値を両方取りたい時には ary.entries() が使えます。


of は本来、イテレーションを順番に実行するためのものです。配列もイテレーションですが、in/ofの使い分けが難しいので使わない方が安全かも知れません。安全な使い方としては、配列もハッシュもinを使ってキーを受け取りつつ、yieldを使った明確なイテレーションのみofを使うといった使い分けになるでしょう。

for…of – JavaScript | MDN

 

video/audioタグの映像を記録するRecording a media elementの紹介

現在の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負荷が大きそうですが、動画コンテンツをより扱いやすくしてくれそうです。

Recording a media element – Web APIs | MDN

PWAの基礎知識(その10)「Service Workerとのメッセージ送受信」

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をよりダイナミックに活用したい時に覚えておくと良さそうです。

PWAの基礎知識(その9)「Push API/VAPID編」

Webブラウザにプッシュ通知を送れるPush APIは魅力的な機能ですが、各ブラウザによって実装が異なっていたり、Firebaseでプロジェクトを登録したりするのが手間でした。それを共通化し、さらにプロジェクト登録不要で使えるようにする仕組みがVAPIDになります。

今回はこのVAPIDを使ったPush APIの使い方です。

必要なもの

今回はVAPIDに対応したライブラリ、web-pushを使います。今回はNode.jsのライブラリです。zaru/webpushというRuby向けのライブラリもあります。

初期設定

まずサーバ側で秘密鍵と公開鍵を用意します。これは以下のコードで可能です。

この内容を application-server-keys.json などとしてサーバに保存しておきます。

JavaScriptの準備

Service Worker

VAPIDを使った場合の魅力として、ペイロードが送れるという点が挙げられます。メッセージ付きで送れるので、クライアントサイドで処理判別ができます。そのための処理をService Worker用のJavaScriptに入れておきます。

クライアントサイド

次にクライアントサイドですが、まずService Workerを読み込みます。そして、その後プッシュ通知の登録状態を確認しています。

購読を開始する際のイベントは次の通りです。大事なポイントとして、 applicationServerKey を追加しています。ここには公開鍵をunit8にしたものを適用します(後述)。

公開鍵の設定です。 vapidPublicKey には web-push で生成した公開鍵を指定します。

Web Pushの購読データ(subscription)をJSON出力すると、次のような内容になっています。このデータをすべて保存しておきます(サーバなど)。

Web Pushを送る

ではサーバからプッシュ通知を送ってみましょう。コードは以下のようになります。まず鍵の設定と受信者を指定します。

そしてプッシュ通知を送ります。 icon で表示するアイコンを指定しています。

そしてGoogle ChromeやFirefoxに対して通知が送れます。

Firefoxの場合です。


VAPIDを使った場合の利点としては、Firebaseでプロジェクトを作る手間がなく、Webブラウザの共通仕様の基で開発できるということです。なお、Safariはこの仕様に則っていない(そもそも独自仕様)ので、対応できません。

PWAの基礎知識(その8)「Push API/Chrome編」

PWAを構成する技術要素の一つにプッシュ通知があります。Push APIがそうで、該当URLを開いていなくても通知を受けられる仕組みです。

Push APIには幾つかの実装方法がありますが、今回はFCM/GCMを使ったGoogle Chrome向けの実装を紹介します。

Firebaseでプロジェクトを作成する

FCMを使うので、まず最初にFirebaseでプロジェクトを作成します。

作成した後、ウェブアプリにFirebaseを追加を選択します。

そして表示されるモーダルの中に messagingSenderId という項目があります。これを覚えておきます。

さらにプロジェクトの設定を選び、クラウドメッセージングを選びます。

その中に表示される、サーバーキーも覚えておきます。

必要な技術

Push APIを使う際に必要なのはService Workerになります。

manifest.jsonの作成

manifest.jsonを作成します。内容は例えば以下のようになります。 YOUR_SENDER_ID となっているところは先ほどの messagingSenderId の値になります。

serviceworker.js の作成

Service Worker用のJavaScriptファイルを作成します。 serviceworker.js とします。今回は簡単な内容にしています。最低限必要なのは install と push イベントになります。

HTMLの記述

HTMLではmanifest.jsonを読み込みます。

JavaScriptの記述

初期化

まずPush通知が使えるかどうか、さらに購読中かどうかを判別します。以下のようなコードで順番に確認できます。

購読処理

次に購読処理を書きます。これは何かのボタンを押したタイミングなどで実行すれば良いでしょう。

プッシュ通知の送り方

上記のコードで取得できる subscription には以下のような内容が入っています。

  • endpoint
  • expirationTime
  • options
  • options.applicationServerKey
  • options.userVisibleOnly

今回のようなFCMから送信する場合に必要なのは endpoint になります。例えば以下のような値です。

そして、この対象に対してプッシュ通知を送るには以下のようなコマンドを実行します。 YOUR_API_KEY となっているのは Firebase で取得したサーバキーになります。

registration_idsのところに配列でendpointとして取得したトークンを指定すればOKです。

受信する

プッシュ通知を受信すると通知バナーが表示されます。このメッセージは Service Worker側で固定していますが、サーバにfetchで問い合わせてデータ取得することも可能です。登録IDが必要な場合は、以下のコードをService Worker内で実行します。

注意点

Push APIはタブを閉じていても(そのURLがアクティブでなくとも)表示されます。ただしGoogle Chromeを終了していたら届きませんので注意してください。Webブラウザを再開すると通知が表示されます。この方式の場合、表示させるメッセージをプッシュ通知側から送ることはできません。データが送れるのは VAPID という方式を使った場合になります。

この方法はGoogle Chrome独自の方式になります。手軽に実装できますが、FirefoxやEdgeなどでは使えませんのでご注意ください。


今回の方式の場合、サーバ側の用意は殆どいりません。取得した登録IDをサーバ側に入れておくだけで大丈夫です。保存する際に任意のユーザIDと結びつけておくことで、プッシュ通知で表示する内容をカスタマイズできるでしょう。

PWAの基礎知識(その7)「Web App Manifestを提供する上で知っておくと良いこと」

PWA(Progressive Web App)という単語がトレンドになっています。PWAは特定の技術を指す言葉ではなく、様々な技術が組み合わさったスマートフォンにおけるWebアプリのベストプラクティスと言えます。

今回はそんなPWAの基礎になる、Web App Manifestを作る時に便利なテクニックを紹介します。

Web App Manifestとは?

Web App ManifestはWebアプリをスマートフォンアプリのようにインストールできる技術です。アプリストアを経由せずに配布できるのが魅力です。

インストール数を知る

どれくらいのPWAアプリが使われているか、それは皆さんが知りたいことだと思います。この時使えるのはGoogleアナリティクスです。例えば、manifest.jsonのstart_urlを次のように指定します。

こうすることでGoogle Analyticsを使って、起動数を測定可能になります。

PWAの場合だけ表示を変える

Webブラウザから使った場合と、PWAとして立ち上げた場合で表示を変えたいこともあるでしょう。PWAではオフラインで使うことも想定してキャッシュされるので、サーバサイドでの表示出し分けはよくありません。そこでJavaScriptを使います。例えば manifest.json で次のように設定します。

こうすることで、JavaScript側でlancherというパラメータの有無によって表示を変えられるようになります。不要なフッター情報などを削除しても良いでしょう。

オンライン/オフライン判定

これはPWAに限りませんが、 navigator.onLine がtrue(オンライン)/false(オフライン)によって判定できます。ムダなアクセスをなくしたり、デフォルト画像を表示したりするのに使えます。

インストールプロンプトの抑止

サイトを閲覧中にインストールしませんか、というバナーを出してもなかなかOKされないでしょう。インストールしたくなるような文脈が必要なはずです。そこで、インストールプロンプトを抑止し、任意のタイミングで出せるようにします。

まず抑止は beforeinstallprompt イベントで行います。

そして、任意のタイミングで deferredPrompt.prompt(); を実行します。

ただし、現状では beforeinstallprompt がいつ実行されるかが分からず、かつ一度離脱した後、確実に次も呼ばれるかは分かりませんので注意してください。

インストール状況を調べる

PWAをインストール済みかどうかは event.userChoice で判別できます。 accepted であればインストール済み、dismissedであればキャンセル済みです。

ネイティブアプリのインストールを進める

manifest.jsonに related_applications を指定することでネイティブアプリを進められるようになります。

さらに preferrelatedapplications を true として指定するとPWAのインストールバナーは出さず、アプリのバナーのみになります。


PWAはネイティブアプリとWebアプリの中間とも言える存在です。単純にWebアプリ + インストールできる程度に扱うのではなく、ちょっとした工夫で解析や、よりユーザビリティの高い仕組みが提供できます。

via ウェブアプリのインストール バナー  |  Web  |  Google Developers

via ウェブアプリ マニフェスト  |  Web  |  Google Developers

PWAの基礎知識(その6)「Web App Manifest作成の便利テクニック」

PWA(Progressive Web App)という単語がトレンドになっています。PWAは特定の技術を指す言葉ではなく、様々な技術が組み合わさったスマートフォンにおけるWebアプリのベストプラクティスと言えます。

今回はそんなPWAの基礎になる、Web App Manifestを作る時に便利なテクニックを紹介します。

Web App Manifestとは?

Web App ManifestはWebアプリをスマートフォンアプリのようにインストールできる技術です。アプリストアを経由せずに配布できるのが魅力です。

検証

Web App Manifestではmanifest.jsonというファイルを作成しますが、これが正しく作れているかどうかが確認しづらいという問題があります。そこで使ってみて欲しいのがGoogle Chromeの開発者ツールです。アプリケーションタブにManifestという項目が追加されています。これを見ると設定内容が正しく認識されているか一目で分かります。

また、Add to HomescreenというリンクをクリックしてChromeアプリにすることもできます。これはほぼブックマークですが、Chromeのブックマークバーよりアプリと言うリンクをクリックすると一覧で表示できます。

さらに詳しい検証

もっと詳しい情報を知ったり、 Web App Manifestに限らずPWAが正しく設定できているか確認するためにはLighthouseという機能拡張が便利です。PWAにしたいWebサイトを表示した状態で実行すると、レポート生成してくれます。

主なチェックポイントとしては次の通りです。

  • Service Workerを登録しているか
  • オフラインでも200のレスポンスを返すか
  • HTTPSを使っているか
  • スプラッシュスクリーンが使えるか
  • アドレスバーの色設定が行われているか
  • HTTPへのアクセスがHTTPSにリダイレクトされるか
  • 3G回線でも十分に速いか
  • メタタグでviewport設定を行っているか

Google Chromeの設定

開発中はインストールバナーが表示されるタイミングが非常に分かりづらく、何度も再読込を繰り返すことになるかと思います。そこでAndroidのGoogle Chromeにて、フラグの設定をします。 chroke://flags を表示して、Bypass user engagement checksを有効にします。これでバナーがすぐに出るようになります。

なお、アプリをインストールした後に削除し、再度バナーを出す場合にはアプリのデータをすべて削除し、再度Bypass user engagement checksを有効にすると表示されるようです。


Web App Manifestはまだ対応しているブラウザが少なく、利用されるとしてもAndroidがメインデバイスになるかと思います(Safariはまだ中途半端にしか対応していないため)。まだ機能的に不十分な感はありますが、幾つかのテクニックを駆使して効率的な開発に努めてください。