本記事は、「Polymer 1.0最新情報」の後編になります（前編はこちらから）。Google I/OでPolymer 1.0が取り上げられた「Polymer and modern web APIs: In production at Google scale」のセッションをレポートします。Polymerの最新情報や活用事例、Polymer Catalog、Polymer Starter Kitなど、盛りだくさんのこのセッションの翻訳と解説を前後編に分けてお伝えします。

後編となる本記事では、「ライブサイトへの適用例（後半）」、「Polymer Starter Kitとは」を解説します。

ライブサイトへの適用例（後半）

前編に引き続き、Polymerのライブサイトへの適用例の後半です。コードを交えながら具体的に解説していきます。

Google I/O Web App

このアプリは社内ではIOWA（アイオワ）と呼んでいる。IOWAはModen Web Platformでの良い実装例で、デスクトップでもモバイルでも動作して、コンテンツが最初に読込まれるときマテリアルデザインのエフェクトと共に表示され、ページとコンテントの間の表示での大きなエフェクトついているし、デスクトップでもモバイルでもビデオをクリックすると全画面になる。Webアプリでここまでネイティブアプリ感が出せている。

そのIOWAには想像できる新しいWeb APIのほとんど全てが使われている。

ここからIOWAのポイントは以下です。

• バックエンド：広範囲に渡ってAppEngine上でGoを使用
• Material Designの実装に関して：Web Animation、Promiseで各種エフェクトを実現
• 開発したチーム：ソフトウェア エンジニアではなく、Developer Relationsチーム
• ツール：誰でも使うことのできる3rdパーティ製のツールを使い、Googleの特別なツールは使っていない

ここから実装方法に関しての説明になります。

Templateを使ったSPA（シングル・ページ・アプリケーション）の実現

Google Santa Tracker 2014ではURLルーティングを行うことでSPAを実現していましたが、IOWAではTemplateとHTML Importsを使って動的にコンテンツを読み込でいるそうです。

1. 異なるid属性を付けた複数のTemplateを1つのページに配置
2. ref属性を持ったTemplateタグを配置
3. ref属性に予め埋め込んだTemplateのidどれかを指定

すると、指定したidのTemplateのコンテンツがTemplateの中に差し込まれます。IOWAは予め複数ファイルでページをTemplateとして用意して、必要に応じてそれらのファイルを動的に読み込む（HTML Imports）ことでSPAが実現されている、とのことでした。

Material Designの実現

ビデオ等は遅延ゼロの理想状態でMaterial Desginの動きは説明されているが、Webアプリではそうはいかないので工夫が必要です。IOWAではWeb Animation、Promiseを使い、ロジカルなアニメーションのシーケンスを作ることで実現しているそうです。

1. Promiseが”page-transition-start”のEventを発行し、ページトップ部分の色を変更するのと同時にコンテンツをページ表示領域から外側にスライドしフェードアウトさせる
2. Import Page Method（TemplateとHTML Importを使ったSPA実現方法）を使ってページのコンテンツをAjaxで取得する
3. コンテンツの準備が完了したら、ページ全体のアニメーションを実行する。このアニメーションは基本的にコンテンツを200ms以下の時間でページにスライドさせていて、パララックスのエフェクトもかけている
4. 動的なページ読み込みとアニメーションが完了した時点で、例えばJavaScriptの実行のようなページを構成するために必要な処理が実行できるようになる

このように、PromiseとWeb Animation APIをWrapして利用することでCSSのアニメーションが動いたり、ネットワーク接続が発生したりと非同期な処理が起こっている状態でも、ロジカルな同期が可能です。

オフライン ファーストの実現

IOWAで注目すべき機能で、Service Workersを使って実現している。Service WorkersのおかげでWeb開発者が実現できることの代表例は以下です。

• ページキャッシュ
• プッシュ通知（Push Notification）
• バックグラウンド・シンク
• ネットワークリクエストの横取り

IOWAではこれらの機能を使い、アクセス解析を行うGoogle Analyticsへのリクエストをオンライン時はリアルタイムに、オフライン時は横取りをして一旦IndexDBに蓄積。オンラインになった段階で再現をしてオフライン時のアクセス解析を可能にしています。一般的にも、こうすることで重要なインサイトを逃さず見ることができるでしょう。

オフライン時の動作の実装で注意した点

Webサイトがオフラインでも動作することはユーザは体験したことがないので、例えばオフラインになったときにアプリケーションを終了されてしまうことを防いだりします。またオフライン動作することに驚かれないために、IOWAでは「オンラインからオフライン」に遷移した時にアプリケーション側で何が起こっているかユーザが把握できるよう、トースト（自動的に消える小さなお知らせエリア）で状態を知らせることができるように注意して実装してます。

実際に以下のリストのような事象が起こった場合にトーストを出しています。

• 初回アクセス時：次回からは最初からオフラインで動作します
• オフライン時の情報情報更新：オンラインになった時に情報をサーバに通知します

オフラインとは電波（Wi-Fi、3G、4G等）の状況が悪いとき、Airplaneモード等でインターネットにつながらなくなった状態のことを指しています。

プッシュ通知(Push Notifications)

プッシュ通知はNativeなアプリでは当たり前になっている機能ですが、Webの世界では真新しい機能になります。もちろん、アプリが開いていない状態でも通知を受けることが可能です。

プッシュ通知も新しい機能なので、オフライン時の動作と同じく状況をトーストで通知しています。このプッシュ通知を動作させるためには、ユーザが通知を受ける/受けないを選択することに加えて、通知を受け取る許可をユーザがブラウザに対して行う必要があります。

プッシュ通知を行う目的はWebサイト/アプリへの再訪にあります。IOWAではその効果測定のためにプッシュ通知からどれだけユーザが実際にサイト/アプリに再訪してくれたかをAnalyticsを利用して計測しています。

プッシュ通知の送信は一見難しそうですが、Elementがあるので心配しないでください。実際にはこのような形で実装することができます。

プッシュ通知を使う目的はWebサイト/アプリへの再訪です。なのでIOWAではプッシュ通知からどれだけユーザが実際にサイト/アプリに再訪してくれたかの計測をAnalytics利用して行っています。

ここまでお話してきた、オフライン動作の実現、Service Workers、プッシュ通知に関してもElementが存在していて、Platinum Elementsに実装しています。

リンク：Platinum Elements（英語）

最後に「6ヶ月の出来事のお話しだったので、駆け足の説明で盛りだくさんになってしまった。紹介した2つはライブサイトも動作しているし、ソースコードも公開しているので、詳しくはそちらをご覧ください」と結びました。

(Speaker: Eric Bidelman)

リンク：Google I/O web app [ライブサイト] [コード]

Polymer Starter Kitとは

「PolymerのDeveloper Toolを担当しているAddy Osmaniです」と自己紹介から始まりました。

そして間髪入れず、最近の出来事からの例えを交えて「物事の筋道にはステップを踏まないと思い通りのモノは作れない」ということの説明が始まりました。

Addyの友達に赤ちゃんが生まれたそうで、赤ちゃんのスケッチしてプレゼントしようと考えたそうです。そしてスケッチ方法をGoogle.comで検索をすると「まずは丸を書くことが最初のステップ（Step1）」という結果だったそうです。「実現可能性を確信したけど、次のステップを探した結果がStep2でした。このStep1からStep2への飛躍は非常に大きく、これを目標に続けると最終的にはStep1.5のようになることも少なくない」と続きます。

Polymerはまさに例に挙げたStep1からStep2へ移行しようとしている段階なので、これを避けるべくPolymer Teamは「Polymer Starter Kit」で、この状況の回避を行うとのこと。「Polymer Starter Kit」は、過去1年間でPolymerを使ったプロジェクトGoogle I/O App、Web Starter Kit、Google Santa Trackerを見返して、そこから得られた知見を1つにまとめた結果です。

ここから「Polymer Starter Kitがどのようなものなのか？」の説明に入ります。

Material Design

非常に高いレベルでMaterial Designをサポートしています。Toolbar，Header-Panelのようなモバイルアプリを開発するときに必ず必要になるパーツ、URLルーティングや複数の画面サイズにフィットするような仕組みもサポートしている。CSS Custom Propertyを使って、アプリ全体のテーマカラーを数行のコードで変更する可能で、非常にパワフル。

