山田祥平のRe:config.sys
【特別編】猫も杓子もAndroid
（2014/7/3 11:19）
米サンフランシスコで開催されたGoogle I/Oでは、ハンドヘルドデバイス、つまり、スマートフォンやタブレットに加え、マルチスクリーン体験をもたらすプラットフォームとして、Wear、Auto、TVという3つの提案を宣言した。今後のAndroidを考える上で、極めて重要な要素でもある。なぜなら、これらのプラットフォームはAndroidでありながら、これまで慣れ親しんできたハンドヘルドデバイスとは異なる特別な振る舞いをするからだ。
大きく進化する通知の機能
「L Developer Preview」(以下、L)では、Notifications、いわゆる通知のメカニズムに大きな手が入る。Android端末の画面上部を下にスワイプすると引き出されるのが通知領域だ。これまで、黒地に白い文字が表示される程度だった通知領域は、Material Design(マテリアル・デザイン)への準拠により、きわめてリッチなものとなる。
さらに、ロック画面通知がサポートされるようになる。画面がロックされているときにも通知を出せるようになるのだが、ロックされているのに全ての通知を表示してしまってはロックする意味がなくなってしまう。そこで、通知を「プライベート」、「パブリック」、「シークレット」という3種類に分類し、ロック画面への通知の有無やスタイルをアプリケーション側から指定できるようになっている。例えば、「プライベート」の場合は、Twitterから3通のメッセージがあることは通知されても、それが誰からのものなのか、どんな内容なのかは表示されない。また、シークレットの場合は、通知があることさえ表示されないといった具合だ。
そして、「Heads-up」と呼ばれる通知のメカニズムが用意される。これは、特定のアプリなどが全画面を占有し、通知バーが表示されていないときにも、緊急度の高い通知を画面最上部にポップアップさせる機能だ。
また、通知はクラウドを通じてデバイス間で同期される。だから、タブレットを使っているときにもスマートフォンに表示される通知を見逃すことはない。
さらに重要な要素として、通知内容にプレイバックコントロールと関連付けられたリッチなコンテンツを用意することができるようになった。
これだけの要素を見ているだけでは、それがどうした感が強いのだが、実際に調べていくと、シンプルでありながら、Androidの世界観に大きな拡張をもたらすことが分かる。
通知とインテントがWearのUXを実現
通知の機能に大きな手が入ったのは、Android 4.3、すなわちJelly Beanが登場したときだ。このとき、通知リスナーという機能が実装された。OSがアプリからのメッセージを受け取り、その内容を通知領域に表示するだけではなく、別のアプリがリスナーを使い、その内容を受け取れる仕組みだ。
さらにLでは、通知の内容がWearにブリッジされるようになった。従って、アプリは何もしなくても今まで通りに通知をするだけで、その内容がペアリングされたAndroid Wearに渡る仕組みが実現されている。そして開発者は、スマートフォンアプリ内に通知をWear用に用意する機能を実装することで、Wearに最適化した通知内容を送れるようにもなっている。
通知は、そのものをタップしたり、表示されているボタンをタップすることで、さまざまなアクションを指示することができる。このときに起こるのがインテントだ。Android OSの最も特徴的な要素であるインテントは、いわゆる共有機能として日常的に目にしていると思う。例えば、このページをスマートフォンで見ているときに、メニューから共有を選ぶと、共有できるアプリの一覧が表示され、その中から任意のものをタップすれば、ページ内容やURL、タイトル情報など、相手が受け取れるデータが別のアプリに渡される。この仕組みをうまく利用しているのがAndroid Wearなのだ。古い仕組みとしては、ネットワークパイプのメカニズムにも似ている。いわゆるツールキットアプローチの1種だ。
Android Wearは、スマートフォンから通知を受け取り、その通知に対してユーザーが起こしたアクションをスマートフォンに戻し、インテントを発生させて、さらにその結果を通知として受け取ることを繰り返してUXを実現している。
通知を表示するセカンドモニタがAndroid Auto
一方、Android Autoはどうか。こちらは、通知のプレイバックコントロールをうまく利用している。スマートフォン上で稼働するアプリは、実は、自分自身がAndroid Autoで動いていることを知らなくてもかまわない。アプリはメディアサービスを使うように機能を拡張し、再生するコンテンツ内容をサービスに渡す機能を実装するだけでいい。スマートフォンで音楽を再生すると、通知バーにジャケット写真や一時停止、次へ、前へなどのボタンが表示されるが、それと同じ仕組みが使われる。これによって、Auto用のアプリを別に用意する必要もなく、既存アプリの機能の大部分を再利用することができるわけだ。
Autoデバイス側のクライアントは、メディアサービスからコンテンツ内容を受け取り、運転しながら操作しやすいように最適化したUIでそれを表示する。これによって、アプリは特にAuto専用のUIを自分で持つ必要もなければ、ユーザーの操作を直接受け取る仕組みを持つこともない。画面解像度を気にする必要もなければ、タッチ操作によるメッセージの受け取りを気にする必要もないのだ。
つまり、Android Autoは、通知領域の拡張であると考えればいいだろう。ここでもLの通知サービスが重要な意味を持っていることが分かる。
Chromecastの拡張としてのAndroid TV
しかし、Android TVだけはちょっと違う。このデバイスだけは、スマートフォンやタブレットの力を借りずに、スタンドアロンで稼働しなければならないからだ。しかも、このデバイスでは、Androidアプリに、開発者がちょっとした宣言を加えるだけで動いてしまう。だが、Googleは、それを推奨しない。さらに、Google Play Gameサービスによって、ゲームのプラットフォームとしては使うが、基本的にはChromecast的にコンテンツのプレーヤーとしての利用を推進しようとしているように見える。
利用にはGoogleアカウントが必要だが、ユーザーがサインインを拒んだ場合にはゲームアプリはそれを強要しないようにするべきだとしている。ゲームの結果のセーブについても、クラウドセーブが推奨され、ローカルデータを削除できるようにする機能を用意すべきだとも。これによって、ユーザーは、TVであろうが、スマートフォンであろうが、タブレットであろうがクラウドを介して唯一の自分自身のゲームデータを保持し、どこからでも参照することができる仕組みだ。そして、Googleは、ゲームアプリがWebブラウズ機能を持つことも推奨しない。TVはブラウズには向いていないデバイスであるともいう。
Android TVにとってゲームアプリはやはり特別な位置付けにあるようだ。基本的にはクラウドにあるコンテンツと放送波をシームレスに楽しむためのものと考えていいだろうだからこそ、Chromecastで実現されたGoogle Castを扱うMediaRouterフレームワークの機能が重要視されるべきだ。
パーソナル性が希薄な新プラットフォーム
こうして今回のGoogle I/Oで発表された新しいプラットフォームを見ていくと、ハンドヘルドデバイスがパーソナルなものであるのに対して、そのほかのデバイスは同じようにAndroid OSが稼働していても、パーソナル性ができるだけ希薄なものになるように考えられていることが分かる。
ただ、時計はとてもパーソナルなもので、肌身離さずという使い方がされる。だから無防備だ。でも、無条件に通知が腕に飛んでくるにしても、スマートフォンから離れれば、ほぼただの時計になってしまう。Android Wearがクラウドと通信するには、必ずペアとなっているスマートフォンが必要だ。もっとも、スマートフォンと時計を一緒に放置したら、プライバシーはないに等しい。現時点でのAndroid Wearには、ロックするという概念が実装されていないからだ。
Googleでは、今回のGoogle I/Oで、人々の暮らしの中で身近な存在になっている各種の画面を新たなプラットフォームとして提案し、Androidの存在感を高める方向性を提示した。しかも、開発者は、通知やインテントといった既存アプリで慣れ親しんだ方法で、これらのプラットフォームへの対応ができるわけだ。
おそらく、各種のアプリがこれらのプラットフォームに対応するのに、それほど長い時間はかからないだろう。そして、アプリが増えれば、プラットフォームは普及する。しかも、ユーザーは新たな画面プラットフォームをパーソナルなものとして扱わなくてもいい。あらゆるデバイスをまたいで、自分の暮らしをAndroidに掌握されてしまうようなことはないことが分かる。うまい手を考えたものだと思う。