１年半ほど前に作った i-mode 用の Java アプリを元に、AU 用のバージョンを作っている。
Java は Write Once, Run Anywhere （一度書けばどこででも動く）をキャッチコピーとして登場してきた。
しかし、実際には Java の実行環境(JavaVM)の実装の違いなどから、「Write Once, Test Anywhere」（一度書いたら、あらゆる場所でテストしろ）などと揶揄されてきた。
まぁ、今回も i-mode と AU の違いがあるのでそれなりの修正は必要だろう、と考えてはいたのだが…
小型機器用の Java 実行環境を KVM と呼ぶ。Kiro byte で動く JavaVM の意味だ。
実際には、Java は実行環境とともに「クラスライブラリ」というものが重要となる。
KVM と組み合わせるには、CLDC と呼ばれるライブラリ群を使う。
i-mode も AU も、KVM + CLDC を基本としていることに変わりはない。
携帯電話用に、CLDC に加えて使うライブラリを MIDP という。
これは、性能も解像度も低い携帯の画面で使うことを想定した、入出力ライブラリだ。
i-mode が Java 対応した時、MIDP はまだ開発中だった。そのため、DoCoMo は MIDP ではなく、独自のライブラリ群を使った…と、表向きには語られている。
しかし、MIDP をベースとして作られたものなので、大きな違いがあるわけでもない、とも語られている。
しかし、ぜんぜん違う。
i-mode では、画面出力を基本的に「HTML 互換」としていた。
i-mode で WEB は見られるのだから、その部品を使う分には難しくないという、非常にもっともな考え方だ。
以上が、i-mode の Java で使える主要な入力部品だ。
しかし、MIDP では、最後の２つ、ドロップリストとボタンがない。
ボタンに関しては通常は一連の入力に１個あればよいもので、携帯電話についているボタンに機能を割り振ることは可能なのでなくてもそれほど問題はない。
問題はドロップリストだ。
というようなインターフェイスを作ることが出来ない。こんな単純なことをラジオボタンで表現すると
という、非常にうざったい画面になってしまう。
実のところ、グラフィックを表示する画面はあるので、最悪の場合「すべてを自前で作る」と解決方法はある。
ただし、この場合文字入力と共存することは出来ない。グラフィック画面ではボタンの入力を直接知ることが出来るかわりに、文字入力が出来なくなるのだ。
加えて言えば、目に見えない「裏」の部分もずいぶん変わっている。
Java では、ユーザーの入力に即時に答えられるような割り込み機能を「Listener」と呼ばれる仕組みで実現している。
i-mode の Java では Listener が豊富に用意されていた。MIDP ではほんのわずか。
たしかに、同じようなことは出来るようになっているのだが、豊富に用意されているほうが使いやすいことは事実。
また、画面表示がらみだが、Font に関する設定も i-mode のほうが柔軟だった。Font というのは奥の深い世界で、英語の場合文字の位置は「ベースライン」を基準として考えられる。
文字は、 1. 文字の高さ 2. 文字の幅 3. 文字の、ベースラインより上の高さ 4.文字の、ベースラインより下の高さ の４つの「サイズ」がある。
i-mode では、すべてを知ることが出来た。長い文字列を指定のドット数以内で表示する時、どこで折り返すと良いかを調べる命令まであった。
しかし、AU では「ベースラインより下」を知ることが出来ない。高さから「上」を引き算すればわかるが、余計な手間がかかる。
折り返し位置も教えてくれない。任意の文字列が何ドットになるかという「幅」は教えてくれるので、少しづつ文字の長さを変えながら自分で調べることは出来るが、これも非常に余計な手間だ。
うむむむむむむむ…
最近、i-mode の Java は「MIDP がまだ出来ていなかったから」独自仕様にしたのではなく、「MIDP があまりにもダメだから」独自仕様にしたのではないかと疑っている。
だとすれば、それに気づかずに MIDP を導入した AU/J-Phone は…
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |