作成日

15 March 2005

Adobe AIRで一番に気に入ったことと言えば、デスクトップ向けのアプリケーションがいとも簡単に開発できてしまうことです。特に筆者のようなWebデベロッパー出身者の場合、単にAIRプロジェクトを作成し、Web開発同様のコードを記述、そしてビルドを作成するだけでデスクトップアプリケーションが開発できてしまいます。

ただし、筆者は経験を積むに連れ、AIRアプリケーションの開発にはコツがいることにも気付きました。デスクトップアプリケーションはブラウザーベースのアプリケーションとは異なるため、特にアプリケーションのデプロイ方法に関しては十分な配慮が必要になります。

幸運なことに、Adobe AIRランタイムおよびそのSDKにはデベロッパーを支援するためのツールが用意されており、この中にはアップデートAPIおよびアップデートフレームワークを介してアプリケーションをアップグレードする方法も含まれています。

Webアプリケーションとは異なり、デスクトップアプリケーションの場合は、後でユーザーシステムにどのような影響が及ぶかを考えず、単に新たなビルドを公開するというわけにはいきません。ビルドごとに新たな依存関係が発生するため、ソフトウェアの寿命を通じて常にこれらの「遺産」にも配慮する必要があります。この配慮を初期の段階から怠ると、様々な問題に遭遇する恐れがあります。つまり、「大いなる力には、大いなる責任が伴う」というのは当を得た表現ということになります。

この記事では、Adobe AIRアプリケーションのアップデートを開発・デプロイする際にありがちな問題点を紹介するとともに、これらの問題を解決するためのヒントやテクニックについて解説していきます。

メモ:ここでは読者の皆さんがAIRアプリケーションの開発・更新について、ある程度の基礎知識を有していることを前提に解説を進めていきます。アップデートフレームワークの使用法について詳しくは、HTML/Ajax用、Flash用またはFlex用の各クイックスタートに用意されている「Adobe AIRアップデートフレームワークの使用」を参照してください。また、Mihai Corlan氏の執筆記事「Adobe AIRアップデートフレームワークの使用」もあわせてご覧ください。

アップデートの計画

test AIRアプリケーションの開発を始める際、将来アップデートを行うかどうかを判断する必要はありません。これはAIRアプリケーションには標準でアップデートを行うための機能が装備されているからです。とはいうものの、ある時点で何らかのアップデートを行わなければならなくなるということを自覚し、一般公開に先立ってこの準備を整えておくのがデベロッパーに課された責任と言えるでしょう。

これが重要な一番の理由として挙げられるのがセキュリティーです。アプリケーションを開発する場合、必ずセキュリティーパッチを提供できるようにする必要があります。十分気を付けなかった場合、AIRアプリケーションはユーザーのファイルシステムに害を与えかねないからこそ、この点は特に注意が必要です。セキュリティーが侵されるような事態は、誰も望んでいません。

セキュリティー以外にも、バグや単なる入力ミス、法務情報の欠落といった誤り・問題が原因で、アップデートが直ちに必要となるようなケースは容易に想定できます。また、皆さんの作品がユーザーにどの程度受け入れられるかも、はじめからは分かりません。デモのつもりで開発した作品が大成功を収めることになるかもしれません。

つまり、ここでは「アップデートに対応できるように開発するかどうか」を考えるのではなく、「アップデートのプロセスをどのように管理するのか」を考えておくことが肝心です。アプリケーションのユーザーが読者のWebサイトを毎日訪れて、新たなビルドの有無を確認する。これは現実的に期待できることではありません。だからこそ、何らかの自動更新機能を用意しておくのが一般的に賢明と言えるでしょう。このためにAIR SDKアップデートAPIを使用することもできますが、最も簡単なのが最新のアップデートフレームワークを使用する方法です。

ただし、どのタイミングで最新ビルドの有無をチェックするか、あるいはアップグレードを強制するのかどうかといった、いくつかの判断は読者自身が下さなければなりません。また、各ビルドはアプリケーションのライフサイクルにおいて、あくまで1つのステップであるということを肝に銘じる必要があります。従って、可能な限り押しつけがましくならないように配慮することが推奨されます。

アプリケーションIDの重要性

既にご存知のとおり、AIRアプリケーションは、アプリケーションのデスクリプターXMLファイル内に用意されたアプリケーションIDを用いて、ランタイムとオペレーティングシステムによって識別されます。このIDには次のいくつかの役割があります。

  • 当該アプリケーションを「アプリケーションストレージディレクトリー」に関係づける。
  • 当該アプリケーションをその暗号化されたローカルストアーに関係づけるためにも用いられる。
  • アップデートの処理時には、どのアプリケーションを置き替えるかを判断するためにランタイムによって使用される。

これらはアプリケーションを全く別のアプリケーションとして認識させたい場合を除き、ビルドをパブリッシュした後に、アプリケーションIDを変更するべきではないことの、いくつかの理由に過ぎません。一部のまれなケースでは、全く別のアプリケーションとして扱い、ユーザーが個別のバージョンをそれぞれ同時にインストール・使用できるようにしたいこともあります。

しかし、大半のケースでは、最初のパブリックリリースを行う前にアプリケーションIDを選択し、その後は一切変更しないことが求められます。Adobe AIRの初期ベータ版の段階では、「com.mycompany.myapplication」といった逆順のDNS命名方法がグッドプラクティスとして推奨されていましたが、現時点ではアプリケーションIDとパブリッシャーIDの組み合わせでアプリケーションが識別されるため、この命名方法は不要になっています。

パブリックリリース後に、(法務上の問題が発生したり、単にマーケティング戦略的な理由で)ソフトウェアの商標名を変更しなければならなくなったとしても心配無用です。アプリケーションIDは、システム上での実行時およびインストール処理中に表示される名称とは一切関係がありません。ユーザーがこのIDを目の当たりにする必要は一切ありません。

アプリケーションIDは、アプリケーションを識別するための唯一の条件ではないことも、頭に入れておく必要があります。仮に同じIDの2つのアプリケーションがあり、これらが別々の署名を用いて開発されていたとします。この場合、適切な署名の移行手続きを済ませていない限り、2つのアプリケーションはセキュリティー確保の理由から、別々のものとして認識されます。

ファイル依存の扱い方

AIRアプリケーションの場合、ユーザーシステム上のファイルまたはディレクトリーを使用したり、これらを作成したりすることがある点に注意するのが肝心です。使用または作成されるファイルとしては、以下が含まれます。

  • ユーザー初期設定ファイル
  • SQLiteデータベース
  • アプリケーション固有のファイルタイプ

この点はAIRの重要な特徴と言えるでしょう。ただし、これらのファイルは依存関係を作りかねない点に注意が必要です。場合によっては、特定のタスクを実行・処理するためにアプリケーションが一定のファイルを必要とするようなことがあります。

このような理由からも、各依存ファイルのパス、役割、ユーザーシステム上の配置場所、依存関係の具体的な詳細の記録を残すために、依存ファイルの説明の一覧表を作成しておくことが賢明です。また、これらのファイルに関しては、将来のビルドが発生した際に上書きを許可するのか、あるいは上書きを強制するのかどうかを判断する必要があります。例えば、ユーザー初期設定であれば、ビルドごとに上書きしないことが推奨されます。

可能であれば、バージョン情報をファイルに含めるようにします。この情報は、将来アップデートビルドを開発する際にとても重宝します。

アプリケーション側では、依存ファイルが存在しない事態にも対処できるようにする必要があります。依存ファイルがアプリケーションに不可欠な場合は、これらのファイルを(再)生成するための何らかの仕組み、または最低でも、適切なエラーメッセージを発し、明示的な形で処理の失敗を通知する仕組みが用意されるべきです。ここで注意しなければならないのは、インストール手続き時には、ユーザーシステムのどの位置に埋め込みファイルを配置するかについて、読者は選択できないことです。.airパッケージに埋め込まれたファイルはすべて、アプリケーションディレクトリーに配置されます。最終的な位置へのコピー処理は、アプリケーションに課される責任です(これらのファイルの大半は、アプリケーションストレージディレクトリーに配置することが推奨されますが、他の位置を作成することを選択することも可能です)。

依存ファイル自体、時間の経過とともに変化することが想定されます。例えば、ユーザーが他のソフトウェアを使用してこれらのファイルを編集しないとは限りません。だからこそ、依存ファイルに不具合が発生する事態に備え、何らかの修正・再生成メカニズムを用意しておくことが重要になります。

このような理由から、プログラムの起動シーケンスにおいては、当該プログラムが必要とする依存ファイルのチェックを行うようにすることが賢明です。また、所定のファイルが見つからない場合はファイルを生成し、古くなったものは上書きしたりするのも肝心です。また、この段階においては、古くなったファイルを削除しなければならないような場面があるかもしれませんが、ファイルを削除する操作はあくまで最終手段としてのみ利用するようにしてください。しかも十分な注意を払うようにする必要があります。

場合によっては、より複雑な特別のファイル移行メカニズムを用意しなければならないことがあります。例えば、データベースのテーブル構造が変更された場合は、従来のデータベース構造の既存データをすべて新しいものに変換しなければならないことがあります。

スタートアップのこの段階では、当該システム上でアプリケーションが初めて実行されるのかどうか、あるいは最も最近にインストールされたバージョンが何であるかを、チェックしなければならないことがあります。これらの情報の保管場所としては、暗号化されたローカルストアーが最適です。これはビルドを問わず、常に一貫しているからです。ただし、これらのアイテムは、trueに設定されたEncryptedLocalStore.setItem()メソッドのstronglyBoundパラメーターとともに保管されないように注意する必要があります。これは、このようなケースにおいて、当該データがアプリケーションの更新後に読み取れなくなるからです。

開発用ビルドとリリースビルドの違い

AIRアプリケーションの作成時に注意しなければならないのは、ADLで実行される開発用ビルドとは異なり、AIRの各リリースビルドは個別のアプリケーションとして扱われることです。これには、次に挙げる2つの重要な影響が及びます。

  • アプリケーションストレージディレクトリーが異なる。開発用ビルドの場合、このディレクトリーにはアプリケーションIDに基づいて名前が付けられます。一方のリリースビルドでは、ディレクトリーの命名方法がやや異なり、アプリケーションIDの後に一見ランダムな数値が付けられます。
  • 暗号化されたローカルストアーも、完全に別のものになります。

アプリケーションストレージディレクトリーおよび暗号化されたローカルストアーは、緊密にバインドされたパラメーターとともに保存されたアイテムを除き、アップデート後もそのままである点に注意が必要です。つまり、これらはアプリケーションファイルではなく、アプリケーションIDに関連付けられます。

なお、暗号化されたローカルストアーは、それに関連付けられたアプリケーションが明示的に指示するようなことがない限り、一切空にすることができません。たとえ当該アプリケーションを完全にアンインストールしたとしても、暗号化されたローカルストアーはそのまま維持されます。これはある意味期待される動作であり、デベロッパーが「当該コンピューターにアプリケーションがインストールされたことがあるか。ある場合は、いつ、どのバージョンがインストールされたか」といった情報を保存できるようにします。この仕組みは、例えばライセンシングモデルを管理する際などにおいて有用です。

暗号化されたローカルストアーをリセットすることはできませんが、開発中のアプリケーションに暗号化されたローカルストアーのエントリーをすべてクリアーするための内部機構を用意しておくことは可能です。なお、この操作には危険が伴うことに注意が必要です。コードを記述する際、暗号化されたローカルストアーが全く空であったり、予期したデータが存在しないようなケースも想定しておくことが賢明です。

開発用ビルドとリリースビルドのもう1つの主な違いは、後者がAIRファイルにパッケージ化される点です。開発用ビルドは、bin-debugディレクトリー(Flex Builderを使用している場合、その他の場合はデフォルトの出力フォルダー)のコンテキスト下においてADLによって実行されますが、最終版のアプリケーションは、その結果として発生するアプリケーションディレクトリー内で実行されます。

リリースビルドを作成する際、.airパッケージのコンテンツを確認するのは読者、つまりデベロッパーの役割です。

アプリケーションのパッケージ化と署名付与

コマンドラインから直接ADTを操作している場合、あるいはFlex BuilderなどのIDEを介している場合のいずれでも、パッケージ化と署名付与の作業は単一の手順で行うこともできれば、いったんアプリケーションをパッケージ化した後に後日署名するという手順でも対応することができます。

もちろん、アプリケーションの実行時に必要なファイルを埋め込むことも、忘れずに注意が必要です。パッケージの内容としてADTが必要とするのは、アプリケーションのSWFまたはHTMLファイルとデスクリプターXMLファイルの2ファイルのみです。当該アプリケーションが依存する他のファイルの存在の有無については、一切検知することができません。繰り返しますが、最終パッケージにすべてのファイルが含まれているかどうかは、デベロッパー自らが責任を持って確認するようにしてください。

また、一部のファイルは特定のリリースビルド専用であることにも注意が必要です。例えば、様々なネイティブアプリケーションおよびファイル関連付け用のアイコンがこの典型例として挙げられます。

メモ:読者がFlex Builderを利用してアプリケーションをパッケージ化している場合、通常はリリースビルドの書き出しウィザードパネルが用いられていることと思います。一見したところ、リリースビルドの.airパッケージコンテンツは、bin-releaseディレクトリーから作成されると思われることでしょうが、リリースビルドの書き出しウィザードではこのbin-releaseディレクトリーのどのファイルおよびディレクトリーを含めるかが選択できるようになっているため、これは完全に事実というわけではありません。

現行バージョンのFlex Builderでは、このウィザードパネルから外部のファイルやディレクトリーが参照できないことが既知の制約として認識されています。これらを埋め込むためには、外部ファイルをソースまたはbinディレクトリーにコピー&ペーストする必要があります。

また、プロジェクトのソースディレクトリーにある一部のファイルは、ウィザードでは見つけることができないため、そのままではAIRパッケージに埋め込む対象として選択できない点にも注意が必要です。この問題はActionScriptファイルとMXMLファイルに影響します。繰り返しますが、これらのファイルはbin-releaseディレクトリーに手動で含める必要があります。

これらのケースでは、自動化されたビルドシステムを使用しない限り、以下の手順でアプリケーションのビルドを作成します。

  1. アプリケーションのビルドを作成し、bin-releaseディレクトリーが生成された時点で停止します。
  2. このディレクトリーの中に、srcディレクトリーから自動的に含められなかった、.airパッケージに埋め込みたいファイルまたはディレクトリーをすべて配置します。
  3. 再度ビルド処理を行い、ウィザードを利用して、先ほどコピーしたファイルを埋め込みます。

コードに署名を付与することは、ソフトウェアのパッケージ化に伴う重要なステップです。特に、次の2点について、十分な注意が必要です。

まず、セキュリティーの理由から、証明書にはタイムスタンプと有効期限が設けられている点に注意が必要です。仮に証明書の有効期限が切れると、それ以降、その証明書を使って新規パッケージに署名を付与することはできません。ただし、以前に署名を済ませたパッケージは、そのまま有効に維持されます。

次に、1つの証明書から別の証明書に移行するような場合(開発期間中に新たな証明書を購入した場合など)は、忘れずに移行手続きを行うよう、注意する必要があります。この手続きを追うことで、エンドユーザーが読者の用意した自己署名型のアプリケーションから、最新の信頼済みビルドへとシームレスにアップグレードできるようになります。

メモ:AIRアプリケーションの署名方法について詳しくは、Oliver Goldman氏の記事「Adobe AIRのコード署名」およびTodd Prekaski氏の記事「Adobe AIRアプリケーションへのデジタル署名の付与」を参照してください。

新たなビルドの動作検証

次は、アプリケーションが期待通りに機能するかの確認です。この手順は機能テストとも呼ばれます。動作検証を行うにあたり、一番の問題は所定の要件を満たす動作検証環境を用意することにあります。たとえデベロッパーのシステム上で正しく機能したとしても、ユーザーのシステム上では必ずしも正常に機能しないかもしれないという前提で、物事を進める必要があります。

理想的には、動作検証をMac OS X、LinuxおよびWindowsで行うべきです。AIRはクロスプラットフォームランタイムではあるものの、一部の機能は個々のOS特有の動作になることがあります(これについて詳しくは、Charles Wardの記事「クロスプラットフォームAdobe AIRアプリケーションの開発」を参照してください)。また、アプリケーションがローカライズされている場合は、言語ごとに動作検証を行う必要もあります。なお、インストールダイアログボックスなど、AIRランタイムのダイアログボックスは、アプリケーションのデスクリプターファイルを使ってもローカライズできる点に注意してください。

ターゲットユーザーの想定としては、以前のバージョンからアップグレードする既存ユーザーと、当該アプリケーションを初めてインストールする新規ユーザーの2種類のユーザー層を考慮する必要があります。

ここではテスト環境に、既に当該アプリケーションの以前のリリースビルドがインストールされていたと想定します。この場合、現時点では読者のオンラインインストールバッジが更新されていないはずなので、.airパッケージから直接アプリケーションをアップデートするようにします。これにより(手動の)更新が正しく行えることを確認できます。

自動更新を検証するための簡単な方法はありません。これはアップデーターXMLファイルと.airパッケージが、ネットワークを介してすべてのユーザーによって共有されているからです。デバッグアップデーターファイルをどこかに配置することも可能ですが、この場合はおそらくデバッグアップデーターファイルを読み込むための特殊な「デバッグリリースビルド」を開発しなければならなくなります。(もちろん、テスト期間中だけオンラインファイルを別のものに置き替え、終了時に元のものに戻すことは可能ですが、これではややプロ意識に欠けることになってしまいます。)

次に、アプリケーションを初めてインストールするユーザーでも、当該ソフトウェアが確実にインストールできることを確認します。このためには、専用のシステムイメージを使用するのがベストです。アップデートの仕組みを検証した動作環境と同じものを使用する場合は、次の手順に従います。

  1. 現在のアプリケーションをアンインストールします。通常、筆者は自らのインストールバッジからアクセスし、AIRランタイムアプリケーションインストールダイアログを用いてこの操作を行っています。
  2. アプリケーションストレージディレクトリーと、当該アプリケーションが作成したすべてのファイルを削除します。このような操作が発生するからこそ、アプリケーションのファイル依存関係を記録しておくことが肝心です。
  3. 新たなビルドをインストールします。

この段階で、開発ビルド時には発生しなかった問題やクラッシュが起こる場合は、ファイルの依存関係が適切に管理されていないことが原因になっている恐れがあります。

アプリケーションのパブリッシュ

アプリケーションをアップロードしたい欲求を抑えるのは容易ではないかもしれません。しかし、アプリケーションの動作検証が完了したら、次は最新ビルドに関する周囲の環境をアップデートする必要があります。

まず、Webサイトのコンテンツを最新バージョン向けに更新します。ただし、まだパブリッシュするのは避けてください。機能リスト、解説、ナレッジベース、既知の問題点等を整理して考えるようにします。

その後の典型的な手順は以下のとおりです。

  1. (おそらく以前のビルドを上書きしつつ、)新しい.airパッケージをサーバーにパブリッシュする。
  2. 最新のバージョン番号およびリリースノートと一致するように、アップデーターXMLファイルを編集する。
  3. インストールバッジが最新であることと、これが予期したとおりに機能することをチェックする。ページまたはWebサイトをメンテナンスモードにし、素早く動作検証を行えるようにする。
  4. アプリケーションのWebサイトエディトリアルコンテンツをパブリッシュする。

メモ:インストールバッジについて詳しくは、HTML/Ajax用、Flash用またはFlex用クイックスタートの「WebでのAIRアプリケーションの配布」、および「カスタムインストールバッジの基本」を参照してください。

また、最新リリースについては、ブログ記事や各種案内等を通じて、既存ユーザーや将来のユーザーにも告知するようにします。

パブリッシュにかかる時間を甘く考えると大変なことになります。過剰なストレスの原因にもなりかねません。パブリッシュ作業はアプリケーション開発の様々な段階と比べて、最も手間のかかる作業の1つと言えます。だからこそ、筆者はこの手続きを支援するために、ANTタスクなどの簡単な自動ビルドシステムを検討することを推奨します。最低でも、パブリッシュ時の手続きを書き留めるなどして、チェックリストを作成するのが賢明です。