モバイルWebアプリ開発ではテーマカラーの変更、クロスデバイス（Android、iOS、Windows Phone）でホーム画面へのアイコンリンクの準備も最初からできているので、再訪へとつなげられる。

Adaptive UI

今回のI/OでMaterial Design Teamが発表したガイドライン。これはデバイスによってインタラクションをどう作り込むのがよいのかのガイドラインですが、Polymer Starter Kitはこれらを全てを含んでいる。あくまでもこれらは1つの例でしかないので、必要に応じてカスタマイズすることも可能。

App Template

Navigation Card Layout、住所録のようなアプリに最適なNavigation List Detail Layout、List Card Over Layout(Wider Card View Layout)などが用意されていて、すぐに利用できるLayoutのセットとなっている。

Offline-first (in your app)

Ericもオフラインの重要性を訴えた通りで、またRob Dodsonも「2015年は、もしアプリがオフラインをサポートしていないのであれば、それは本当の意味でのモバイルWebエクスピリエンスを提供できていない、という考え方が現実になるだろう」と言っています。良いことにPolymer Starter Kitはデフォルトでオフライン ファーストになっているので何の設定をすることもなくAirplaneモードや、オフラインになったときにもアプリに含まれる全てのページにアクセスすることが可能。

Service Workers

素晴らしい機能だけど、導入するには多くの設定が必要です。ですが、

> There is an element for that!

で、Polymer CatalogにあるPlatinum Elementsを使えば、Service Workersを使ったキャッシュ機能を簡単に実装することができます。

Service Workersのセット・アップの例です。Service Workersの登録し、キャッシュのストラテジを数行で設定している。例では「Network First」をキャッシュのストラテジとして、キャッシュしたいファイル名を予め宣言しています。

Production-ising Cache

ユーザにできるだけ小さく、できるだけ速いアプリを提供するという意味ではビルドプロセスはとても重要。Polymer TeamはストリーミングビルドシステムのGulpが大好きなので、Polymer　Starter Kitに採用している。

web-component-testerなどのクオリティテスト、Vulcanize等のミニフィケーション等が可能。Browser Syncを使っているので、アプリに変更を加えるとその変更はクロスデバイスで伝搬され（クリック/タップ、スクロールも含む）全てのデバイスで一度に確認することも可能。

実際に「Polymer Starter Kit」を適応して「Paper Reader」という名のRSSリーダアプリを作ったお話は変わります。

使った技術の一覧で、これらの1つ1つにElementが存在しています。

• 記事をGoogle Feedから取得（RSS、Atom、Media RSS feedに対応）
• 既読/未読の管理にはFirebaseを利用
• オフラインでの動作
• 新着のプッシュ通知

まとめると、Polymer Starter Kitは大きく分けて、以下の4つを含んでいる。

• Components
• Layout
• Theming
• Build tools

「これらのElementやPolymer Starter Kitを使って、何を作るかはあなた次第です」

と最後に結び、Matthew McNultyに戻ります。

(Speaker: Addy Osmani)

リンク：Polymer Starter Kit（英語）

まとめ

ここ2年間で、Polymerが約束をして実現したことは以下の通り。

• Web Components
• Interoperability
• 宣言的な書き方ができること

ChromeではWeb Componentsがリリースされて1年、またProductionに耐えられるPolymer 1.0がリリースされた。

Salesforde、Vaadin、Atabistなどの3rdパーティも、PolymerをProduction用に使っている。Google Santa Tracker、Google I/O web appはオフラインで動作します、Polymer Starter Kitも今日から使えるし、今後は1.0には入れられなかった新しい機能、Elementを早いペースで次々に追加する予定です。

Polymerについての情報の取得等のリンクは以下。

• 最新情報：polymer-project.org
• Polymer Teamと直接会話：Slackチャンネル

そして、Polymer単独のカンファレンスの告知がありました。

「2015年9月15日にアムステルダムにて、PolymerだけのカンファレンスPolymer Summitを開催します。1日中、Polymerを、また最先端のWeb開発を学びにくてください」とのことです！

最後に「バグも見つけてね」でセッションは終了でした。

(Speaker: Matthew McNulty)

あとがき

個人的にはPolymerを最初に触ったのが2013年頃で、そのキッカケは楽器系のアプリを作った時に必ず使いたくなるリッチなノブ、スライダ、スイッチ、鍵盤を簡単に配置できる世界を夢見たwebaudio-controlsが開発され始め、それに乗っかって一緒にはじめたことでした。

今回のセッションに参加して、その中で何度もリピートされていた言葉、 “There is an element for that!“（それ、エレメントあるよ！）をwebaudio-controlsを作ってから、実際に自分自身が言っていたことに気が付きました。

また、ブラウザにMIDI機器を接続して遊べるWebアプリを、簡単に作ることができる世界を夢見てx-webmidiというElementも作りました。これを作った理由は「ゼロから書くのはちょっと…という理由で手が出しずらい、という印象を少しでも和らげたい」からでした。

この「手軽に使えること」だったり「ゼロから書くのはちょっと…という理由で手が出しずらい、という印象を少しでも和らげたい」という想いがさらに一般に拡がりElementが量産されたのであれば、その未来はブラウザにはよりプリミティブなAPIが実装されるようになり、ブラウザのAPIをより使いやすくする、APIを組合せることで新たな枠組みを作るためのWeb Componentsが「ブラウザのAPIとWebアプリの中間に新たなクリエイティブな層」を創り出して、Web開発がExtensible Webな時代へ突入するのかな？なんて、Webの未来をモヤモヤ考えさせられる2015年のPolymerのセッションでした。

Polymerは、Google I/O 2015にて1.0が正式リリースとしてアナウンスされました。本記事は、Google I/OでPolymerが取り上げられた「Polymer and modern web APIs: In production at Google scale」のセッションをレポートします。Polymerの最新情報や活用事例、Polymer Catalog、Polymer Starter Kitなど 盛りだくさんのこのセッションの翻訳と解説を前後編に分けてお伝えします。

前編となる本記事では、「Polymer1.0の特徴」、「Polymer Catalogとすぐに使えるElements」、「ライブサイトへの適用例（前半）」を解説します。

Polymer1.0の特徴

Polymerが全体的にどう変わったのか、その特徴をまとめて説明してくれました。Polymer1.0の特徴を全て紹介しきれていないとのことですが、セッションで特に紹介されていたのは以下の通りです。

• 高速化(0.5と比較)：Chromeでは3倍、モバイルSafariでは4倍高速化した
• 軽量化(0.5と比較)：以前より35％コード量減らしPolyfillも含めてgzipをすると19kb-42kb
• Shady DOMの採用：スピードを重視したShadow DOMのPolyfillで100％互換ではない
• CSS Custom プロパティ：プロパティの変更だけでテーマやスタイルの変更を可能に

「PolymerはWeb標準技術であるWeb Componentsのライブラリであって、そのElementを作ることができます。なので、結果的にそれらのElementはWeb標準技術の上に作られたのと同意である。他のブラウザ上でも動作するし、AngularやReactといったFrameworkの中に一緒に共存させることもできる、というところが最大の特徴であり利点でもあります」

セッションでは、これらの説明をコンテナを運ぶ物流システムに例え「標準化を元に作られたコンテナ（Polymer Element）だからこそ、標準化されたボート・電車・トラックで効率的に運ぶことだってできる（ブラウザのInteroperabolity）」という形で説明をしていました。この例えは、Polymer TeamはSan Franciscoのオフィスにいて、普段の会話の中に湾を行き交う輸送船について話すことが多いことに由来しているそうです。

(Speaker: Matthew McNulty)

Polymer Element Catalogとすぐに使えるElements

ここからPolymerを使ってWebアプリを作るときのElementについて話に変わります。

「Polymer Teamは全ての開発者にPolymerを使って高品質なアプリを簡単に作ってもらうことを目標にしています。そして、アプリはElementによって出来が左右されるので、高品質なアプリを作るには高品位なElementが不可欠です。なのでGoogleでは高品質なElementを提供します」

という導入があり、続いて具体的にElementの説明です。

まずは去年から公開されていたElementとして、Iron Element、Paper Elementが紹介されています。そして、新しく追加されたElementとして、Google Web Components、Platinum Elements、Gold Elementsがあります。

