当初、Adobe AIRはデスクトップアプリケーションのプラットフォームとして考えられていました。 ただし、現在では、モバイルデバイス、デスクトップコンピューター、ホームデジタルデバイス用のスタンドアロンアプリケーションの開発をサポートしています。 このように広範囲にカバーされているため、魅力的な開発プラットフォームとなっています。 同時に、各環境には固有の特異性があり、それを考慮する必要があります。
たとえば、ほとんどの場合、モバイルアプリケーションは短時間で起動されます。 このようなアプリケーションのユーザーインターフェイスは、小さな画面での使用に便利で、タブレットで適切に表示されるようにスケーリングされ、さまざまなデバイスの向きをサポートする必要があります。 タッチスクリーンで動作し、特定のクラスのデバイスに固有のソフトウェアおよびハードウェア機能を使用する必要があります。 さらに、メモリとグラフィックスの要件を考慮する必要があります。
この記事では、iOS、Android、Blackbery Tablet OSを実行しているスマートフォンとタブレットのアプリケーション開発者にAIRが提供する機能について説明します。
スクリーン
おそらく、最初の最も明白な考慮事項は、モバイルデバイスの画面です。 物理的寸法と表示ピクセル数の両方の点で比較的小さく、高密度（1インチあたりのピクセル数）が特徴です。 デバイスごとに、ピクセル密度と物理サイズの組み合わせが異なります。 さらに、デバイス自体を縦向きと横向きの両方で保持できます。
このさまざまなサイズと密度のすべてを処理するために、AIRは次の主要なAPIを提供します。
-
Stage.stageWidth, Stage.stageHeight
：これらの2つのプロパティには、画面の実際のサイズが格納されます。 さらに、たとえば、アプリケーションがフルスクリーンモードを開始または終了したときや、デバイスの向きが変わったとき（向きが少し下になったとき）、実行中に値が変わる場合があります -
Capabilities.screenDPI
：このプロパティは、インチあたりのピクセル数を保持します。
これらの値を使用して、アプリケーションは異なる特性を持つ画面に適応できます。
注：以前にAIRでデスクトップアプリケーションを開発したことがある場合は、モバイルプラットフォーム用に開発する場合、Stageが使用され、NativeWindowは使用されないことに注意してください。 つまり もちろん、リンクをインスタンス化できますが、これは効果がありません。 この機能は、モバイルデバイスとデスクトップの両方で機能するコードを作成できるように残されています。 NativeWindowが使用可能かどうかを確認するには、NativeWindow.isSuppotedを使用します。
モバイルアプリケーションは画面の回転をサポートする必要はありませんが、すべてのモバイルデバイスがデフォルトで縦向き（幅よりも大きい）を使用するわけではないことに注意してください。 画面を自動的に回転させる機能に関心のないアプリケーションは、アプリケーション記述子でflaseに設定することにより、画面を拒否できます。 逆に、trueに設定し、Stageから
StageOrientationEvents
イベントをリッスンできます。
タッチ入力
アプリケーションが画面に描画された瞬間から、通常はユーザー入力を受け入れる準備が整います。 モバイルアプリケーションの場合、これはタッチスクリーンからの入力を意味します。
AIRは、タップイベントを1本の指でクリックするなど、マウスイベントを単純な1本指のジェスチャーに自動的に一致させます。 これにより、モバイルデバイスでもデスクトップコンピューターと同じように機能するコードを追加の変更なしで作成できます。
より複雑なマルチタッチ操作のために、AIRには次のAPIが含まれています。
-
Multitouch
：使用可能なタッチ操作の種類に関する情報を提供します -
TouchEvent
：タッチ処理中にアプリケーションが受け取るイベント -
GestureEvent, PressAndTapGestureEvent, TransformGestureEvent
：アプリケーションは、ジェスチャーを処理するときにこれらのイベントを受け取ります
標準のシステムジェスチャ（ピンチやピンチスケーリングなど）で動作するアプリケーションの場合、
Multitouch.inputMode
を
MultitouchInputMode.GESTURE
に設定します。 シングルタッチは、システムによって自動的に適切なジェスチャーに変換されます。 たとえば、減少/増加のジェスチャーの場合、TransformGestureEvent.GESTURE_ZOOMタイプの
TransformGestureEvent.GESTURE_ZOOM
イベントが発生します。
アプリケーションが
Multitouch.inputMode
に関する「生の」情報を受け取りたい場合は、
Multitouch.inputMode
を
MultitouchInputMode.TOUCH_POINT
に設定します。 システムは、タッチ、移動、および終了を開始する一連のイベントを生成し、画面のタッチは複数のポイントで同時に発生します。 このような複数のタッチを解釈するタスクは、アプリケーションにあります。
テキスト入力
ソフトウェアキーボード（つまり、物理キーなしで画面に表示）を備えたモバイルデバイスには、特別な注意が必要です。 そのようなキーボードはどこにでもあるわけではありませんが、それを使用するデバイスが普及し始めているため、すべてが正常に機能することを確認する必要があります。
表示されると、ソフトキーボードは画面の一部を覆います。 これを考慮するために、AIRはステージをシフトして、入力フィールドとキーボードの両方が同時に表示されるようにし、アプリケーションの上部を画面外に隠します。 この動作を無効にして、独自の動作を実装できます。 これを行うには、アプリケーション記述子のsoftKeyboardBehaviorパラメーターをnoneに設定します（デフォルト値はpanです）。
Stage.softKeyboardRectフィールドには、ソフトキーボードが占める領域のサイズが格納されます。 SoftKeyboardEventイベントをリッスンして、この値がいつ変更されるかを確認してください。
原則として、アプリケーションはソフトウェアキーボードを開くことを心配する必要はありません;これは、テキストフィールドがフォーカスを受け取ったときに自動的に発生します。 ただし、フォーカスを受け取ったときにInteractiveObjectに対してキーボードを自動的に開くように要求する（InteractiveObject.needsSoftKeyboardプロパティ）か、InteractiveObject.requestSoftKeyboard（）を呼び出してキーボードを開くことができます。 これらのAPIは、ソフトキーボードをサポートしていないデバイスには影響しません。
センサー
モバイルデバイスとのユーザーインタラクションは、単一のマルチタッチスクリーンに限定されません。 アプリケーションは、ユーザーの位置に関する情報を使用できるだけでなく、空間内のデバイスの向きと動きに応答できます。 AIRは、次の主要なAPIを通じて、説明されている機能をサポートしています。
- ジオロケーション：デバイスの地理的位置（緯度と経度）、およびその動き（方向と速度）に関連するイベントを処理します
- 加速度計：x、y、z軸に沿ってデバイスに加えられた力を報告するイベントを処理します
一部のアプリケーションでは、ジオロケーションの可能性は不可欠な部分です（例は、最も近いATMのロケーションを決定するアプリケーションです）。 他のアプリケーションでは、利便性のためにジオロケーションを使用できます（例は、記録されている場所に関する情報を備えた音声メモです）。
前述のように、加速度計は、単に論理的な向きではなく、空間内のデバイスの実際の位置を知りたいときに役立ちます。 加速度計を使用すると、デバイスを単独でジョイスティックのような入力ツールに変えることができます。 多くのアプリケーションがこの機能を使用しています。
記載されている両方のAPIにより、センサーのポーリングの間隔を設定できます。 関連する情報が関連するリスナーに送信される頻度。 ただし、設定周波数は保証されておらず、たとえばデバイスのハードウェア特性などのさまざまな要因に依存する可能性があることを明確にする必要があります。
Webコンテンツの表示
最新のランタイムには、HTMLコンテンツのサポートが含まれている必要があります。 AIRには、このためのStageWebView APIがあります。 StageWebViewにより、AIRアプリケーションはデバイスの組み込みHTMLレンダリング機能にアクセスできます。 StageWebViewはプラットフォーム自体のHTMLエンジンを使用するため、異なるプラットフォームで同じ表示が保証されないことに注意してください。
ネイティブツールを使用する別の結果は、StageWebViewコンテンツがアプリケーションの表示リストに統合されないことです。 ただし、このコンテンツはdrawViewPortToBitmapData（）メソッドを使用してラスターイメージとして保存し、表示リストに配置できます。 これは、たとえば、ページのスクリーンショットを撮ったり、スムーズな切り替え効果を作成したりするために使用できます。
AIRのHTMLLoader APIに精通している人にとって、StageWebViewはそれに代わるものではないことに注意する価値があります。 HTMLLoaderにはHTMLサポートが組み込まれており、ブラウザーサンドボックスの外部で実行されるHTMLおよびJavaScriptを配置できます。 StageWebViewは、従来のブラウザサンドボックス内のHTMLおよびJavaSctiptコンテンツで動作します。
ユーザーをアプリケーションからブラウザーまたはYouTubeやGoogleマップなどのアプリケーションに送信する場合は、navigateToURL（）を使用します。
画像
写真を撮るということになると、質問は「デバイスは写真を撮る方法を知っていますか」ですが、別の質問があります：「このデバイスにはいくつのカメラがありますか？」。 モバイルデバイス用のAIRには、カメラで直接操作することも、すでに撮影した写真で操作することもできるAPIが含まれています。
CameraUIおよびCameraRollクラス
組み込みカメラの機能は、CameraUIクラスを介して利用できます。 名前が示すように、このクラスは、カメラのユーザーインターフェースではなく、カメラのユーザーインターフェースで直接動作するという点で、類似のCameraクラスとは異なります。 デバイスに応じて、これは写真とビデオの撮影の選択、写真の解像度の指定、フラッシュのオン/オフ、フロントカメラとリアカメラの切り替えなどのユーザーの能力で表現できます。
ただし、モバイルデバイスは写真を撮るだけでなく、写真も保存します。 ユーザーが作成した写真のライブラリは、CameraRollクラスから入手できます。 browseForImage（）メソッドを使用して、ライブラリから画像を選択するための標準ダイアログを開くことができます。 さらに、addBitmapData（）メソッドを使用して、この領域にデータを書き込むことができます。
クラスMediaPromise
CameraUIとCameraRollは、MediaEventイベントを使用してメディアコンテンツを返します。 関連する情報が利用できるMediaPromiseタイプのデータフィールドを除いて、異常ではありません。
名前が示すように、MediaPromiseはコンテンツを提供することを約束しますが、必ずしもコンテンツを保存するわけではありません。 これは重要なニュアンスなので、数分かけて理解する価値があります。
メディアファイルをメモリに配置するか、ストレージデバイスから直接操作するかは、いくつかの要因に依存します。 たとえば、ビデオは通常大きなサイズであり、ビデオ全体を入れることは実用的ではありません。 彼女はいつものようにあまりありません。 一方、撮影したばかりの写真は既にメモリ内にあり、ビデオほど大きくなく、メモリから直接操作できます。
MediaPromiseクラスは、単一のインターフェイスを介してメディアオブジェクトへのアクセスを提供することにより、このあいまいさを軽減するために設計されたラッパーです。 アプリケーションがストレージデバイスからオブジェクトを直接操作したい場合は、MediaPromise.fileを介してその存在を確認できます（nullでない必要があります）。
アプリケーションがメモリ内のメディアオブジェクトを処理する場合、MediaPromise.open（）を使用してアクセス可能なストリームを介して常に読み取ることができます。 MediaPromiseは、メモリにあるかストレージデバイスにあるかに関係なく、メディアオブジェクトのコンテンツを自動的に返します。 open（）を使用する場合、MediaPromise.isAsyncをチェックしてストリームのタイプを確認してください。
最後に、メディアファイルを表示リストに直接配置する必要があり、コードの不必要なコピーを回避する場合、LoaderクラスにはLoader.loadFilePromise（）メソッドがあります。 名前が示すように、FilePromiseで機能します（MediaPromiseはIFilePromiseインターフェイスを実装します）。
アプリケーションのライフサイクル
モバイルデバイスでは、アプリケーションはライフサイクルをほとんど制御できません。 それらは単独では起動できませんが、ユーザーの直接参加（たとえば、ホーム画面から、またはアプリケーションに関連付けられたURL経由）でのみ起動できます。 アプリケーションはいつでもバックグラウンドに送信してから完全に停止できます（これは通常、現在アクティブなアプリケーションに十分なリソースがない場合に発生します）。
一部のモバイルプラットフォームでは、NativeApplication.exit（）は適用されません（操作不能、「no-op」）。 終了時に状態を保持する代わりに、アプリケーションはバックグラウンドに入るとき、および/または特定の間隔で保存する必要があります。
アプリケーションは、スタンバイモードに入ってそこから戻るときに、それぞれDEACTIVATEイベントとACTIVATEイベントを受け取ります。 これに加えて、AIRはさらにいくつかの特定のアクションを実行します。詳細はプラットフォームによって異なります。
Androidのバックグラウンド動作
Androidでは、アプリケーションはバックグラウンドで可能な限り少ない作業しか受けない傾向がありますが、厳密な制限はありません。 AIRアプリケーションがバックグラウンドに移行すると、フレームレートは4 fpsに低下し、イベント処理は継続しますが、イベント処理サイクルのレンダリングフェーズは省略されます。
したがって、AndroidのAIRアプリケーションは、ファイルのダウンロード/ダウンロード、バックグラウンドでの情報の同期などのタスクを実行できます。 それでも、バックグラウンドモードに切り替える場合、アプリケーションは独立して追加の手順を実行して、フレームレートを下げたり、不要なタイマーを無効にしたりする必要があります。
IOSバックグラウンド動作
iOSでは、アプリに実際のマルチタスク機能はありません。 アプリケーションは、バックグラウンドで何らかのアクティビティを表示することを示す必要があります（たとえば、VoIPコールの保留やファイルのアップロードなど）。
AIRはこの作業モデルをサポートしていないため、アプリケーションがバックグラウンドに移行すると、一時停止します。 つまり、フレームレートは0 fpsに設定され、イベントは処理されず、レンダリングは発生しません。 それでも、アプリケーションの状態はメモリに保存され、バックグラウンドモードを終了すると復元されます。
性能
アプリケーションの良好なパフォーマンスを実現するには、そのすべての側面に慎重にアプローチする必要があります。
打ち上げ時間
起動時間を短縮するのは簡単なことではありません。 通常、起動はアプリケーションの多くの側面に影響します。 まず、実行速度を上げるのではなく、実行されるコードの量を減らすことに焦点を合わせます。
たとえば、ゲームを書いているときに、ローカルに保存されているスコアテーブルを最初の画面に表示したいとします。 このコードを実行すると、驚くほど高価になる可能性があります。 コードは初めて実行されるため、その解釈/コンパイルに関連するオーバーヘッドが発生し、定常状態の通常のActionScriptコードよりも実行が少し遅くなります。 第二に、ファイルシステムから情報を読み取るコスト。 最後に、画面上の情報の配置と表示のコスト。
代わりに、最初の画面が表示された後にこのすべての作業を行うことを検討してください。 そして、ユーザーがあなたのアートのすべての利点を見るのに忙しい間、スコア表を準備してアニメーションを使用してそれを表示できます。
一般に、最適化のアプローチは次のとおりです。まず、高速最適化に苦労するのではなく、どのコードをいつ実行すべきかを慎重に検討します。 ユーザーが感じる主観的なパフォーマンスは重要です。ユーザーは、プロセスの完了を待たなければならない場合、遅延に気づきます。
レンダリング
グラフィックプロセッサ（GPU）の使用により、レンダリングを最適化するアプローチが変更されました。 CPUを使用してレンダリングする場合、大量のピクセルを使用するのは無駄であるため、オブジェクトの形状とその変換の数学的記述を使用するのは、その描画の後のみにすることをお勧めします。 これは、AIRがベクターコンテンツを操作するために使用する従来のアプローチです。
反対に、GPUはパイプライン処理を使用して、ピクセルの大きな配列で非常に迅速に動作できますが、ベクトル画像では事態はさらに悪化します。
AIRを使用すると、両方のアプローチを最大限に活用できます。 すべてのフラッシュ機能を使用してベクター画像を操作し、一連のラスター画像として結果をキャッシュして、画面に効果的に描画できます。 これらの目的には、BitmapData.draw（）を使用します。
また、オンザフライでベクター形式から受信する代わりに、事前に準備されたラスターイメージを使用することも可能です。 ただし、モバイルデバイスの画面のサイズと密度はさまざまであるため、これはそれほど効果的ではありません。
記憶
最新のモバイルデバイスには十分な量のRAMが搭載されていますが、従来のデスクトップオペレーティングシステムとは若干異なるメモリ管理モデルを使用していることを覚えておくことが重要です。 デスクトップでは、メモリが不足すると、一部のデータを一時的にディスクにアンロードしてからメモリに戻すことができます。 これにより、オペレーティングシステムは、ほぼ無制限の数のプログラムを同時に実行し続けることができます。
モバイルデバイスでは、このアプローチは一般に適用できません。 要求されたメモリサイズが現在使用可能なサイズを超えると、バックグラウンドアプリケーションが強制的に終了され、メモリが解放されます。 それでもメモリ割り当て要求を満たせない場合、要求元のアプリケーションはその作業を強制的に停止します。
これには、次の結果が伴います。 まず、アプリケーションが占有しているメモリについて明確に把握する必要があります。 第二に、実行を継続する機会を増やすために、アプリケーションはバックグラウンドで可能な限り少ないメモリを占有しようとする必要があります。
これらのタスクは両方とも、アプリケーションからの明示的なメモリ管理によって実現できます。 これらの目的のためにガベージコレクタがあるため、最初はこれは奇妙に思えるかもしれません。 ただし、ごみ箱をきれいにするだけのメカニズムと考える方が良いですが、ごみをこのバスケットに自分で送る必要があります。
明示的なメモリ管理に向けた最初のステップは、オブジェクトへの参照が不要になった場合は必ずそれをクリアすることです。 例は次のとおりです。XML構成ファイルを開始時に読み取るアプリケーションがあるとします。 設定が読み取られて適用された後、ツリーのルートへのリンクと、それに応じて不要になった関連XMLツリーへのリンクがメモリに保存されます。 この場合、ツリーのルートへのリンクにnull値を明示的に設定し、ガベージコレクターがメモリを解放できるようにする必要があります。
明示的なメモリ管理は、同じ種類のオブジェクトの多くを扱う場合にも重要です。 たとえば、イメージのセットをロードするアプリケーションは、正しく書き込まれていない場合、およびこのセットが十分に大きい場合、確実にメモリ不足になります。 逆に、メモリ内に同時に存在する画像の最大数をプログラムで同時に制限すると、メモリの問題を回避できます。 この例では、新しいイメージをロードする前に古いイメージを削除するか、メモリ内の一定数のイメージを周期的に上書きできます。
保管
モバイルデバイスは、アプリケーションが設定、ドキュメントなどを保存できるローカルファイルシステムへのアクセスを提供します。原則として、アプリケーションはデータのみが利用可能であるという事実に依存する必要があり、このデータを他のアプリケーションと共有する方法はありません。すべてのデバイスで、File.applicationStorageDirectoryプロパティを介してストレージにアクセスできます。
さらに、Addroidは、パス「/ sdcard」で利用可能なSDカードのファイルシステムを使用する追加の機会を提供します。主記憶装置とは異なり、デバイス上のすべてのアプリケーションの読み取りおよび書き込みに使用できます。ただし、SDカードはデバイスから取り外したり挿入したりすることはできますが、マウントすることはできません。
モバイルデバイス上のカメラの普及を考えると、写真用の特別な共通ストレージがあることを忘れないでください。 「画像」セクションで前述したCameraRoll APIからアクセスできます。また、一部のプラットフォームでは、写真へのアクセスをファイルシステムから直接取得できますが、これはアプリケーションの移植性に影響を与えるため、悪い習慣です。
展開
モバイルデバイスの世界では、アプリケーションは主に特別なストア（アプリマーケットプレイス）を介して配布されます。これらのストアには、アプリケーションの検索、インストール、および更新のためのデバイス上の特別な機能が含まれています。
特定のストアに配置するには、AIRアプリケーションを各プラットフォームに固有の特別な形式に変換する必要があります。たとえば、Apple App Storeでの配置の場合は.ipaファイルであり、Androidの場合はマーケットプレイスの.apkファイルです。これは、Flash Builderから直接行うことも、たとえばADTユーティリティを使用して行うこともできます。
すべてのモバイルアプリストアでは、アプリに署名する必要があります。 iOSの場合、証明書はAppleによって発行されます。 Androidデバイスの場合、開発者は自分で証明書を作成します、少なくとも25年間有効で、それによって各アプリケーションとその更新プログラムに署名する必要があります。したがって、異なるサイトでアプリケーションを公開する場合、いくつかの証明書を操作する必要があります。
Androidマーケットに配置するアプリケーションを準備する場合、AIRはそこに個別にインストールされることに注意してください（iOSでは、AIRのコピーが各アプリケーションに含まれています）。AIRがインストールされていないデバイスでアプリケーションを実行すると、ユーザーはリダイレクトされてインストールされます（ADTの-airDownloadURLフラグも参照してください）。
次は？
Adobe AIRを使用した開発により、Android、iOS、またはBlackBerry Tablet OSを実行するスマートフォンやタブレットなど、多くのモバイルデバイスに展開できる単一のモバイルアプリケーションを作成できます。
これは、クロスプラットフォームの抽象化を使用して（たとえば、写真にアクセスするとき）、デバイスの動的プロパティに関する情報（たとえば、画面サイズ）を提供することによって実現されます。同時に、AIRは、ヘルプが必要ない場合（たとえば、ファイルシステムAPIを使用する場合）に干渉しません。
クロスプラットフォームモバイルアプリケーションの開発では、プログラマがメモリの効率的な使用とアプリケーションのライフサイクルについて知る必要があります。この知識をAIRランタイムと組み合わせることにより、クロスプラットフォームアプリケーションをすばやく作成できます。
-
便利なリンク
ブログ
Flash + AIRでのモバイルゲーム開発
本
ハイパフォーマンスフラッシュ：Flash、Flex、AIR、およびモバイルアプリケーションのパフォーマンスチューニング、 E。Elrom、2012-Amazonでの先行予約
Adobe AIRによるAndroidアプリケーションの開発、V。Brossier、O'Reilly、2011
Adobe AIR、J。Lott 、2009- Adobe AIRに関する最初のロシア語の本
Adobe AIR Bible、B。Gorton、Wiley、2008年
フォーラム
AIRに関するAdobe Mobile Development Forum
記事
AIR 3の新機能
Flex / AIR for iOS開発プロセスの説明！
Flash CS5.5 + AIR 2.7を使用したiOSアプリの作成
その他
AIR Native Extentions（ANE）：さまざま
な 情報Adobe AIRのモバイル開発に役立つリンク集Adobe AIRの
公式ページ
Adobe AIR開発者センター
Adobeモバイルおよびデバイス開発者センター
Adobe AIRクックブック
TourDeFlex-フラッシュプラットフォームに関する情報のコレクション。モバイル開発を含む