複数のモバイルデバイス向けの単一アプリケーションのビルド

Question

1 つのアプリケーション バイナリを複数のモバイル デバイス用にビルドすることは可能ですか ( 醸造 プラットフォーム)、条件付きコンパイルを含むビルド スクリプトを使用してデバイスごとに個別のビルドを作成するのではなく、

特に、単一の BREW アプリケーション ビルドを複数の画面解像度に使用することは可能ですか?

目標は単一の バイナリ 建てる。コードベースが 1 つだけの場合は、条件付きコンパイルとスマート ビルド スクリプトで十分です。

Answer 1

はい、可能です。前の職場ではこれができました。ただし、必要なものは難しいです。

1. 最小公倍数の BREW バージョン用にコンパイルします。バージョン 1.1 は、現在販売されているすべての携帯電話のベースです。
2. コードは複数の解像度を処理できる必要があります。私の経験では、画面の幅と高さを検出する方法はすべての携帯端末で正確です。
3. すべてのリソースをすべてのデバイスにロードする必要があります。これには、特定のデバイスの問題を回避するために独自のカスタム イメージ ローダーを作成する必要があります。サウンドについては、シンプルな MIDI タイプ 0 がすべてで機能することはわかっていますが、QCP も機能するはずです (私自身は経験がありません)。
4. ビットマップフォントを使用します。フォントに関するデバイスの問題が多すぎるため、システム フォントを使用する価値はありません。
5. コード構造を有限状態マシンとして設計します。これをどれだけ強調しても足りません。これを実行しても、多くの問題は決して現実化しないのです。
6. デバイスの問題ごとに回避策を用意します。ここが難しい部分です！それは可能ですが、このウサギの穴は信じられないほど深いです...

結局のところ、アプリケーションが複雑で高度であればあるほど、この方法に進む可能性は低くなります。一部のデバイス プロパティ (プラットフォーム ID など) は実行時に確実に検出できないため、複数のビルドが必要になります。

Answer 2

Javaground で使用される J2ME から Brew への変換を作成しました。複数の解像度の単一バイナリ コードを記述することはかなり可能です。デバイスのバグのデータベースがあり、プラットフォーム ID を介してデバイスを検出し、どのバグがタグ付けされているかを示す一連のフラグを生成できます。たとえば、すべてではないにしても、ほとんどの Motorola Brew 電話には、着信に応答するまでアプリケーションが中断されないというバグがあるため、TAPI を使用して着信を監視し、hideNotify イベントを生成します。 Java をエミュレートしますが、生成されるコードは純粋な C++ です)。実行時に Brew のバージョンをいくつかチェックし、Brew 3 ではなく Brew 2 の場合は特定の API を無効にします。

3D タイプのゲームは、ソフトウェアで拡大縮小するため、解像度を独立させるのが簡単です。

また、サウンドには IMEDIA と ISOUNDPLAYER という 2 つの別個の API があります。ISOUNDPLAYER は古い API で、すべてのデバイスでサポートされていますが、それほど多くの機能はありません (IMEDIA を使用した場合のみマルチチャンネル オーディオを実行できます)。IMEDIA オブジェクトを作成します。IMEDIA オブジェクトを取得できない場合は、フォールバックして ISOUNDPLAYER オブジェクトを作成します。

完全にユニバーサルなビルドの問題は、機能に大きな違いがあるため、いくつかのビルドを行う価値があることです。古いデバイスのヒープは 1MB 以下しかなく (画面サイズも小さい)、それでも多くの効果が得られます。 6MB 以上 (176x204 以上)。

Brew では (Java とは異なり) かなり一貫したキー値のセットを使用できますが、新しいデバイスの一部はタッチ スクリーン (ポインター入力を処理する必要がある) や回転スクリーンです。

また、ビッグ エンディアン モードを使用する古い Nokia 携帯電話もあります。これは、ファイルが通常の MOD ファイルと同じではないことを意味します (ファイルをデコードする非常に優れたアセンブリ言語プレフィックス ヘッダーを作成する場合を除く)。

Answer 3

別のアイデアとしては、たとえば画面の寸法に基づいてハンドセットを 2 ～ 4 つのカテゴリに分類し、それらに合わせてビルドを作成することも考えられます。これは、サポートしたいすべてのハンドセットをはるかに少ない複雑さでサポートできるため、はるかに高速なルートでもあります。

もう 1 つ確認すべき点は、起動する端末の BREW バージョンです。たとえば、ある端末に BREW 1.1 が搭載されており、それがターゲット市場の少数の端末によって所有されている場合、それをサポートするために取り組むのは意味がありません。