• Iron Element (Fe)
  新しく聞こえますが、Core Elementから名称を変更しました。内容は以前と変わらずElementの基本となり、どのアプリケーションにも使うようなエレメントのセット。
• Paper Element (Md)
  Material DesignのリファレンスになるElementのセット。
• Google Web Components (Go)
  Google SDKとも言えるようなElementでGoogleのServiceやAPI（GCP、Drive、Map、Hangout、Calendar、Analytics、YouTube、Docs、Chrome Web Store、アドレス帳など）を利用する際に利用するElementのセット。
• Platinum Elements (Pt)
  オフライン・キャッシング、ServiceWorkers、Push Notificationのようなとてもパワフルな機能を最も簡単に利用することのできるElementのセット。このElementを使うことで、半年前には夢だと思っていたような機能が簡単に実装可能。
• Gold Elements (Au)
  モバイルでの高品質な決済のチェックアウト遷移を作成できるElementのセット。日付、カード番号等の自動Validationが可能。

これらのうち、新しく追加された3つのElementは、Web開発者が特定の問題を解決するために用意しているものとのことです。このPolymer Catalogについては次のように説明しています。

「このサイトの目的は、解決したい問題がある場合は解決策を見つければいいのだけど、例えば、何かに触発されたかったり、思ったこともないようなデザインを見つけたかったり・眺めたかったり、考えたこともないようなアプリケーションを考えたいという場合もあります。この2つ「解決策を見つける」、「インスピレーションを得たい」を実現させる為に、Elementをブラウスでき、デモを動作可能で、ドキュメントも読むことができるのがPoymer Catalogです」

リンク：Polymer Catalog（英語）

Polymerを使ってアプリを実装、公開している3rdパーティとそのアプリの紹介

「Polymer TeamではWeb開発者が「実装したい」と考えるであろう機能は、”There is an element for that!“（それ、Elementであるよ！） と言えるようにりたいと思っていますが、我々の以外でも同じことを想っている方々は多くいます。そこで、ここでは出版関連を行っているAtabist、Enterprise向けのJavaアプリ用のFrameworkを作っているVaadin、そしてSalesforceの3つの事例を紹介します」

Atabist

出版関連を行っている会社で、Web上に本を作るPlatformをリリース。Webは音声、映像、画像、地図、ブラフを一緒に配置して1つにまとめるにはとてもよい媒体で、これらの1つ1つをPolymerのElementにして自由に配置できるようにしたのがこのPlatform。

リンク：Atabist（英語）

Vaadin

Enterprise向けのアプリを書くためのFrameworkを作っている有名な会社の1つで、Front-endのComponentsはPolymer Elementを使って実装している。特に大量のデータを表示することに重きを置き開発されていて、例えば、v-gridというElementを作っていて、これを使うとアドレス帳のようなモノを表示、LazyLoading、行または列の複数選択の機能もElementを実装することができる。グラフを描くElementも作っていてタグ名を変えるだけで、グラフの種類を変更することができる。

リンク：v-grid（英語）

Salesforce

Salesforceは彼らのPlatform上でそのデータを表示するアプリケーションを作るためのSDK、APIを公開している。このアプリケーション開発をより簡単にしたいということで、Polymer Elementでの提供を行っている。

ライブデモ：デザイナ（英語）

Google社内でのPolymerの実用例

最後にGoogle社内でのPolymerの実用例の紹介です。Polymer Teamは「GoogleさんはLiveサイトでPolymerを使っているの？」とよく聞かれるそうですが「もちろん使っている」とのことで、そのうち3つを紹介してくれました。

Translate：Translation TeamはTranslateの質を上げるためにコミュニティのメンバーが参加して作り上げることのできるシステムを新しく作った。サイト全体がPaper Elementを使ったMaterial Designを採用している。このプロダクトはFront-endエンジニア2人で2～3ヶ月の開発期間で完成させることができたとのこと。Paper Elementを使っているので、開発者はどうやってMaterial Desiginを実装するかということは気にせず、アプリケーションの本質部分に集中して開発を進めらたそうです。

ライブデモ（英語）

Play Music：Play TeamもPaper Elementを使ってMaterial Designを採用しているので、アプリケーションの本質部分に集中して開発を進めることができたとのことです。Play Musicは現在はPolymer Elementの組合せで作られていて、同じような音楽再生用WebサイトにElementを再利用することも可能です。（日本からはアクセスできません）

YouTubeのモバイルWebサイト：多くのPolymerを使ったサイトはまだGoogle社内にしか公開されていないのですが、その中の1つ、それがYouTubeのモバイルのFront-End。これも全てがPolymer Elementで作られています。キビキビ動き、アニメーション、トランジションもついていて、とてもよいUIに仕上がっている。またビデオを画面の角にドラッグして動かすというWebでは実現が可能とは予想していなかったであろう動作も実現できている。このようにWebでもNativeのような最高の動作をPolymer Elementで作ることができる。

「Elementはとても素晴らしく、紹介したような素晴らしいElementを作ることができます。Polymer Teamは引続き素晴らしいElementを開発していきます。そして、コミュニティからもっと素晴らしいElementが出てくることを楽しみにしています」

と結び、次のライブサイトへの適用例の説明に移りました。

(Speaker: Taylor Savage)

ライブサイトへの適用例（前半）

ここからはEric Bidelmanにバトンタッチです。彼の3年間を振り返ってのお話からです。

Polymer Teamにいて「これはどうやってWeb Componentsで実現するの？」ということを開発者と話してきて、そこでよく質問にあがる具体例が「どうやってSPA（Single Page Application）をWeb Componentsでどう実装するのか？」、「他言語化やLazyLoad、またURLルーティングはど実現するのか？」というような「Polymerを使ってどう実現したいモノを実装するか？」という部分です。それに対してPolymer Teamはこう答えているそうです。

> There is an element for that!

という掴みがあり、続いてEric Bidelmanが前回のI/Oから数多くの実験を実際に行い、Google.com上のアプリを作りそれらを公開して、実際に使えるのかを試してみた、というストーリで実例を2つ紹介してくれました。

「これらの事例ではPolymer1.0ではなく、ちょっと遅いけどGoogle.comで公開されているのは0.5。なんだけど、1.0と書き方が少し違うだけで本質的なPolymerの部分は同じなので、これからお話をする事例には影響は特にないのです」

と捕捉があって、Google Santa Tracker 2014とGoogle I/O Web Appの説明が始まります。

Google Santa Tracker 2014

このアプリは12月に公開されたアプリで、サンタ村を訪れることができ、12月中は毎日新しいゲームを提供したりしているAdvent Calendarのアプリ。日々提供されるゲームだったり、そのSceneのことを社内ではLaunchと呼んでいて、それらの全部がElementになっていて、Web AudioだったりWeb GLだったりを使っているものもある。クリスマスイブには今どこでサンタがプレゼントを配っているかも見ることができる。もちろんそれもElementになっている。

コード的な説明です。<santa-app> が全体をオーケストレーションするElementで、Google Analyticsに、また音楽の再生・停止をするEventの発火を行う。<santa-app> の内部にはさらにElementが入っている。URLルーティングもElementを作って対応していて、LazyLoadingのElementとを結びつけ、ユーザがSceneを選択したときにJavaScript、CSSが動的に読み込まれるような仕組みになっている。このプロジェクト全体的にElementはDeclarativeにしていて、各Sceneのプログレスバー、背景色、背景画像もそのおかげでHTMLのAttributeでの設定が可能になっている。

Google Santa Tracker 2014の説明は以上でした。

リンク：Google Santa Tracker [ライブサイト] [コード]

（後編に続きます）

最近、モバイルではネイティブ一強という状況にみえます。Webはあまり注目されません。今後も同じ状況が続くのでしょうか？そのことについて、Google I/O 2015のセッション「The Next Generation Mobile Web」が参考になります。補足を加えつつ翻訳してみましたので、どうぞご覧ください。

But What About Mobile

Webはパワフルな技術だ！これからも、ビジネスをもっと盛り上げていく。2014年、Eコマースは低く見積もっても1.5兆ドルの規模になった。そんな中、モバイルは何を変えたのか？ユーザにどんなインパクトを与えたのか？

