モバイルアプリケーションのデザイン上の考慮事項

アプリケーションが別のアプリケーションへのフォーカスを失うと、AIR は、フレームレートを 4 フレーム/秒に落とし、グラフィックのレンダリングを停止します。このフレームレートを下回ると、ネットワークのストリーミングおよびソケット接続は中断しやすくなります。アプリケーションでこのような接続を使用しない場合は、フレームレートをさらに低くすることができます。

適切な場合は、オーディオの再生を停止し、そのジオロケーションおよび加速度センサーのリスナーを削除します。AIR NativeApplication オブジェクトは、アクティブ化イベントおよび非アクティブ化イベントを送出します。これらのイベント使用して、アクティブ状態とバックグラウンド状態間の移行を管理します。

多くのモバイルオペレーティングシステムは、警告せずにバックグラウンドアプリケーションを停止します。アプリケーションの状態を頻繁に保存することで、アプリケーションがバックグラウンド状態からアクティブ状態に戻るとき、または新たに起動するときに、適切な状態に復元できます。

モバイルデバイスの画面をデスクトップの画面と比較すると、物理的なサイズは小さくても、ピクセル密度（ppi）は高くなります。モバイルデバイス画面上では、同じフォントサイズの文字が、デスクトップコンピューター画面上よりも小さく表示されます。読みやすくするために、大きいフォントの使用が必要となる場合も少なくありません。一般的に、14 ポイントが、読み取りやすい最小のフォントサイズです。

モバイルデバイスは、多くの場合、移動中や、照明条件が悪い中で使用されます。画面上でどれだけ多くの情報を現実的に読みやすく表示できるかを検討します。モバイルデバイスに表示できる情報量は、デスクトップで同じピクセルサイズの画面に表示するよりも少なくなる場合があります。

ユーザーが画面にタッチするときに、指や手によって画面の一部が隠れてしまうことも考慮します。瞬間的なタッチではなく、ユーザーが一定時間触って操作するインタラクティブなエレメントは、画面の横および下部に配置します。

多くのデバイスでは、テキスト入力に仮想キーボードを使用します。仮想キーボードは画面の一部を占め、しばしば邪魔になります。ソフトキー以外では、キーボードイベントの使用を避けてください。

入力テキストフィールドの代わりとなる機能を実装することを検討してください。例えば、ユーザー入力が数値の場合、テキストフィールドは必要ありません。値を増減する 2 つのボタンを代わりに使うことができます。

モバイルデバイスには多数のソフトキーが用意されています。ソフトキーは、様々な機能をプログラム可能なボタンです。アプリケーションにおけるこれらのキーの設定については、プラットフォームの規則に従ってください。

モバイルコンテンツは、縦長モードまたは横長モードで表示できます。アプリケーションが画面の向きの変更にどのように対応するかを検討します。詳しくは、「 ステージの方向 」を参照してください。

AIR は、ビデオの再生中に画面が暗転するのを自動的には回避しません。AIR NativeApplication オブジェクトの systemIdleMode プロパティを使用して、デバイスが省電力モードに入るかどうかを制御できます（プラットフォームによっては、この機能を動作させるために、適切な権限を要求することが必要になります）。

AIR ランタイムは、電話の発着時にオーディオを自動的にミュートします。Android では、バックグラウンドで実行中のアプリケーションがオーディオを再生する場合、アプリケーション記述子で Android の READ_PHONE_STATE 権限を設定してください。この設定を行わないと、Android のランタイムは電話の受信を検出してオーディオを自動的にミュートすることができなくなります。 Android 権限 を参照してください。

ユーザーがタップするボタンや他のユーザーインターフェイスをデザインする際には、ヒットターゲットのサイズを検討します。タッチスクリーン上で指で簡単に起動できるように、十分な大きさにする必要があります。また、ターゲット間に十分なスペースも確保します。ヒットターゲット領域は、一般的な高 dpi の電話画面の場合、両側に約 44 ～ 57 ピクセルで設定します。

モバイルデバイスでは、通常、アプリケーションとデータのインストール用の記憶領域の容量は、デスクトップコンピューターよりも大幅に少なくなります。使用しないアセットおよびライブラリを削除して、パッケージサイズを最小化します。

Android では、アプリケーションのインストール時に、アプリケーションパッケージは個別のファイルに抽出されません。その代わり、アクセスされたときに、アセットは一時的な記憶領域に解凍されます。解凍されたアセットが使用する記憶領域を最小化するため、アセットが完全にロードされたら、ファイルと URL ストリームを完全に閉じます。

モバイルオペレーティングシステムに応じて異なるファイルシステムの制約が設けられており、これらの制約はデスクトップオペレーティングシステムによる制約とは異なる場合があります。このため、ファイルとデータの適切な保存場所はプラットフォームによって異なります。

AIR File クラスによって提供される共通ディレクトリへのショートカットが常に利用できるとは限りません。これは、様々なファイルシステムが存在するからです。次の表に、Android および iOS で使用できるショートカットを示します。

iOS アプリケーションに対する Apple のガイドラインでは、様々な状況でファイルに使用すべき記憶域の場所について、具体的なルールが定められています。例えば、あるガイドラインには、ユーザーが入力したデータや、それ以外の再生成や再ダウンロードが不可能なデータを含むファイルのみを、リモートバックアップ用に指定したディレクトリに格納すべきであると記述されています。ファイルのバックアップとキャッシュに関する Apple のガイドラインに従う方法について詳しくは、「 ファイルのバックアップとキャッシュの制御 」を参照してください。

Adobe は Flex フレームワークのモバイル最適化バージョンを開発しました。詳しくは、「 Flex および Flash Builder を使用したモバイルアプリケーションの開発 」を参照してください。

モバイルアプリケーション用のコミュニティコンポーネントプロジェクトも使用できます。これには、以下が含まれます。

• Josh Tynjala 氏の Starling 向けの Feathers UI コントロール

• Derrick Grigg 氏の スキン機能のある Minimal Comps

• Todd Anderson 氏の as3flobile コンポーネント

AIR 3.2 以降のモバイル用 AIR では、Stage 3D によって高速化されるグラフィックレンダリングがサポートされます。 Stage3D の ActionScript API は、低レベルの GPU アクセラレーション API のセットであり、これによって 2D および 3D の高度な機能が実現されます。この低レベルの API により、開発者は GPU のハードウェアアクセラレーションを柔軟に利用でき、パフォーマンスを大きく向上させることができます。また、Stage3D ActionScript API をサポートするゲーム用エンジンを使用することもできます。

詳しくは、 Gaming engines, 3D, and Stage 3D を参照してください。

パフォーマンス向上のために、AIR ではビデオのスムージングが無効になります。

多くのモバイルプラットフォームで、現時点での標準 AIR API ではアクセスできない機能が用意されています。AIR 3 以降では、独自のネイティブコードライブラリを使用して AIR を拡張できます。そのようなネイティブ拡張ライブラリでは、オペレーティングシステムから利用できる機能や、特定のデバイスに固有の機能にもアクセスできます。ネイティブ拡張は、iOS では C 言語で、Android では Java か C 言語で記述できます。ネイティブ拡張の開発については、「 Adobe AIR 用ネイティブ拡張の概要 」を参照してください。