ベストプラクティス - SWF アプリケーションのオーサリングガイドライン

Animate アプリケーションを作成するのに最もよい方法は、作成するアプリケーションとそれに使用する技術によって異なります。

オンラインアプリケーションでは、ユーザーが Web サイトとやり取りすることによって、その Web サイトに影響を与えることができます。例えば、アプリケーションがユーザーから登録用のユーザー名やパスワードなどの情報を収集し、情報がフォーラムなどでサイトに追加され、あるいはユーザーがサイトの他の訪問者とチャットルームまたは対話型掲示板などでリアルタイムにやり取りするような場合があります。やり取りによっては、サーバーからの結果が SWF ファイルに反映されることもしばしばあります。上記の例は、ユーザーと、様々な種類のサーバーとのやり取りを扱うアプリケーションの例です。訪問者の情報やデータを使用しない Web サイトは、アプリケーションではありません（ポートフォリオ、マンガアニメーション、静止情報型サイトなど）。Animate アプリケーションでは、ユーザー、Web アプリケーションおよびサーバーの間のやり取りの手順が必要です。基本的な手順は次のとおりです。

アプリケーションを作成するときは、データの転送に使用するプロトコルを選択する必要があります。プロトコルは、データがいつ送信または受信されたか、転送時の形式、およびサーバーの応答の処理方法をアプリケーションに警告します。SWF ファイルにデータが受領されたら、操作してフォーマットする必要があります。プロトコルを使用すると、データが予期せぬフォーマットになる心配はありません。名前と値のペアを使用してデータを転送する場合は、データのフォーマット方法をチェックすることができます。データが正しくフォーマットされているかどうかチェックして、XML 形式のデータを受け取らないようにすることによって、データを予想し、作業するデータが SWF ファイルに認識されるようにします。

データの収集とフォーマット

アプリケーションは、ユーザーによる SWF ファイルの操作に依存しています。ユーザーによるフォームへの入力に依存することもしばしばです。Animate では、Animate アプリケーションにデータを入力し、フォーマットする方法が多数用意されています。この柔軟性は、アニメーションやインターフェイスのクリエイティブコントロールの機能、および ActionScript を使用して実行できるエラーチェックや検証によって実現されています。

データ収集用のフォームを Animate で作成する利点としては、次のようなものがあります。

• デザインコントロールの向上

• ページの更新の減少または不要化

• 共通アセットの再利用

   ユーザーから収集した情報は、ユーザーのコンピューターの共有オブジェクトに保存します。共有オブジェクトを使用すると、データをユーザーのコンピューターに保存できます。これは Cookie の使用に似ています。共有オブジェクトについて詳しくは、『ActionScript 2.0 リファレンスガイド』または『ActionScript 3.0 言語およびコンポーネントリファレンス』の「sharedObject クラス」を参照してください。

データの送信と処理

通常、情報をサーバーに送信する前に、それをサーバーが認識できるような形式に処理する必要があります。サーバーがデータを受信すると、様々な方法で操作することができ、SWF ファイルに受け入れられる形式で返すことができます。この形式は、名前と値のペアから複雑なオブジェクトまで様々です。

 アプリケーションサーバーでは、出力の MIME タイプが application/x-www-urlform-encoded に設定されている必要があります。この MIME タイプがない場合は、結果が Animate に到達しても通常は使用できません。

次の表に、Animate を使用してサーバーとの間でデータを送受信するいくつかの方法を示します。

データのロードと検証の追加

データをサーバーに送信する前に、取得した情報を検証します。これにより、リモートサーバーの負荷を抑えることができます。これは、ユーザーが必須フィールドに入力しないときほど多くの要求を処理しないためです。どのアプリケーションでも、クライアント側の検証に全面的に頼らず、サーバー側でも検証を行う必要があります。

簡単な登録またはログインのフォームを作成する場合でも、ユーザーが名前とパスワードを入力したことを確認します。この検証は、要求をリモートのサーバー側スクリプトに送信して、結果を待つ前に行います。サーバー側の検証だけに頼らないでください。ユーザーがユーザー名しか入力しないと、サーバー側のスクリプトは要求を受信し、送信中のデータを検証して、ユーザー名とパスワードの両方が必要であるというエラーメッセージを Animate アプリケーションに返さなければなりません。同様に、検証がクライアント側のみで SWF ファイル内で実行された場合、ユーザーが SWF ファイルをハッキングして検証を回避し、不正なデータを書き込もうとしてデータをサーバーに送信する可能性があります。