モバイルは経済のシフト、デスクトップが担っていた領域の変化だ。パフォーマンスが求められるような動作も、従来のPCとは違い、バッテリーで動いているデバイス上で実現しなくてはいけない。必要とされる機能も完全に変わってしまった。プッシュ通知はモバイルのポテンシャルを高める上で重要なのだが、Webにそれはできなかった。結果、ネイティブの方が当然良く見えるわけだ。

しかし、我々は全てをネイティブアプリに置き換えるべきなのだろうか？ネイティブにはいいところがあるけれど、Webもまた負けないいいところがあるはずだ。

みなさんは、Chrome Dev Toolsがどれだけの人に使われているのかご存知だろうか？Androidは400万人/週だが、Dev Toolsは2,500万人/週に使われている。そして、素晴らしいことに、今もなお増加し続けている。全ての人が巨大で複雑なWebサイトを作っているわけじゃないし、中にはあまり上手くWebサイトを作れていない人もいる。けど、少なくともDev Toolsを使っているみなさんは十分にスキルが高い。今からするこの話は、そんなWebを愛する2,500万人のあなたたちに伝えたい。

Reach

Webサイトはツリー型だ。例えば以下の図だと、ノードにあたるのがPinterest.comみたいなサイトで、あなたたちのサイトはその葉にあたる。URLからURLへ、ノードから葉へ飛ぶ。異なるサイトであっても、リンクからリンクへ飛ぶことはそんなに難しいことじゃない。サイトの奥地へだって行ける。

人間が使うモバイルアプリは平均12から20と言われている。しかし一方で、アクセスされるWebサイトは、一ヶ月あたり100ドメイン以上だ。それはWebが、リンクを使って簡単にアクセスできるからだ。USにおいて、85%のリテーラーはモバイル上のトラフィックがWeb経由でやってくる。これがWebの持つパワーなのだ。

Performance

では、これらのリーチに対して、Webページはどの程度のパフォーマンスが必要なのか？ページの読み込み時間か？いや、それでは十分とは言えない。実際にはもっと様々なメトリクスがある。スクロールだってサクサク動かなくちゃいけないし、アニメーションも60fpsで動かすべきだ。ただ、どんなパフォーマンスをどれぐらい速くすれば十分なのかは、なかなかわからない。

その答えとして「RAIL」というコンセプト挙げている。Reaction、Animation、Idle、Loadの略称だ。RAILでカギとなっている考え方は「When is performance ‘Good Enough’? When the user can’t perceive it.(十分な速さとは、ユーザがそれを気にしないことだ)」だ。そしてそれを実現するために、60fpsを意味する16.67ミリ秒、100ミリ秒、1秒という時間に注目している。

RAILのR、Reaction Timeは、例えば画面にタップするなどのアクションに対して、100ミリ秒未満でリアクションすることを求めている。そうでないと、ユーザはそのアプリが、壊れているだとか遅いだとか感じるだろう。100ミリ秒未満で、ボタンの色を変えたりインジケーターを回したりすれば、フリーズしたようには見えない。

RAILのA、Animation Time。アニメーションは、16.67ミリ秒未満で動作することを求めている。RAILのI、Idle Timeについて。JavaScriptなどでデコードなどの重い処理を行うと、UIが固まってしまう。処理をチャンクを使うなどして分けて、Idleを作り出さなくてはいけない。その期間は50ミリ未満が望ましいだろう。そうすることで、RのReaction Timeの100ミリ秒未満は守られるだろう。

RAILのLは、みなさんもよく知っているLoad Timeだ。これは1秒未満が望ましい。ただ、これに関しては、Service Workerを使えば、読み込み時に動作中であることをユーザに伝えることができる。

Chrome開発チームには現在、約200人程度のエンジニアがいる。そしてその多くは、パフォーマンスを改善するために働いている。モバイルを良くしようと、様々な取り組みを行っている。その全てを深く語るには、時間が足りなさ過ぎている。一つだけ紹介すると、例えば「スケジューラー」。これはパフォーマンスを劇的に変えたと思っている。タスクの優先度が変わったことで、スクロールのパフォーマンスが大きく改善されたのだ。

パフォーマンス改善は、とても難しいことにみえるかもしれない。しかし臆することはない。博士号なんか取得していなくても、ちゃんとできる。Chrome Dev Toolを使って、サードパーティスクリプトであったり、リソースのパフォーマンスを計測して、問題を探るのだ。そして、RAILをゴールとして、パフォーマンス改善を行っていけばよいだろう。

Engagement

モバイルWebに欠けていたのは、エンゲージメントだ。しかし今、Webにはエンゲージメントを助けるたくさんの機能がある。ただ同時にそれは、セキュリティ面に大きな課題を抱えている。

例えば、background sync(Service Worker)なんかは、Webページを閉じていても簡単にコンテンツの読み込みや送信ができてしまう。あなたが一ヶ月に100のサイトへアクセスするとして、その全てでbackground syncが有効になることは望まないだろう。質の悪いWebページにアクセスしようものなら、Background syncが裏で動き続け、バッテリはどんどん消耗されるなんてこともある。バッテリー効率の悪いネットワーク処理を、ガンガン動かすことが可能だからだ。

誰しも、初対面の相手は簡単には信頼しない。Webサイトオーナーとユーザーとの関係は、ゆっくりと築かれる。ネイティブはアプリのコピーがWebほど簡単ではない。ストアがいて、その開発元も明かされているからだ。しかしWebはオープンだ。パーミッション機能は慎重に作られていなくてはいけない。ユーザに確認して、パーミッションをWebサイト側へ与えることで、初めてリスクの高い機能は使えるようにしている。

さて、これらの機能のうち、有益なものを2つ紹介しよう。

一つ目が「Add to homescreen」だ。例えば興味をもったWebサイトがあったとする。そこに手軽にアクセスしたい。そういう時に、ホームスクリーン上へアイコンを配置しておき、ネイティブアプリのように手軽にアクセスできるようにしておくと、簡単にWebサイトへ飛べる。

実は、古くからそのような機能がブラウザについているのだけれど、設定メニューの中に隠れていたため、手軽では使えなかった。しかし今は、それができるAPIを提供している。これをWebサイト上から呼び出せば、以前より手軽になるだろう。

モバイルWebでユーザ体験を高める場合、ネイティブアプリのような、オフライン対応も重要になる。以前は、「App Cache」がその役割を担っていた。しかしそれは、始めること自体は簡単なのだけれど、メンテナンスにやっかいな問題を抱えている。失敗すると、Webサイトは簡単に動かなってしまう。これを改善し、柔軟なコントロールが行えるようにしたのが「Service Worker」だ。

Service Workerはオフラインで動くスクリプトで、Webサイトにアクセスするとまずそこに問い合わせが行われる。Service Workerは何をすべきか判断し、必要であればネットワークを通じてリソースを取得し、キャッシュへ置くことができる。その振る舞いから、クライアントサイドのJavaScriptプロキシなんて呼ばれていたりする。

Google I/OのWebサイトなんかが良い例だ。Service Workerを使って、必要な全てのリソースをキャッシュに読み込んでいる。Gulpに「sw-precache」というプラグインがある。それを使えば、簡単にService Workerのインテグレーションを、あなたの現場のワークフローへ組み込めるだろう。

Service Workerは、Webページが複数のタブが開かれていても、その全てと通信できる。また逆に、一つも開かれていなくても内部で生存している。それはランダムに起き上がって動くようなことはせず、基本的にはイベント駆動だ。ネットワークなどのイベントを検知して、スクリプトはストレージ内からメモリ上へ移される。だいたい50ミリ秒程度だろうか。その後、Service Workerの処理が実行される。

モバイルであれば、ネイティブアプリのようにプッシュ通知を扱いたい考える事は必然であろう。Anish AcharyaはTechCrunchで「Notification Are The Next Platform(次のプラットフォームは通知だ)」と語っている。通知機能は、エンゲージメントを改革するのだ。

人々がアプリに長く時間を使うのは、人々が通知を受け取るからだ。モバイルの画面を見て、通知を受け取っているのを見て、そこでアプリを使う決断をする。ニュースサイト「The Guardian」はネイティブアプリを提供しているのだが、彼らは事件が起きた時に、そのニュースをプッシュ通知を通じて伝えると、40%のユーザがそこからやってきたそうだ。これはとても多い人数だ。

