プリプロセッサを使ってJ2MEアプリケーションの移植を自動化する

アプリケーションを様々な機種に効率よく対応させる方法

内製の移植ソリューション

　アプリケーションの移植を自動化することに決めたら、実際に何をすればよいのでしょうか。もちろん外注することもできますが、自社内でやるつもりなら、基本的に4つの方法の中から選ぶことになります。

1. デバイスシリーズごとにバージョンを1つずつ作成する
このアプローチは、単に一連のモデル（例えばNokia Serie40 Edition 1）ごとにアプリケーションを開発するというものです。この場合の問題点は、サポートするAPIが多いほど、あるいはアプリケーションでそのデバイスに力点を置くほど、シリーズを細分化することになります。というのも、高度なAPIに対するサポートによってシリーズ内のわずかな差異が際立つからです。例えば、同じような2つのデバイスでも、画面上のイメージの数によってパフォーマンスが大きく違ってきます。

2. ハンドセットの動的検出
このオプションでは、実行中にアプリケーションをテストします。例えば、モデルがNokiaハンドセットだとすると、アプリケーションは実行中にこのデバイスモデルを検出し、モデルに応じた適切な動作を選択します。
これで、特定のハンドセットでのみ使用可能なメソッド（全画面モードなど）を呼び出すことができます。それぞれの実装ごとにクラスを作成する必要があります（NokiaCanvas、SiemensCanvas、StandardCanvas）。次に例を示します。

try {
   Class.forName("com.nokia.mid.ui.FullCanvas");
   Class myClass = Class.forName("NokiaCanvas");
   myCanvas = (ICanvas)(myClass.newInstance());
} catch (Exception exception1) {
   try {
      Class.forName("com.siemens.mp.color_game.GameCanvas");
      Class myClass = Class.forName("SiemensCanvas");
      myCanvas = (ICanvas)(myClass.newInstance());
   } catch (Exception exception2) {
      myCanvas = (ICanvas) new StandardCanvas();
   }
}

基本的にインターフェイス（Icanvas）と3つの実装（Nokiaデバイス、Siemensデバイス、標準MIDPデバイスについて1つずつ）を作成します。
それからプロプラエタリAPIが利用可能かどうか確認するためにClass.forNameを使用します。例外がスローされなければ、NokiaCanvasを使用します。そうでなければ、現在のデバイスがこのAPIをサポートしていないことになります。その場合は、もう1つのAPI（例えばSiemens）をテストします。もう1つの例外がスローされた場合は、標準キャンバスを使用しなければなりません。
このソリューションではデバイスの各モデルの動作のロジックを各アプリケーションに組み込むことを想定しているので、すぐに無理がきます。

3. AOPや拡張Javaのような代替物を使用する
Allen Lauは最近のDevXの記事で、AOPによる細分化問題の解決方法を論じています。彼のアイデアは、アプリケーションロジックを一箇所にまとめ、コードを部分的に追加/削除することでアプリケーションのコードを修正するというものです。
このアプローチでは、いくつかの問題が解決されますが、アプリケーションの構造をそれぞれのプラットフォームに合わせて修正しなければならないので、結局のところ、もう1つの補足的なソリューションを使用するはめになるかもしれません。なぜなら、アプリケーションを各デバイスモデルに合わせて最適化するのは非常に難しい場合があるからです。オプションのAPIをサポートするときは特にそうです。
さらに、この方法では各デバイスモデルに合わせてコンテンツ（イメージやサウンドなど）を修正するという問題が解決されません。Java拡張機能を使用すればソースコードを自動的に変換できますが、これは興味深いアプローチであっても、実際には作業量が増えてしまいます。

4. プリプロセッサを使用する
プリプロセッサを使用すると、条件によってソースコードが自動的にアクティブまたは非アクティブになります。
例えば、Nokiaデバイスで全画面モードを設定するには、Canvasではなく、FullCanvasを拡張する必要があります。MIDP2デバイスでは、setFullScreenModeを呼び出す必要があります。MIDP1デバイスでは、これは可能でないので、非全画面モードのままです。

//#ifdef NOKIA
   extends com.nokia.mid.ui.FullCanvas
//#else
   extends Canvas
//#endif
   {
　：
　：
//#ifndef MIDP2
      setFullScreenMode(true);
//#endif

プリプロセッサによってこのソースコードが処理されるので、ディレクティブを設定します。従って、Nokiaデバイス用のアプリケーションを生成するには次のようにします。

//#define NOKIA

プリプロセッサは次のものを生成します。

extends com.nokia.mid.ui.FullCanvas
{

MIDP2デバイスの場合（//#define MIDP2）は、次のものを生成します。

extends Canvas
{
    setFullScreenMode(true);

このソリューションでは、ソースコードの1つの本体を各デバイスにモデルに合わせて修正できます。ディレクティブを含むリファレンスソースコードを開発するだけで済むのです。処理済みファイルに加えられたその他の変更は、次のプリプロセスですべて失われます。
このソリューションはプリプロセスという古い発想に頼っていますが、いろいろなデバイスモデルへの移植を試みるときに遭遇する問題をすべて解決できる、柔軟性の高い唯一の方法です。

プリプロセッサを使った移植に必要なこと

　ソースコードのバージョンを1つだけにするというのが基本原則です。これがプリプロセスされて、それぞれのデバイスモデルに適合したコードが生成されます。

　留意すべき点を以下に列挙します。

• それぞれのデバイスモデルの動作を熟知している必要があります。
• それぞれのデバイスモデルでサポートされているJava機能を知る必要があります。
• プリプロセスでどんな操作（デプロイメントなど）が扱われるか知る必要があります。
• プリプロセスではリソース（イメージやサウンドなど）は変換されません。
• 完全に自動化されたソリューションにする必要があります。パラメータ化したソリューションでは不十分です。
• 自動化されたコンパイルとパッケージングのプロセスの開発に力を注ぐ必要があります。

　イメージやサウンドなどのリソースを各デバイスモデルの能力に適合させるためには、変換ツールを使う必要があります。イメージの最適化も必要です（例えば、.pngイメージのヘッダーからオプションの情報を取り除いたり、小さなイメージを大きなイメージにまとめたり、各イメージの色の数を減らしたり、リソースをプリロードしたりします）。

　同じ特性や機能や動作を持つ一連のJavaデバイスを作成する必要があるかもしれません。そうすれば、各デバイスモデルに対してではなく、このシリーズに対して1つのアプリケーションを生成できます。このシリーズの機能は、アプリケーションの中で使用したい機能に本質的に依存することになります。使用するオプションの機能が多いほど、細分化の度合いが増大します。

　予期しないリソースを考慮に入れようとすると、アプリケーションの更新が必要になります。例えば、デバイスが大きな.jarファイルをサポートしていて、大きなヒープメモリを持っていれば、アプリケーションのバックグラウンドイメージを格納できます。そうでなければ、イメージは.jarファイルには入れられないので、単純に描画する必要があります。その場合、.jarサイズは小さくなり、ヒープメモリはあまり消費されません。

　モバイルプログラミングでは画面サイズが重要な問題となるので、あらゆる技法を（イメージの動的変換やパッケージング前の変換など）駆使して、イメージサイズを小さくするように努力してください。

　さらに、システムとのやりとりを管理することも大切です。例えば、着信の際にサウンドを中止し、ミッドレットを一時停止するといった具合です。