内部情報とか全く持ってないヒラAndroid開発者である俺がHoneycombを大予想してみる。
現時点での最新情報はこの辺
動画：Android 3.0 ” Honeycomb ” 紹介、タブレット最適化UI デモ
3Dで超かっこいい！ グーグルの新タブレットOS「Android 3.0」が全貌公開（動画） : ギズモード・ジャパン(イタコ注意)
ほんとは
Android ” Honeycomb ” はデュアルコアのタブレット限定、既存製品からアップグレード不可？
この記事を誤報ではないかと大予想してやろうと思ってたんだけど
Android 3.0 Honeycomb に必須プロセッサ要件なし、開発者が証言
俺がブログに書く前にGoogleの中の人に否定されて誤報確定してしまった。ちぇ。
以下、繰り返しになりますが内部情報とか全く持ってない一般のAndroid開発者・ウォッチャーの意見です。
■Honeycomb(Android 3.0?)はタブレットとスマートフォン共通のメジャーアップデートとなるであろう
つまり「タブレット専用になる」とされている報道は誤報であろうと予想
その理由
(1)ブランチする利点が見当たらない
タブレット用とスマフォ用にブランチするとGoogle側の開発コストが大幅に増大する。また、もちろん開発者側のコストも増大する。
Honeycombの「タブレット向け新UI」部分はコード全体で見ると極一部であり、恐らく98%だの99%だのが結局共通になる。つまり、同じコードベースでビルドオプションとしてタブレット向けとスマフォ向けの切り替えを行う方が簡単である。
(2)既にGingerbreadにタブレット向け対応が入り始めている
「Honeycomb=タブレット専用説」では「Gingerbread系列」がスマフォ専用となるとされているが、実のところGingerbreadで既にタブレットを想定した対応が追加されている。具体的には従来7インチまでの対応だったマルチ解像度対応APIが10インチ強まで拡張されている。このためGingerbreadはスマフォ専用ではなくスマフォ・タブレット両対応のOSのロードマップ上にいると考えられる。
ちなみに俺的にはHoneycombでは13～14インチ(xx-large?)まで拡張されると予想している。
(3)先月、Andy Rubin神がHoneycombは両対応であると明言している
ここ1か月でブランチが決まったとするとロードマップは破滅的な変更に見舞われたはずで、逆説的に考えると順調に進んでいるHoneycombの状況から見てそんな激震が起こったとは考え難い。
(4)総括
以上から、GingerbreadとHoneycombは単一のロードマップ上に位置しており、Gingerbreadは単にHoneycombの前身である、と予想する。
経緯から見てもGingerbreadでの更新内容から見ても、開発が遅れたため先行リリース出来る部分だけ切り出してGingerbreadとしてリリースし、(本来Gingerbreadとして出すつもりだった)Honeycombを後から出す、という流れと考えた方が自然だと思われる。
■Honeycomb新UIに関する予想
(1)アプリ単位での対応である
動画で新ホームや新ブラウザや新Gmailが出てきているが、これらは元々OSそのものというよりバンドルされた単なる標準アプリである。
恐らく多くの標準アプリが新UIに合わせてリライトされるが、OSの根幹部分は完全互換で共通となるであろう。
(2)標準アプリはブランチするのか
これらのアプリの作り方は2通り考えられる。
1つはスマフォ用アプリとタブレット用アプリを別々に開発してどちらかを標準バンドルするという形。これはつまりOS基幹部は共通であるが標準アプリはブランチするということになる。
もう1つはスマフォ用もタブレット用も単一ソースで開発してビルドオプションやリソース設定で切り替えるという形。iPhone/iPadで言うところのユニバーサルアプリに似ている(それにしてもこの呼び方はどうかと思う……)
「Androidらしい」のは後者であると考える。
多解像度対応などで単一ソースのリソース切り替え対応というのは今でも常套手段である。各アプリもUI部分を除けば内部処理はどうせ共通のはずでブランチして2倍のメンテコストが掛かるより、ユニバーサル化して1.2倍くらいのメンテコストになった方が幸せである。
標準アプリはAOSPベースでも30個くらいあるのでこれを全部ブランチして二重メンテする愚は犯さないのではないだろうか。
また後述の新API予想にも関係する。
■新API予想
これはGingerbreadの予想を書いた時の蒸し返しになる。
(1)マルチカラムUIのための新Activity機構
これは今度こそ必須になる。現在のActivity機構では新Gmailのようなアプリは(シングルカラムアプリが楽勝なのと比べると)作りにくい。
これはActivity機構の根幹に関わるため、大幅な強化が来ると思う。というか、来てくれないと即ち「力技で書いてね☆」という意味になるので、アプリ開発者としては大変困る。
現行でも複数のActivityを管理する(タブなどで使われている)ActivityGroupというクラスはあるが非常に使いにくいので、マルチカラムを「ちゃんと」管理するためのActivity機構は必須であると思われる。
(2)シングルカラムUIとマルチカラムUIの単一ソース管理
上で述べた標準アプリを単一ソース管理する場合、Activity部分のソースを二重管理するというのは筋が良くないしAndroidらしくもない。賢明なGooglerの皆さんがそのような愚かな管理方式を採用するはずがない(ことを期待する)
どうせActivity機構に新流儀が出来てしまうとどうせUI周りはリライトになる。となるとシングルカラム・マルチカラムを単一ソースで管理するなら、Activityを別々で用意するより、layout xmlで切り替えられるレベルまで統合されている方が開発効率は良くなる。何よりその方がAndroidらしい。
きっとAOSPの標準アプリのMailあたりを見るとヒャッホーって感じになってくるに違いない(ことを期待する)
■予想される問題
上記予想が当たった場合、タブレット・スマフォ両対応アプリを書くために、従来なら1.6以上対応として開発されていたようなアプリまでが新規開発だと3.0以上対応(3.0未満切捨て)になるケースが増えてくると思う。となると3.0未満端末は色々と不幸な目に遭うかもしれない。
まあスマフォでは1.6の切捨てもまだ進んでないくらいだし、3.0未満まで切捨てになるのはスマフォでの3.0シェアが最低8割は超えてからになるのだろうけど。
……というかその場合、過渡期の開発者は色々めんどくさいことになるね。