そんなプッシュ通知だが、今はブラウザから実行できるようになっている。一つの例として、The Guardianのある記事へアクセスした時に、その記事の更新をプッシュ通知を受け取ってみる。

通知の許可を、Webサイト上で行うことができる。

その後、Chromeを閉じ、ユーザは作業を再開する。そして、記事が更新されると・・・この通り！プッシュ通知が飛んでくる。これは他のネイティブアプリと、同じように扱われている。

じつは、今サンプルとして紹介したThe Guardianは、今後本当にプッシュ通知を対応させる予定だ。SNSのFacebookや、商品を扱っているebayやticketmasterでも対応する予定だ。今後も増えていくことだろう。

最後に

いかがでしたか？

Reach、Performance、Engagementは非常に重要であり、これらが効果を上げれば、モバイルWebは上手くいく、というのがGoogleらの答えなようです。

「Web vs ネイティブ」という議論は散々行われてきましたが、彼らはそういう見方をしていないようですね。モバイルの本質を考え、そこからWebの立ち位置を明確化してきたように見えます。

よくよく考えてみたら、モバイルのホームスクリーンはブラウザのブックマーク機能と、そのユースケースに大きな違いはありません。そして、最近のプッシュ通知もまた、アプリの状態を表示するものというよりも、エンゲージメントの高い情報を目立つ所にリスト化しているだけのようにみえます。それはWebのサービスにおいて、メールの通知によって補っていた機能です。いまさら、驚くようなことでもありません。従来デスクトップでもやっていたことを、モバイルのユーザビリティに合わせてきたと捉えられます。

この考え方が、一日でも速く現場にも浸透してほしいですね。そのためにも、「Windows XPの悲劇の再来」にも見えるAndroidのフラグメント化が、一日でもはやく改善してくれることを祈っています。

この記事は2015年5月28日に行われたGoogle I/O 2015「Material Now」セッションの翻訳です。「Material Now」では、Material Designがリリースされてからの1年間の状況や反響、事例等を取り上げています。本翻訳の後編は、Google社のデザインに対する取り組みと、Material Designの採用事例について記述します。

Design Sprints

• Design Sprint | Google Developers

私たちはみなさんにMaterialをもっと好きになってもらいたいですし、みなさんのフィードバックをMaterialに取り込みたいと考えています。みなさんと対話するために、去年から私たちはいくつかのプログラムを始めています。

スターターのために、私たちはGoogleでDesign Sprintsを行いました。マウンテンビューのキャンパスでガレージと呼ばれる場所で、1日かけてデザインワークショップをします。いくつかの企業を招いて、そのチームのデザイナー、プログラムマネージャー、エンジニアが一緒にプロダクト開発における特定の問題に取り組むのです。

私たちはそれをサポートするのですが、それはなにも既存のアプリのMaterial Design化だけでなく、アプリデザインをいろんな観点からサポートするのです。これはとても素敵な取り組みで、私たちはみなさんが抱えている問題が何なのかを理解することができます。とても真剣で濃密なプロセスですが、反応はとても良いものでした。私たちは17の企業と協力し、今もこれ続けています。

加えて、私たちは100以上のデザインレビュー、それは1、2時間の短いセッションで、私たちのデザイナーの何人かがみなさんのデザインチームとMaterial Designの実装について話し合うのです。これもまたみなさんと協力しあえることができ、技術・デザイン両面からみなさんをサポートすることができます。

I/Oではデザインのセッションが他にもありますので、ぜひとも、みなさんチェックしてみてください。もし、このようなデザインレビューができないのなら、どうかdesign@google.comまで連絡ください。

FORM

• FORM

昨年、Googleで初めてデザインカンファレンスを、ここサンフランシスコで開催しました。このイベントはとても素晴らしいものとなりました。このイベントは招待制なので、みなさんの中でどれだけの人がこのイベントに行けるかどうかは私にはわかりませんが、デザインコミュニティに繋がっていればその機会があることでしょうし、私たちは世界中のデザイナーを招き、講演をし、パネルディスカッションをし、ハンズオンのワークショップもしました。次のFORMを企画していますので、どうぞご期待ください。

Material Design in the Wild

さて、Material Designについてはここで終わりです。なぜなら、私たちはみなさんにもっと美しいアプリを作ってほしいですし、もっと直感的な体験をみなさんのユーザー・顧客に届けてほしいと考えています。

ここでセッションを終えますが、みなさんが実装したMaterialの事例について話す時間を設けることにしましょう。私たちはいくつかのMaterial Designを採用しようとする企業と話す機会を得ました。そして彼のストーリーを聞きました。そこで彼らの事例についてシェアしたいと思います。

Trello

まず、Trelloです。いくつかのプロジェクトを組織したりシェアするのに便利です。MobileリードのHamidはTrelloのMaterial Design化することで、プロダクトそれ自体、デザインにフォーカスすることができたと言っています。さらにははっきりとしたインパクトも数字として現れています。

• 週間ユーザーあたりのセッション数が10%増加
• セッションあたりのボード作成数が42%増加
• セッションあたりのボードを追加するユーザー数が63%増加

The Hunt

次にファッションスタイルを共有するThe Huntですが、プロダクトデザイナーのJennyは、Material Designはデザインチームをスムーズに拡張してくれるものであり非常に助かっており、それはまたチームを加速させるものだと述べています。私たちは非常に嬉しかったです。なぜならこれは私たちが望んでいたことだからです。同様に、HuntのMaterial Design化で、以前と比べて”Hunts”が30%増加しました。

Pocket Casts

最後に、ポッドキャストアプリのPocket Castsですが、前述のアプリと同じような効果をあげていますし、Material Design化により30%も売上が増加しました。ファンタスティックですね！

このような事例は、なぜMaterialを採用するのかといった証明になりますし、まさしく私たちが進むべきものです。私たちは、みなさんが現在やっていることをさらに集中・加速させることを手助けしようとしているのです。もし、Material Design化に対して説得を要するのならこれらの事例をぜひとも使ってもらいたいです。

みなさんのこのような素晴らしい成果に私たちは非常に感動しました。もう少しこのようなアプリに対してより多くのみなさんにシェアや賞賛をしてもらいたいと考え、私たちPlayチームとDevチームは18の素晴らしいMaterial Designアプリを選択し、ショーケースとしてみなさんにシェアしたいと思います。

• Best-In-Class Android Design – Google Play の Android アプリ

昨年、Material Designを紹介する動画を作成しましたが、実際それらはフェイクのアプリですが、今回並んでいるのは実際のみなさんが作ったまぎれもないリアルなアプリです。私たちは非常に興奮しております。

Material Design Award

• Material Design Awards – Articles – Google Design

さらに私たちは、特定の分野でもっとも素晴らしいMaterial Designをしているアプリを表彰するためのMaterial Design Awardも用意しました。今年は6つのカテゴリーから選びました。これらのアプリはまさしくMaterial Designのパイオニアです。

• Adaptive Layouts – Pocket
• Immersive Imagery – B&H Photo Video Pro Audio
• Elegant Typography – NYTimes – Latest News
• Seamless Browsing – Pocket Casts
• Crafted Simplicity – Weather Timeline – Forecast
• Delightful Animation – Tumblr

私たちMaterial Designチーム全体は非常にみなさんに感謝いたしております。なぜなら、システムそれ自体はただのアイデアに過ぎませんが、みなさんの日々の仕事のがんばり、貢献、革新のおかげで、Material Designがリアルなものとして、実際に手に触れるものとなったのです。本当にありがとうございます。

そういうわけで、Material Designの最初の一年は素晴らしくわくわくするような成功した一年でした。私たちは引き続き、みなさんとコミュニケーションしていきたいと考えています。何が機能して、何が機能しないのか、などみなさんから学びたい。次の一年はさらに素晴らしい一年となることを楽しみにしていますし、また来年ここGoogle I/OでMaterial Designの2歳の誕生日を祝うために集まりましょう。今日は本当にありがとうございました。

この記事は2015年5月28日に行われたGoogle I/O 2015「Material Now」セッションの翻訳です。「Material Now」では、Material Designがリリースされてからの1年間の状況や反響、事例等を取り上げています。本翻訳の前編は、Material Designの普及状況とアップデート内容について記述します。

• Material Now – Google I/O 2015

こんにちは、みなさん。私の名前はMatias Duarteです。今日はMaterial Nowについてお話したいと思います。まずは、ハッピーバースデー！Materialですね。記念すべきマイルストーンです。昨年のI/Oで私たちはMaterial Designを紹介しました。私たちは異なるプラットフォーム、異なるスクリーンサイズを超えたデザインシステムを作りたかったのです。私たちはモダンなグラフィックデザインと現実的なユーティリティ、ユーザービリティを組み合わせたかったのです。そして、後づけではないモーションデザインを重視したシステムを作りたかったのです。

信じられないかもしれませんが、私たちがMaterial Designを作っていた時、どのようにそれが受け入れられるのか、少しナーバスでした。しかし、ふたを開けてみれば、私たちはそれを気に入っていましたし、こんな素敵なクオートも見かけました。

Material Designは単なるタブレット・スマートフォン用のデザインではない。それはプロダクトが何百万というユーザーにどうコミュニケーションするのかシステマティックなアプローチである。
— Gizmodo

また開発者のみなさんも、良い反応を示してくれました。

Googleはデザインゲームを次に進めた。それは絶対的な美的感覚に頼る変わりに、個々のデザイナーをより自由にする原則を定義したのだ。
— Sacha Greif Creator of Folyo, Telescope, and Sidebar

もちろん、デザイナーのみなさんもMaterial Designが何を解決しようとしているのか、そのシステムが、すべてのインタラクティブなプラットフォーム上でデザインする上で助けになると、とても理解しているよう思えます。

Material Designは、Web全体のビジュアルを根本的に変えるポテンシャルを持っている。
— Armin Vit Under Consideration/Brand New

こういった感想を聞けて、私たちはホッとしました。しかし、本当にみなさんが聞きたいのは、どのくらいMaterialが役に立っているのか？ということでしょう。私たちGoogleは数字が好きですので、ここでMaterial Designに関する数字を見ていきましょう。

Material Designに関するデータ

まずは、私たちのMaterial Designガイドラインを見ていきましょう。私たちはこれを親しみを込めて、『スペック』と呼んでいます。この一年足らずで、250万ユニークビジターがこのスペックに訪れました。これはとても良い結果だと私は考えます。もし、あなたがYoutuberであったり猫動画をアップロードしている人であれば、これはそんなに良い結果とは言えないでしょう。しかし、これはデザインガイドラインですよ？すごくありませんか？

もっと重要なことに、このうち60%以上のユーザーが再訪問しているのです。これはMaterial Designガイドライン決して一度チラ見すれば理解できるものではないですし、何度も何度も見るような役立つリファレンスだということでしょう。特に、カラー、タイポグラフィとアイコン、そしてもちろん、FAB（Floating Action Button）などのコンポーネントのセクションが特に閲覧されているようです。

デザイナーだけでなく、開発者のみなさんもMaterialを使っています。Polymerに目を向ければ、MaterialコンポーネントをWebに実装するために必要なシステム、Paper Elementの仕様書が250万回も閲覧されています。もっと重要なことは、10万ものWebプロジェクトで、このフレームワークが使われていることです。

また、みなさんが気にかけているのはAndroid上ではどのくらいなのか？でしょう。Play Store上では25万近くのMaterial Designを実装したアプリを確認することができます。たぶん、これはそんなに大きな数字ではないでしょう。なぜなら何十億というAndroidデバイスがあるというのに、もしくはPlay Storeができてからの7年間どれだけのアプリがリリースされたのだろうか？と考えるからです。

違う観点からこの数字を見れば、2014年10月にLollipop(Android 5.0)がリリースされてから、Play Storeで出されたアプリの40％はMaterial Designを採用しています。これは良い結果だと考えています。新しくできたアプリの3つに1つはMaterialの恩恵を受けているからです。

これらは始まりにしかすぎませんが、私たちはもっとこの数字を大きくしたいと考えています。デザインに終わりはありません。そこでこれらの数字をどのように大きくするのか、またいかに早く普及させるのか、そしてMaterialをみなさんにいかに簡単に使ってもらうか説明したいと思います。

私たちは、より良く、より包括的にするためにMaterial Designガイドラインのアップデートを公開以来、続けています。実際、私たちはこれまで2回アップデートを既にしています。

最初は2014年11月、Organizing Objects、Navigation Drawers、スクローリングテクニック、Swipe to Reflesh、プロダクトアイコンのセクションを追加しました。

2015年4月のアップデートでは、Data Tables、App StructureなどのMaterial Designのガイドラインを多く追記しました。

2015年5月のアップデート

そして今日、2015年5月はガイドライン公開後もっとも大きなアップデートとなります。非常に多くのものを追加しました。その中にはデザインパターンのリニューアルも含まれています。

Floating Action Button

そう、みなさんも好きなFABです。スペック公開時は非常に限定したガイドラインになっており、どのようにフローティングアクションボタンが振る舞うのか、もっと違うトランスフォームがあるのではないか、もっと柔軟性があっては良いのではないかとみなさん考えたことでしょう。私たちもそう思います。よって今日はこのFABパターンを拡張したいと思います。これによりもっと柔軟にFABをみなさんのアプリに実装することができることでしょう。

Material Icon Library

また、今日はスペックにまったく新しいリソース、Material Iconライブラリを追加しました。このサイトには750以上ものみなさんのプロジェクトで簡単に使えるアイコンあります。しかも、ワンクリックでプロジェクトに導入できるようにしてあります。アプリ開発者のみなさんはすべての必要な解像度のアイコンをここでダウンロードできます。さらにこれらのアイコンをWebフォントとしてもリリースしてますので、リガチャ（合字）として利用できるので、みなさんはアイコンの名前をタイプするだけで実装できます。とってもクールですよね？

Adaptive Layout

• Adaptive UI – Layout – Google design guidelines

Material Designについての要望で一番大きなものと１つとしてアダプティブレイアウトがあります。このため、今回はスケーラブルで一貫性のあるグリッド、レイアウト間でのブレークポイント、振る舞いなど関する詳細なセクションを新たに追加しました。この新しいパターンはきっとどのコンテキストにもなじむことでしょう。

Device Metrics

• Device Metrics – Google Design

加えて、アダプティブデザインのためにデバイスのサイズレファレンスを新たにサイトに追加しました。これは、ウェアラブルだろうと、携帯端末であろうとも、タブレット・ラップトップであろうとも任意のサイズのデバイス上でデザインするときに役立つでしょう。そしてキーとなる解像度や密度を発見できるでしょう。もっと重要なことは、これによってどのデバイス・向きで、どのアダプティブテンプレート・パターンを使うべきか理解できるようになったことでしょう。この2つのリソースがみなさんの役に立つことを祈っています。

もちろん、ほかにもたくさんのアップデートがあります。意味のあるモーションについて解説したセクション、ローンチスクリーン、エンプティステートなどの追加と、多くのアップデートがなされました。

そして、現在Material Designはほかのプロダクト、TV、Auto、VRのCardboardに対しても適用できるよう、ガイドラインを追加しました。

今回の大型アップデートによって、みなさんのデザインのお役に立てること祈っていますし、私たちに引き続きフィードバックをください。そうすれば、私たちはアップデートを続けることができます。

私たちはガイドライン・ツール、リファレンスの枠を超えたかったのです。つまり、それらはいくぶんか静的で、ドライ、権威的なのです。そこで、私たちはデザイナーがダイレクトに繋がれる場所にするために、Google Designを新しくリニューアルしました。

つまり、それをデザイナーと開発者のコミュニティにしたかったのです。どうしてデザインをするのか、どのようにデザインするのかといった情報をシェアする場所として考えています。実用的な記事やビデオを配信することで、デザイナー・開発者が抱えている関心事、例えば、どのようにブランド・アイデンティティを損なわずMaterial Designを実装するのかなどを解決できると思っています。

また、Android、iOS、Webと異なるプラットフォーム間でデザインを簡単にするTipsなどの記事などもあります。私たちはみなさんにどこでも快適にMaterialを使ってほしいと思っています。チュートリアルもちろん、Material Designの裏側のシーンを収めたビデオなどもありますので、どうぞチェックしてみてください。

Polymer

• Welcome – Polymer

