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

モバイルデバイスの動作状況や物理的特性は、慎重なコーディングとデザインを必要とします。例えば、可能な限り高速で実行されるようにコードを簡素化することが欠かせません。コードの最適化には、当然限界があります。デバイスの制限内で動作するインテリジェントなデザインを採用することも、ビジュアル表示がレンダリングシステムの処理能力を上回らないようにするのに役立ちます。

コード

コードの実行を高速化することは常に有用ですが、それと同時に、多くのモバイルデバイスのように低速なプロセッサーでは、無駄のないコードにすることで、書き込みにかかる時間が減ることによるメリットが大きくなります。さらに、モバイルデバイスは、ほとんど常に電池で動作します。同じ結果を少ない操作で実現すれば、消費電力を節約できます。

デザイン

アプリケーションのユーザーエクスペリエンスをデザインする場合、小さい画面サイズ、タッチスクリーン操作モード、また、モバイルユーザー環境が常に変化することを考慮する必要があります。

コードとデザイン

アプリケーションがアニメーションを使用する場合、レンダリングを最適化することは非常に重要です。ただし、多くの場合、コードを最適化するだけでは不十分です。コードが効率的にレンダリングできるように、アプリケーションのビジュアル表示をデザインする必要があります。

重要な最適化テクニックについては、『Flash Platform のパフォーマンスの最適化』ガイドで説明しています。このガイドで説明しているテクニックは、すべての Flash コンテンツおよび AIR コンテンツに適用されますが、モバイルデバイス上で適切に動作するアプリケーションの開発に不可欠です。

アプリケーションのライフサイクル

アプリケーションが別のアプリケーションへのフォーカスを失うと、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 で使用できるショートカットを示します。

 

Android

iOS

File.applicationDirectory

(ネイティブパスではなく)URL 経由での読み取り専用

読み取り専用

File.applicationStorageDirectory

使用可

使用可

File.cacheDirectory

使用可

使用可

File.desktopDirectory

SD カードのルート

使用不可

File.documentsDirectory

SD カードのルート

使用可

File.userDirectory

SD カードのルート

使用不可

File.createTempDirectory()

使用可

使用可

File.createTempFile()

使用可

使用可

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

UI コンポーネント

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

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

Stage 3D によって高速化されるグラフィックレンダリング

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 用ネイティブ拡張の概要」を参照してください。