FacebookとFlash、2つのプラットフォームを組み合わせてアプリケーションを開発しよう

原題：Facebook Platform ｘ Flash Platformで開発するアプリケーションのアーキテクチャーの理解

Facebook上のアプリ：Non-Flashアプリの場合

　Facebook上のアプリにユーザがリクエストすると（例えば、http://apps.facebook.com/someapp/）、Facebookのクロームを含むページを返します。このページ内にはiFrameタグがあり、iFrame内にあなたのアプリがロードされます（図1）。

図1「Facebook上のアプリ」のアーキテクチャ：Non-Flashアプリの場合

1. Facebook上でユーザがアプリにアクセスします。つまり、ブラウザーがFacebookにHTTPリクエストを行います。
2. Facebookサーバーは、HTML／JavaScriptページを返します。このページには、FacebookのクロームとiFrameタグが含まれています。
3. ブラウザーは、あなたのサーバーに対して、iFrame内に表示するページをリクエストします。通常、このリクエストされるページは（PHP、ColdFusion、JSPなどの）アプリケーションサーバーページですが、HTMLページでも構いません。このページには、ユーザがFacebookにログインしているかをチェックするためのロジックを含める必要があります。ユーザがFacebookにログインすると、「fbs_applicationID」というcookieにセッションデータが保存されます。このapplicationIDは、Facebook Developer applicationにアプリを登録した際に割り振られるIDです。またcookieには「access_token」という変数があり、これを取得し、ログイン後に行うFacebook Graph APIへの呼び出し全てにおいてこの変数を渡すことになります。もしユーザがFacebookにログインしていない状態、つまりcookieに変数「access_token」が保持されていない場合は、Facebookのログインページへリダイレクトするようにしなければなりません。
4. アプリケーションサーバーページが処理され、必要に応じて、Graph APIを使ったFacebookへのコールや、データベースや他のサーバーへのコールが行われます。FacebookのAPIをコールする際は、全てのコールにおいてセッションcookieから取得したaccess_tokenを含める必要があります。
5. Facebookサーバーは、リクエストされたデータをJSON形式であなたのサーバーへと返します。
6. あなたのサーバーがHTML／JavaScriptページをユーザのブラウザーに返し、iFrame内でページが表示されます。

　さらにユーザがアプリを操作することで、以下のような処理が行われます。

• アプリ内に新しいサーバーサイドページへのリンクが含まれていて、ユーザがそれをクリックした場合、ステップ3～6が繰り返されます。
• また、アプリ内にあなたのサーバーに対する非同期型JavaScriptコールが含まれている場合、図1のステップ7～10の処理が行われます。ステップ3～6と異なりこの場合、ユーザのブラウザーにはJSON形式で返され、ページ内のJavaScriptで処理が行われます。
• その他にも、Facebook JavaScript SDKを使えば、ページ内のJavaScriptから、あなたのアプリケーションサーバーを介さずに直接Facebookサーバへコールすることも可能です（図1のステップ11～12）。

※注意

　以前はFBMLを使ってFacebookに対してAPIリクエストを送信することができましたが、FBMLは2012年1月1日から非推奨とされています。

Facebook上のアプリ：Flashアプリの場合

　Non-Flashアプリでの基本を押さえたところで、次はいよいよFlashアプリの場合について説明していきましょう（図2）。

図2　「Facebook上のアプリ」のアーキテクチャ：Flashアプリの場合

1. Facebook上でユーザがアプリにアクセスします。つまり、ブラウザーがFacebookにHTTPリクエストを行います。
2. Facebookサーバーは、HTML／JavaScriptページを返します。このページには、FacebookのクロームとiFrameタグが含まれています。
3. ブラウザーは、あなたのサーバーに対して、iFrame内に表示するページをリクエストします。先程の場合、表示するページはアプリケーションサーバーページかHTMLページでしたが、ここではそれらのページ内にSWFファイル（Flashアプリ）を埋め込みます。
4. あなたのサーバーがHTML／JavaScriptページをユーザのブラウザーに返し、iFrame内でページが表示されます。このページには、先程と同様にユーザがFacebookにログインしているかをチェックするためのロジックを含める必要があります。ただし、このチェックロジックは、Adobe ActionScript 3 SDK for Facebook Platformを使ってSWF内に実装することも可能です。また、アプリ内にcookieの変数「access token」の有無をチェックするコードを含める必要があります。もし、access tokenがない場合は、Facebookのログインページへリダイレクトするようにしなければなりません。
5. ユーザのブラウザーはあなたのサーバーに対して別途リクエストを行います。今度はiFrame内のHTMLページに埋め込むSWFを取得するためです。
6. あなたのサーバーはSWFファイルを返します。
7. ユーザがアプリを操作すると、Adobe ActionScript 3 SDK for Facebook Platformを使って、Facebookサーバーへ非同期型のコールを行います。全てのAPIコールにおいてaccess tokenを含める必要がありますが、これはSDKにより自動で行われます。

   　Flash Playerのセキュリティ制約により、SWFファイルがデータコールを行うことができるのは、当該SWFファイルの供給元となったサーバー（つまりあなたのサーバー）、および当該SWFファイルの供給元サーバーを記したクロスドメインポリシーファイルの配置されたサーバーに対してのみです。つまり、SWFファイルからFacebookサーバーへ直接コールするためには、「SWFファイルにFacebookサーバーへのアクセスを許可する」クロスドメインポリシーファイルがFacebookサーバーに配置されている必要があります。以下は、Facebookのクロスドメインポリシーファイルの例です。ここでは「ワイルドカード「*」を使って、あらゆるサーバーから供給されたSWFファイルのアクセスを許可しています。

   <cross-domain-policy>
      <site-control permitted-cross-domain-policies="master-only"/>
      <allow-access-from domain="*" secure="false"/>
   </cross-domain-policy>
   

8. FacebookサーバーがJSON形式データをアプリへ返します。
9. ユーザがアプリを操作した際に、（サーバーにデータを保存したり、何らかのサーバーサイド処理を行うなどのために）リモートプロシージャコールメソッドを使ってあなたのサーバーへ非同期型のコールを行うこともできます。リモートプロシージャコールの手段としては、Flexで開発したFlashアプリの場合、HTTP／Webサービス／Flash Remotingなどが使えます。なお、これらのうちFlash Remotingを使うと、最速かつ最軽量のコールを実現することができます。というのも、Flash Remotingは、サーバーとFlash Player間のデータ交換に、オープンソースのバイナリプロトコル「Action Message Format（AMF）」を使っているからです。
10. 必要に応じて、Facebookサーバーとやり取りを行います。
11. Facebookサーバーから返ってきたJSON形式データを、サーバーサイドコードで処理します。
12. あなたのサーバーからブラウザーのFlashアプリにデータを返します。

　ここまでで、Facebookと連携するFlashアプリを開発する場合の「Facebook上のアプリのアーキテクチャ」を解説しました。続いては「外部サイト上のアプリ」との連携を見て行きましょう。

　この記事の続きは、Dreamweaverデベロッパーセンターにてご覧ください。

　

記事の続きはこちら！

Flash＋Facebook関連情報はこちら

• Adobe Developer Connection Flash + Facebook
• Flash＋Facebook Platformの事例