ここまで紹介してきた技術はデザイナーにとって、Materialを表現する上で便利なものですが、今日は開発者のカンファレンスですからMaterialを実装する上で役立つものを紹介したいと思います。

もちろん、最初はPolymerです。今日Polymer 1.0がアナウンスされました。これはパフォーマンス的にも満足が得られるようになったり、安定したり、APIが固定されたことを意味します。PolymerはモダンなWebプラットフォームとモバイルプラットフォームのために必要なものです。もしPolymerを使えば、簡単にスケール可能なアプリケーションを作ることができるでしょう。Polymer開発チームはパフォーマンス改善のために、一行毎にPolymerのコードを書き直したと私に言いました。とっても速くなりましたよ。つまり、プロダクション用途に使ってもらっても問題ないということであり、高品質のアプリのようなものをWeb上でも作成可能ということです。

さらに、Polymer Starter kitとCatalogはMaterial Designのアプリ作成にとりかかる前に、すべてのPaper Elementsを実際に使って試してみることができます。デモやサンプルも含んでいて、とっても見やすいサイトになっていますし、コマンドラインを使わなくてもクールなショッピングカートで各エレメンツをダウンロードできます。

Android Design Library

もちろん、MaterialはAndroid 5.0、Mでも使うことができますが、みなさんは2つの気にかかっていることでしょう。もっと簡単に使いやすいコンポーネントがないのか、そして後方互換性も広く対応してほしいと。

Support Libraryは常に後方互換性と対峙しています。これはプラグ・アンド・プレイシステムなので、古いAndroidバージョンで新しい機能を動かすことができます。昨年、Materialをリリースしたとき、appcompat libraryを提供しました。これは基本的なレイアウトとスタイリングをサポートするライブラリです。

今回紹介する新しいライブラリはAndroid Design Libraryです。このライブラリはMaterial Designのコアエレメントを使うことができ、隠蔽化された実装を簡単に導入することもできます。例えば、以前シンプルなFABを実装するにも5,6つのXMLファイルが必要でしたが、今日からは1つのフローティングアクションボタンの要素を追加するだけです。新しいライブラリは、他にも簡単に実装できるシャドウ付きのカード、複雑なサイドナビゲーションも、Navigation Drawer Viewにドロップするだけで、スペック通りの動作をするコンポーネントを実装できます。

同様にMaterialタブもまた、アプリに簡単に実装できます。私のお気に入りであり、複雑なコンポーネントで知られるツールバースクローリングも１つのコンポーネントにピンチなどの動作を設定するだけで実装できます。パレットは去年紹介しましたが、今日はそれが6倍速くなりました。詳細について知りたければデベロッパーサイトを確認して下さい。

先ほど、私はSupport libraryは完全なMaterialコンポーネントを提供していない、つまり簡単にデプロイできない、より多くのAndroidデバイスに提供できていないと申し上げました。現在、LoliipopはAndroidデバイスの10%程度しかありませんが、今回紹介した新しいSupport libraryを使用すれば、Android2.1以上のデバイスにMaterialを提供することができます。最高じゃありませんか？

（後編に続きます）

こんにちは！今回はGoogle I/O 2015の小セッションから、Justin UbertiさんとSam Duttonさんによる、”Video chat for Web, Android and iOS”のお話をお届けします。このセッションではWebRTCを使ってビデオチャットアプリを作る方法について、WebRTCの中の人であるお二人が説明してくれました。

WebRTCはWeb Realtime Communication の略で、Webブラウザ上でカメラやマイクの映像/音声を取得したり、他のブラウザと通信するための技術です。過去のHTML5Experts.jpの記事に解説がありますので、併せてそちらもご覧ください。

• HTML5でWebRTCを使ってみよう！「カメラを使ってみよう」編
• WebRTCに触ってみたいエンジニア必見！手動でWebRTC通信をつなげてみよう

セッションの始めに

最初にJastinさんから、今日は Web/Android/iOS のアプリにリアルタイムコミュニケーションを組み込む話をする、との宣言がありました。従来は「Webブラウザで、JavaScriptでできる」という部分がクローズアップされることが多いのですが、今回はあえてWebブラウザ以外の「Androidネイティブアプリ」や「iOSネイティブアプリ」でも使えるということを強調した内容になっています。そう言えばセッションのタイトルも「WebRTC」という言葉は使っていませんでした。

セッションの冒頭では、関連する資料の公開先が案内されました。どちらもGoogle Docs上で共有されています。

• 関連する様々なリソースのまとめ g.co/webrtc
• 今回のプレゼンの資料 Video chat for Web, Android and iOS

余談ですが企業でGoogle Apps for work を使っていてdocs/driveが使えないように機能制限している場合、アカウントにログインした状態では見れません。私も最初は見れなくて、地味にはまりました。

Google I/Oの大きなセッションのビデオは、公式サイトで公開されています。残念ながら本セッションのような小規模セッションのビデオは公開されていませんが、Google I/O 2015のお土産にもらったCardboard用のアプリからGoogle I/Oの様子をVRで見ることが可能です。本セッションの映像もVRでみることができるので、今年のCardboardをお持ちの方はお試しください。

これまでを振り返る

まずはこれまでの経緯を振り返えっての説明がありました。「数年前、Webをリアルタイムコミュニケーションのプラットフォームにしようと考えた」と言います。

• あらゆるアプリでリアルタイム通信を可能にしたい
• オーディオ、ビデオ、独自のデータを扱えるようにたい
• エコシステムを構築するためにオープンなプロトコルを使いたい

そのために次の点について力を入れたとのことです。

• 実用になるための高品質
• 可能な限りPeer-to-Peerで通信
• End-to-Endの暗号化を提供

実に野心的なプランで、ここでSamさんが”Crazy Plan!”と突っ込みます。

• そんなプランに取り組み、WebRTCができあがった
• しかしその後、モバイルシフトがものすごい勢いで起こった
• モバイルでは、コミュニケーションアプリに非常に多くの時間を使っている

利用シーンの変化に合わせるため、AndoridとiOSのネイティブアプリでもWebブラウザと同じことができるようにした、との説明がありました。そしてここで、(WebRTC改め)”AndroidiOSWebRTC” と大きく書いたスライドが登場しました。

この通信技術は、Webブラウザだけリアルタイムコミュニケーションではなく、すべてのプラットフォームで使えるリアルタイムコミュニケーション技術だよ、との力強い声明です。

WebRTCの普及については、次のように説明しています。

• いまや 1.5 billion (15億)を超えるWebRTC対応ブラウザが使われている
• また 3 billion (30億)を超える回数、WebRTCのアプリがダウンロードされている
• 現在はWeb, Android, iOS の3つのプラットフォームで使える様になっている

30億回ダウンロードというのはにわかには信じがたいですが、アップデートも含めればそうなるのでしょう。 FacebookのメッセンジャーがWebRTCを使っているという話もあるので、それを含めれば30億回に到達するのかもしれません。

ソースコードの紹介

次に、実際のソースコードの概要について、3つのステップで説明がありました。Webブラウザ、Android、iOSのケースを順番に比較しています。

(1) カメラ、マイクへのアクセス

Webブラウザの場合

navigator.getUserMedia(constraints, onStream);
function onStream(localStream) {
  // do something with stream
}

Webブラウザの場合、getUserMedia()を使って、リアルタイムの映像/音声データをセットでMediaStreamという形で取得できます。取得に成功するとコールバック関数（この例では onStream ）に渡されるので、そこで処理します。映像/音声の取得については、こちらの記事もご覧ください。

• HTML5でWebRTCを使ってみよう！「カメラを使ってみよう」編

Androidの場合

VideoCapturer c = VideoCapturer.create(device);
PeerConnectionFactory factory = new PeerConnectionFactory();
MediaStream localStream = factory.createLocalMediaStream(streamName);
VideoSource s = factory.createVideoSource(c, constraints);
VideoTrack t = factory.createVideoTrack(trackName, s);
localStream.addTrack(t);

Androidの場合は、カメラの映像とマイクの音声は別々に取得するようです。

• まずVideoCaptureクラスを使ってVideoSource取得します
• 次にVideoSouceから、実際の映像であるVideoTrackを取得します
• VideoTrackが取得できたら、WebRTCで映像/音声を扱うためのMediaStreamクラスの配下に加えます

