2012年12月23日
Chromeから綺麗に消えた Web Intents。その理由を追ってみる
2012年も残すところあと1週間あまり、明日はクリスマスです。今年1年はWebとデバイスとの連携を中心に色んな活動をしてきました。「最新のWeb技術(Chrome の Socket API)を用いるとブラウザから直接TVを操作できる」ことを紹介し、それと Web Intents を組み合わせると「YouTubeで検索したビデオを、テレビで視聴することができるよ」といったデモ(内容は、下のYouTubeをチェックしてみてください)を紹介してきました。
しかし、残念ながら(たぶん)2012年12月18日以降のChrome canaryで、Web Intents が使えなくなりました(Chromiumの対応Issueはこれ)。10月末ぐらいから、chorme://flags で「有効」にしないとWebページからは使えなくなっていた(Chrome の Web Apps では使えていました)のですが、この度、完全に。。。(まぁ、怪しい状況にあったのは、11月のW3Cの会議で聞いてはいたのですが)チーーーーン
ということで、(おそらく)今年最後のエントリーでは、この辺の事情について書きたいと思います。なお、本エントリーはHTML5 Advent Calendar 2012 の記事です。
デバイス連携に Web Intents は必須ではない
まず、最初に断っておきますが、ブラウザから TV を操作するような、Webベースのデバイス連携を行うに辺り、Web Intentsは必須のAPIではありません(決して強がりではないですよ!!)。TV を DLNA なり、デバイス独自のインタフェースで操作するのに必要となるのは、Socket API(Chrome Packaged Apps v2 のAPI)です。先に紹介したデモで Web Intents がやっているのは、検索した YouTube 動画のURLを渡すところ。デバイス連携シナリオでは、「Webサイトと(デバイスを操作する)Web Appsを簡単に連携する」のが Web Intetns の役目です。
決して Web Intents が今回Chromeから消えたからといって、
Web からのデバイス操作が「オワコン」になったわけでは無い
ですので、その点は注意してください。(でも、あると便利なんだよなーーー。。。。残念)
Web Intentsに対する逆風は UI Issue
「Web Intentsを、現行仕様のまま検討を進めるのは厳しい」ことが正式に表明されたのは、今年の11月にフランス・リヨンで行われたW3Cの技術総会(TPAC2012)。Google の Greg さんよりアナウンスされました(この時の模様は議事録として公開されています)。議事録自体はかなりの長文ですので全てを紹介することは避けますが、Gregさんの冒頭で述べられた発言
... current state, it's behind a flag in Chrome 24からかいま見れるように、Web の User Interface と Web Intents との親和性。そして、User Experienceとの親和性が主なポイントとなっています。議事録からそれをまとめると、
... you go to chrome://flags and enable
... web intents from there
... implementation, mostly UI issues
- Tabブラウザの問題
- Web Intentsでは、Web アプリを呼び出すと別のタブで表示される。ここで、Web アプリ間のデータ連携が正常に行われるためには、両方のタブが立ち上がっている必要があるが、タブは簡単に閉じることができるため、APIとして上手く動作しなくなってしまう。
- Pickerの問題
- 普通にWebブラウジングしている最中に、Web Intents でアプリ選択ウィンドウ(ピッカー)が表示されるのは、今までのWebサービスでは無かったこと。Extension や Web Apps に慣れているユーザーであれば、まだ「あーそーゆーことね」となるが、大部分のユーザーにとっては「何これ???」になってしまう。
- Persistant connectionの問題
- 最初にあげたTabの回避策として、アプリをコールした時に新たにタブを開かず、同一ウィンドウの中で遷移する(navigation model)ものがある。しかし、現在の Web Intentsのスペックでは、二つのアプリ間で継続してデータ連携するモデルが入っており、navigation modelとはマッチしない(navigation modelだと、呼び出し元のページは一旦閉じられてしまう)
上の発言にあるように、この会議の直前に、Chrome://flagsで有効化しないと Web ページからは使えなくし、Web Appsからは、フラグを有効化しなくても使える状態となっていたのですが、これは主に 2 番目の問題に対応するためだったわけです。
他にも類似の API が・・・
Web Intents に関しては、UI/UX以外にも課題があります。それは、類似のAPIがいくつか提案されているという点です。
- Web Activity
- Mozillaが提案している Web Intents に類似の API。Android IntentsのFirefox OS版という位置づけ。Web Intentsが一般のWebページでも使える一方、Web Activityは Web Appsでしか使えない(なので、前述のタブのような問題もない)
- Register Protocol Handler
- 例えば、mailto: に対してGMailを呼び出すように、特定のプロトコル(mailto:など)に対応するWebアプリを登録する API。Web Intents の中で、片方向の Activity (SHARE、VIEWなど)については、このAPIと機能的にかぶる。
- Network Service Discovery API
- Operaが提案している、UPnPやmDNS の discovery を実行する API。元々のメインターゲットは、DLNAなどのホームネットワークデバイスをブラウザから操作することを主目的としていたが、自分およびリモートデバイス内のWebサービスを発見し、それと連携する仕組みとして考えると、Web Intents とは機能的にかぶる部分が大きい
まとめ
正直 Web Pages 向けにはきついけど、Web Apps 向けには、このまま存続するんじゃないかなーーーと個人的には楽観していた Web Intents ですが、綺麗サッパリ Chrome から消えてなくなってしまいました。ただ、 今回の措置を僕は悲観的には見ていなくて、「Web アプリ間の連携機能を、今一度しっかりと整理しよう。そのために、スタートポイントに戻ろう」という Google からのメッセージなんじゃないかな?と見ています(正式なアナウンスはまだ出ていませんが・・・)。
あと、興味深いのは、こうなった経緯ですね。技術的な API 仕様の問題というより、「現在のWebになじむか」「一般的なWebの利用者が、このAPIを受け入れられるか」というコンテキストから今回の措置は起こったわけで、そういったユーザー目線というポイントが標準化の舞台で大きなインパクトを持つということを、教えてくれます。
研究者・開発者というのは、もちろん「こーすれば便利になるし、みんなハッピーになるじゃん」という気持ちで新しいテクノロジーを生み出そうとするわけですが、それが本当に幸せをもたらすかどうかは、利用者がそれを受け入れてくれるかということにかかっているわけです。それは大切なことと認識しつつ、その観点を見逃してしまいがちになるのが現実だったりするわけですが、標準化という大きな流れの中で、そのことを教えてくれた出来事でした。
Web アプリ連携は大きなテーマ。さて、Web Intentsはどのような形で再構築されるんでしょうか(きっと、完全 give up では無いと、僕は信じています)。楽しみですね!!

トラックバックURL
この記事へのコメント


ティファニー 指輪 メンズ http://www.yamaju.me/diarypro/data/tiffany_co.php
エルメス ジップザップ 二つ折り財布 グリーン レザー http://www.api.lecco.it/packing/hermes-at-722.html