はじめに
Javaは理論上は移植可能なので、Javaモバイルアプリケーションを開発するときにも、すべてのJava対応デバイス上で正しく実行されるはずだと思いがちです。ところが、理論上の事柄が大抵そうであるように、これも実際にはうまくいきません。J2MEモバイルアプリケーションはまだ日の浅い技術ですが、多くの開発者は、こうした共通利用の問題がMIDP2.0やJTWIのような新しいイニシアチブによって簡単に解決されることはないだろうと述べています。
J2MEはグローバルに移植できるとしても、J2MEアプリケーションはそうではないというのが現実です。つまり、バイトコードはすべてのJavaハンドセットで正しく実行されますが、アプリケーションの動作はハンドセットごとに個別に調整しなければならないのです。モバイルデバイスは1200種もありますが、いずれも能力が異なり、MIDPを含めて種々のJavaプラットフォームをサポートしており、またオプションのAPIとオプションのAPIパーツをサポートしています。さらに、これらの実装にはそれぞれ独自のバグもあります（デバイスの特性/特徴の細分化の例については、下記の補足説明を参照）。
そのため、典型的な開発サイクルでは、移植とテストにかかる時間が全体の40～80パーセントに上ることになります（実際にどれくらいの比率になるかは、開発者の経験レベルとサポートするデバイスの数によります）。
移植したモバイルアプリケーションを実際の携帯電話でテストするのは必ずしも簡単なことではありません。よくできたエミュレータを使用すれば、実際のデバイスのバグがすべて再現されるはずですが、常にエミュレータがあるとは限りませんし、たとえあっても決して当てにできるわけではありません。
バグにはもう1つ難しい問題があります。バグに対処するには、バグをソースコード上で解決するか、不具合のある機能を無効化しなければなりませんが、このような対策がファームウェアのバージョンによってすべて異なるものになる可能性があります。特に厄介なのは、仮想マシンにバグがある場合です。これは、メーカーが仮想マシンをハードウェアレベルでハンドセットに統合する際に問題になります。
モバイルオペレータは配布されたミッドレットの品質をコントロールする必要があります。なぜなら、低品質のミッドレットはオペレータサービスに影響を与えるからです。オペレータは比較的うまくできている古いミッドレットを新しいデバイスモデルのために交換し、広範に使用できるようにする必要もあります。そのため、開発者はアプリケーションを新しいデバイスにすばやく移植できなければならないのです。
移植の自動化は必要か
一番のポイントは、そのアプリケーションでサポートできるデバイスの数です。これが、自動化という投資の効果を左右する最大の要因になります。移植を自動化することには次のような利点があります。
- J2MEプロトタイプが使用可能になり、市場化までの時間が短縮される。
- 単調で退屈な作業が自動化される。
- さまざまなデバイス仕様に煩わされずにアプリケーションロジックに専念できる。
- デバイスごとに最適化されたアプリケーションを生成できる。
まず、各デバイスモデルの特異性を考慮する必要があります。利用できる場合にはいつでもオプションの機能を使用すべきです。デバイスに応じてアプリケーションでサポートすべき機能の例を表1に示します。
| デバイスが次の条件に当てはまる場合は | アプリケーションで次のことを実現する |
| サウンドをサポートしている | サウンドを再生する |
| アルファブレンディングをサポートしている | 不透明度に変化をつけてメニューを表示する |
| .jarファイルサイズの制限がきつい | 必須でないイメージを削除する |
| 全画面をサポートしている | 全画面を使用する |
| 十分なヒープメモリがあり、大きな.jarファイルサイズをサポートしている | ビットマップフォントなどのオプションの機能を使用する |
| カメラコントロールをサポートしている | カメラで撮ったスナップショットを使ってゲームをカスタマイズできる |
| Bluetoothをサポートしている | SMSまたはHTTP接続を使用して他のユーザーと通信する（チャットなど） |
| SMSをサポートしている | SMSを使用して現在のアプリケーションをアクティブ化する |
| PDAPをサポートしている | PDAPを使用して内部ギャラリーのイメージにアクセスする |
| 電話をかけられる | 電話をかける |
| バックグラウンドでのアプリケーションの実行をサポートしている | バックグラウンドでアプリケーションを実行する |