興味深いのは、MediaStreamのインスタンスはPeerConnectionFactoryから作る、というところでしょうか。Androidの通常の映像処理とは異なり、WebRTC専用クラスということだと思います。
コードの紹介では出てきませんでしたが、マイクからの音声もAudioTrackとして取得してからMediaStreamの配下に追加するのでしょう。

iOSの場合

iOSもAndroidと同じく、VideoCapture → VideoSource → VideoTrack → MediaStream という流れになります。

RTCVideoCapturer* c = [capturerWithDeviceName device];
RTCMediaStream* localStream = [factory mediaStreamWithLabel:streamName];
RTCVideoSource* s = [[factory videoSourceWithCapturer:c ...];
RTCVideoTrack* t = [[RTCVideoTrack alloc] source:s ...]; 
[localStream addVideoTrack:t];

(2) PeerConnectionを使った通信

次は通信です。通信で使うRTCPeerConnectionがWebRTCの肝で、裏で非常にたくさんのことをやっている、との説明がありました。

Webブラウザの場合

pc = new RTCPeerConnection(config);
pc.onaddstream = onRemoteStream;
pc.addStream(localStream);
pc.createOffer(onCreateSuccess);
function onCreateSuccess(offer) { sendMessage(offer); }

Webブラウザの場合はPeerConnectionのオブジェクトを作るところから始まります。

• PeerConnecitonのオブジェクトのonaddstreamイベントハンドラに、相手側のメディア（映像/音声）を扱う処理を設定する（この例ではonRemoteStream）
• PeerConnecitonのオブジェクトにaddStream()で自分のメディア（映像/音声）を教える
• 通信を始めるための情報であるSDPを、createOffer()を呼び出して生成する
• SDPが生成されたらコールバックが呼ばれるので（この例ではonCreateSucess）、その中で相手側に送信する

Peer-to-Peer通信を始めるまでの手順をシグナリングと呼びます。シグナリングについてはこちらの記事もご覧ください。

• WebRTCに触ってみたいエンジニア必見！手動でWebRTC通信をつなげてみよう
• WebRTC初心者でも簡単にできる！Node.jsで仲介（シグナリング）を作ってみよう

Androidの場合

PeerConnection pc = factory.createPeerConnection(iceServers, constraints, observer);
pc.addStream(localStream);
pc.createOffer(this, offerConstraints);
public void onCreateSuccess(final SessionDescription offer) {
 sendMessage(offer);
}

Androidも流れは同じです。FactoryでPeerConnectionを生成する際に、observerを指定するのがAndroid流のようですね。PeerConnectionにaddStream()して、createOffer()を呼び出し、生成されたSDPをobserver側のメソッド（この例ではonCreateSucess）で処理しているようです。

iOSの場合

RTCPeerConnection* pc = [factory peerConnectionWithICEServers:iceServers constraints:constraints delegate:self];
[pc addStream:localStream];
[pc createOfferWithDelegate:self constraints:offerConstraints];
- (void)peerConnection:(RTCPeerConnection *)peerConnection
    didCreateSessionDescription:(RTCSessionDescription *)offer
    error:(NSError *)error {
  sendMessage(offer);
}

流れはAndroidと同様ですが、delegateを使うのがiOS流ということでしょうか。createOffer()で作られたSDPを、delegateのdidCreateSessionDescrition()で処理しているようです。

(3) 表示

最後は動画を表示する部分です。

Webブラウザの場合

function onRemoteStream(remoteStream) {
  videoElement.src = window.URL.createObjectURL(remoteStream);
}

おなじみの video タグを使います。 URL.createObjectURL()を使って、MediaStreamをvideoタグで表示できる形に変換します。

Androidの場合

public void onAddStream(final MediaStream stream) {
  VideoTrack track = stream.getVideoTracks(0);
  YuvImageRenderer renderer = remoteRenderer;
  track.addRenderer(new VideoRenderer(renderer));
}

MediaSteamからvideoTrackを取り出し、OpenGLベースのVideoRendererを使って描画する、という流れの様です。OpenGLベースなので描画にGPUを使っていて、CPU負荷が低いのが特徴とのこと。 ソースコードの中にYuvImageRendererとVideoRendererという2種類のRendererが登場していますが、私には役割の違いがよく分かっていません。すみません…。

iOSの場合

- (void)peerConnection:(RTCPeerConnection *)peerConnection
       addedStream:(RTCMediaStream *)stream {
  RTCVideoTrack* track = stream.videoTracks[0];
  RTCEAGLVideoView* view = _remoteVideoView;
  [track addRenderer:view]; 
}

OpenGLベースのRTCEAGLVideoViewというものを使うそうです。VideoTrack.addRenderer()を使うところは、Androidと同じです。

詳細は

Web上に公開されている2つの記事を参考にしてい欲しいとのことでした。（どちらも、WebRTCを使ったビデオチャットサービスを提供している、apper.inのブログ記事です）

• Introduction to WebRTC on Android
• Getting started with WebRTC on iOS

AppRTCを使ったデモ

実際に動くデモを用意していますとのことで、AppRTCについての紹介がありました。Hight performance, fast call setup, easy to understand and extend の3つを目指しているとのことです。 実際にChromebookとNexus6 を使ったデモが行われました。Nexus6ではエンコード側でもハードウェア(GPU)を使えて、720pのHD動画が快適に送れます。

フロントカメラからバックカメラに切り替えて、観客も映して見せました。

apprtc関連として、次の情報も紹介されていました。

• apprtcの短縮URLとして、appr.tc が使える
• ソースコードはgithubで github.com/webrtc
• ブラウザ側で[i]キーを押すと、統計情報(stats)が表示される

統計情報(stats)を表示しているところ

自分でも試してみましたが、Chromeで表示できる統計情報(stats)はどのような通信が行われているかを知る手掛かりとして、とても興味深いです。

つながるためのサーバー側の仕組み

デモの後は、実際の通信がつながるまでの裏側についての解説です。

シグナリングサーバー

Peer-to-Peer通信を始める前にはシグナリングと呼ばれる処理が必要ですが、AppRTCではそのサーバーとデバイスの間の通信にはWebSocketを使っているそうです。（シグナリングについてはこちらをご覧ください）

AppRTCならではの工夫(Smart signaling)として、最初のユーザがシグナリングサーバーに接続した際に、ユーザの接続情報（おそらくSDPのことだと思われます）をサーバー側にキャッシュしているとのこと。2番目のユーザが接続してきたら、サーバーから直ちにキャッシュされた情報を渡すことで、接続までの時間を短縮しているそうです。

リレーサーバー(TURN)

Peer-to-Peerで通信できないケースでは、リレーサーバー(TURNサーバー)が必要です。AppRTCでは次の仕組みを用意しているそうです。
TURNサーバーの役割については、こちらの記事をご覧いただくと参考になると思います。

• 壁を越えろ！WebRTCでNAT/Firewallを越えて通信しよう

• Tailbone … オープンソースのGoogle App Engineモジュール（動的にGoogle Compute Engineのインスタンスを起動する仕組みのようです。そのなかのmeshというものが、webrtc関連のように見えます）
• Coturn server + (Tailboneで起動される)オンデマンドのGoogle Compute Engineインスタンス

これによってすべてのGCEのゾーンでTURNサーバーが動き、世界中で快適に接続できるとのことでした。 ユーザになるべく近いゾーンのTURNサーバーを経由することで、遅延を小さく抑えるようにしているのだと思います。

さまざまな工夫によって「通信が確立するまで500ミリ秒しかかからないよ」と、その短さを強調していました。

最後に、改めて「情報はg.co/webrtcを見てほしい」との紹介のあと、「フィードバックを歓迎します」と締めくくられました。

おまけ

セッション終了後、Justinさんに質問してみました。

• Q. iOSのSDKでTURN over TCPがProxy設定を見てくれないようですが？
• A. 先週(5/21)その修正が反映されました。最新のソースで試してください

• Q. ChromeのBandwidth Estimationで、帯域の上限を指定するにどうすればよいですか？
• A. SDPのb=ASで指定すれば、その上限は超えません
• Q. 指定しているのですが効いていないみたいです。2Mbit/secぐらいです
• A. それはデフォルトの値ですね。指定が間違っていると思うので確認してください

どちらもちょっと間の抜けた質問だったようです。失礼しました…。