クライアント側の検証は、フォームのフィールドが 1 文字以上であるか、ユーザーが文字列ではなく数値を入力したことを確認する程度のもので十分です。例えば、電子メールアドレスを検証するには、Animate のテキストフィールドが空ではなく、少なくともアットマーク（@）とドット（.）の文字が入力されていることを確認します。サーバー側の検証では、もっと複雑な検証を追加して、電子メールアドレスが有効なドメインに所属していることを確認します。

サーバーから SWF ファイルにロードするデータを処理する ActionScript を記述する必要があります。SWF ファイルへのデータのロードが終了すると、その場所からデータにアクセスできます。ActionScript を使用して、データがすべてロードされたかどうかを確認します。コールバック関数またはリスナーを使用して、データがドキュメントにロードされたことを通知することもできます。

データはロードすると、いくつかの方法でフォーマットできます。

• XML をロードした場合、データの解析と使用に XML クラスメソッドとプロパティを使用します。名前と値のペアを使用する場合、このペアは変数に変わり、変数として操作できます。

• データを Web サービスや Animate Remoting から受け取ることもあります。

どちらの場合にも、配列、オブジェクト、またはレコードセットなどの複雑なデータ構造を受け取る可能性があり、これを解析して適切にバインドする必要があります。

エラー処理とデバッグの使用

アプリケーションは、一定のエラーを予測してそれに合った処理ができるように十分な堅牢性を持たせる必要があります。

ActionScript 2.0 でエラー処理を実行する最もよい方法は、try-catch-finally ブロックを使用することです。これはカスタムエラーをスローしてキャッチします。カスタムエラークラスを作成することによって、アプリケーション全体でコードを再利用することができ、エラー処理コードを記述し直す必要がありません。カスタムエラーのスローについて詳しくは、「Error クラス」（『ActionScript 2.0 リファレンスガイド』）を参照してください。try-catch-finally ブロックについて詳しくは、「try..catch..finally」（『ActionScript 2.0 リファレンスガイド』）を参照してください。

ActionScript 3.0 では、エラーのキャッチに flash.errors クラスを使用します。

詳しくは、『ActionScript 3.0 のプログラミング』の「アプリケーションの同期エラーの処理」を参照してください。

ファイルの整理とコードの保存

ファイルを整理してコードを保存する前に、次に示すガイドラインについて検討してください。

• SWF ファイルを複数の SWF ファイルに分割するか。分割する場合は、互いの関係をどのようにするか。

• 複数の SWF ファイルでどのアセットが共有できるか。

• 動的にロードするのはどのファイルか。

• ActionScript をどこにどのようにして格納するか。

  アプリケーションを開発するときは、サーバー側のコードとファイルを ActionScript パッケージの論理ディレクトリ構造に類似したディレクトリ構造に保存します。コードがよく整理され、上書きされる危険性が低減するように、コードをこの方法で配置します。

  大きなアプリケーションでは、クライアント側の通信とサービスをクラスにカプセル化します。クラスを使用すると、次のような利点があります。

• 複数の SWF ファイルでコードを再利用できます。

• コードを一元管理して編集し、すべての SWF ファイルを再パブリッシュすることによってこれらのファイルを更新できます。

• 類似した機能を実行する様々な UI エレメントやその他アセットを操作できる単一の API を作成することができます。

MVC デザインパターンの使用

MVC デザインパターンは、アプリケーションで情報、出力、およびデータ処理を分けるときに使用します。アプリケーションは、モデル、ビュー、およびコントローラという 3 つのエレメントに分割されます。これらはそれぞれ、プロセスの異なる部分を処理します。

アプリケーションのデータとルールを組み込みます。アプリケーションの処理の大部分は、デザインパターンのこの部分で発生します。このモデルには、CFC、EJB、Web サービスなどのコンポーネントとデータベースも含まれます。返されるデータは、プロセスのこの部分では、アプリケーションのインターフェイス（またはフロントエンド）用にフォーマットされていません。返されたデータは別のインターフェイス（またはビュー）に使用できます。

アプリケーションのフロントエンド（ユーザーが操作に使用するインターフェイス）を処理し、モデルのコンテンツをレンダリングします。このインターフェイスは、モデルのデータの表示方法を指定し、ユーザーが使用するビューを出力し、ユーザーがアプリケーションのデータにアクセスまたは操作できるようにします。モデルが変更されると、ビューはデータを書き出しまたは読み込み（データを送信または要求）することによって更新され、その変更を反映します。複合型の Web アプリケーション（例えば Web ページ上で他のアプリケーションとやり取りする Animate を組み込んだアプリケーションなど）を作成する場合は、デザインパターンのビューの一部として、複数のインターフェイスを用意することを検討します。MVC デザインパターンは、各種ビューの処理をサポートします。

データを処理し表示するための、モデルとビューの要件を処理します。通常は、多数のコードが収められています。インターフェイス（またはビュー）からのユーザーの要求によって、モデルのどの部分でも呼び出します。アプリケーション固有のコードが収められています。このコードはアプリケーション固有のものであるため、通常は再利用できません。ただし、デザインパターン内のその他のコンポーネントは再利用できます。コントローラはデータの処理や出力は行いません。しかし、ユーザーからの要求を読み込んで、モデルまたはビューのコンポーネントの呼び出しが必要な部分を判断し、データの送信先と、返すデータに適した形式を判断します。コントローラは、モデルデータ内の、表示を必要とする部分にビューが必ずアクセスできるようにします。通常、コントローラはモデルとビューにかかわる変更の送信と応答を行います。

このモデルの各部分は、プロセス全体の中で必要な機能をすべて備えたコンポーネントとして作成されています。モデルのある部分を変更（例えばインターフェイスの手直しなど）しても、プロセスの他の部分は通常修正を必要としません。このため、問題が発生することは少なくなります。デザインパターンが正しく作成されていれば、モデルやコントローラを手直しすることなくビューを変更することができます。アプリケーションで MVC が使用されていない場合、どこかの部分で変更を行うと、コード全体に波及効果が起こり、特定のデザインパターンを使用していた場合よりも多くの変更が必要になります。

MVC パターンを使用する重要な理由として、データとロジックをユーザーインターフェイスと分離することが挙げられます。プロセス内のこの部分を分離すると、同じモデルと未フォーマットのデータを使用する、異なったいくつかのグラフィカルインターフェイスを利用することができます。つまり、様々な Animate インターフェイスを持つアプリケーションを使用できるということです。これらは Web 用のインターフェイス、Pocket PC 用のインターフェイス、携帯電話用のインターフェイス、そして Animate をまったく使用しない HTML バージョンなどです。データをアプリケーションのその他の部分と分離すると、複数のクライアントインターフェイスの開発、テスト、さらに更新でも大きく時間を短縮することができます。同様に、既存のモデルが使用できる場合、同じアプリケーションに新しいフロントエンドを追加するほうが容易です。

e-コマース Web サイトや e-ラーニングアプリケーションなどの大規模で複雑なアプリケーションを構築する場合は、MVC だけを使用します。このアーキテクチャを使用するには、Animate とこのデザインパターンがどのように作用するかを計画し、理解することが必要です。様々な部分が互いにどのように関係しているかを注意深く検討します。通常、これにはテストとデバッグが必要です。MVC を使用するとき、テストとデバッグは一般の Animate アプリケーションよりも複雑で難解です。複雑性を上げる必要のあるアプリケーションを構築する場合は、MVC を使用して作業を整理することを検討してください。

セキュリティの高いアプリケーションの作成

ログインして記事を読むだけの小さなポータルサイトを作成する場合でも、大規模な e-コマースストアを作成する場合でも、不正なユーザーがアプリケーションをハッキングしようとする可能性はあります。このため、次の手順でアプリケーションのセキュリティを高めることを検討してください。

• データを HTTPS に掲載します。これは、セキュリティを高めたいデータ用のものです。データを処理するためにリモートサーバーに送信する前に、Animate で値を暗号化します。

   SWF ファイルには、ユーザーに見られたくない情報やコードを決して保存しないでください。SWF ファイルを逆アセンブルして、サードパーティソフトウェアでそのコンテンツを見るのは容易です。

• クロスドメインポリシーを追加します。これによって、許可されていないドメインからこちら側のアセットにアクセスできなくなります。