【IT168 技术文章】

    Flash平台可帮助你构建富用户体验的应用，而Facebook平台可帮助你构建富社会化体验的应用。将二者合而为一，你就可以构建高交互性、富于表现力，并融入了社会化功能的杀手级应用了。

    本系列文章（共分三部分）将为你介绍基于Facebook和Flash平台的应用程序架构，解析你能在此平台上构建的各种应用类型，并说明这些应用如何与你的服务器、Facebook服务器通讯。

    可构建的应用类型

    你可构建三种Flash与Facebook平台集成的应用：基于Facebook的嵌入式应用、对外服务的Web应用和桌面应用。

· 基于Facebook的嵌入式应用。部署在你自己的服务器上，但其用户通过Facebook站点访问。用户看到的是一个将你的应用包容其中的Facebook容器。你访问Facebook上的某个应用（通常是因为收到朋友邀请，或搜索某个应用时得到一个链接）时，Facebook服务器会将请求转发给你的应用服务器，得到一个页面（HTML和Javascript代码），最后在Facebook站点上展示出来。这种方式对于访问Facebook站点的用户而言，提供的体验是无缝的。这类应用的例子很多，比如来自Playfish和Zyng德克萨斯扑克的谁有最聪明的大脑应用。

· 提供对外服务的独立Web应用，也部署在你自己的服务器上，但用户通过你提供的URL而不是Facebook站点来访问该应用。在外部站点中，你可以通过Facebook API和Facebook Connect来增加Facebook的特性。比如利用Facebook API实现用户登录，应用在一个新的浏览器窗口中打开Facebook登录页面，用户必须在这里登录后，才能访问你本身的应用。为了避免在 Facebook站点上登录，为用户提供无缝体验，你就需要使用Facebook Connect了。比如，某用户阅读一篇博客后，可能想写点评论。那么不必让用户在你的站点上再注册一个账号吧，用他/她在Facebook上的帐户就好了。为提升用户体验，Facebook API和Facebook Connect还允许你访问用户的全部数据，比如在评论旁边显示评论者的姓名和个人图片。类似的如购物网站，通过让用户用他们的Facebook帐户登录，你可以查看其朋友是否推荐或评论过什么商品。这类的应用如RedBull Connect和City Search，在这些网站上你可发表评论、阅读朋友的评论，或将自己的评论发表到Facebook Wall或朋友的新闻种源中。

·桌面应用，除了基于Flash平台的桌面AIR这个特点外，其他和对外服务的Web站点是大致相同的。AIR桌面应用同样是借助Facebook Connect为用户提供无缝的Facebook登录体验。这类应用的例子有Seesmic和Nomee。

    在开发Facebook应用之前，必须在Facebook开发者应用上注册，获得API授权和应用的密钥。至于具体步骤，请参考构建你的第一个Facebook应用快速入门。在注册过程中，需要你指定要开发应用的一些设定，例如应用是基于Web还是桌面的，是否使用FBML或iFrame。

  ·  开发基于Facebook的嵌入式应用时，你需指定为Web应用类型，并选择使用iFrame或FBML。

  ·开发对外服务的独立Web应用时，你需指定Facebook Connect信息。

  · 开发桌面应用时，你需指定为桌面应用类型。

    现在，在我们深入分析基于Flash平台的嵌入式应用、对外Flash平台站点和Flash桌面应用的架构前，先让我们大致了解一下常规嵌入式的、非Flash的、基于iFrame和FBML的Facebook应用的架构。

    iFrame Facebook应用

    当用户访问Facebook的某个应用（比如http://apps.facebook.com/someapp）时，Facebook对此请求的处理方式，与应用是基于iFrame还是FBML有关。如果是iFrame应用，Facebook服务器返回的页面包含一个Facebook容器，容器容纳一个iFrame，你的应用就在其中加载（如图1）。

    图1 iFrame应用架构

 1.   当用户在Facebook网站上访问你的应用时，浏览器会向Facebook服务器发送一个HTTP请求。

 2.   Facebook服务器返回一个HTML/JavaScript(JS)页面，其中包含了Facebook站点容器和一个iFrame HTML标记。

 3.   用户的浏览器向你的服务器请求将显示在iFrame中的页面（一般是一个PHP、ColdFusion或者JSP式的服务端页面）。 Session信息会通过GET请求中的URL参数传递，这样你的应用服务器就知道此请求是来自Facebook，以及请求是哪个用户发出的。

 4.   服务端页面执行时，可能会根据需要访问数据库或其他服务器，其中也包括通过REST API向Facebook服务器发出请求。调用REST API时，必须包含认证信息，比如在Facebook上注册应用时获得的API Key、该调用的签名（通过传给Facebook方法的参数、用户请求你的应用时指定的Session的MD5哈希串生成）、应用的密钥和其他信息。通常来说，服务端页面会利用标准的代码库生成对Facebook的请求，并且其签名也在服务端脚本中产生。尽管Facebook官方只提供了一个服务端用户库（支持PHP 5），不过其他的服务端库已由社区开发了很多。另外，Facebook官方还提供了两个客户端库，分别支持JavaScript和ActionScript 3.0。

 5.   Facebook服务器将被请求的数据（XML或JSON格式）返回到你的服务器。

 6.   你的服务器向用户浏览器返回HTML/JS页面，并由客户端浏览器显示在iFrame中。在用户和你的应用交互时，交互行为包括：

     ·   如果你的应用包含了新的服务端页面请求，将重复步骤3-6。

     ·   如果你的应用包括对你的服务器的JavaScript异步调用，那么步骤7-10将被执行。和上面有所不同的是，此时向用户浏览器返回的通常是XML或JSON数据，由页面的JavaScript脚本负责处理。

     ·   还有一种情况，是页面中的JavaScript代码直接访问Facebook服务器，而不通过你的应用服务器中转（步骤11-12）。Facebook官方提供了对应的JavaScript API库。利用这个库，你可将多个API调用打包，通过一个HTTP请求向Facebook服务器发出。这项技术有利有弊。好处是减少了总的HTTP访问次数，缺点是导致页面大小和复杂度的上升。

    提示：你也可以通过XFBML技术，在你的应用中放置一些简单的FBML标签（具体会在下一个部分中讨论）；当然为了使用这些标签，你必须用JavaScript代码扫描标签的DOM，然后也可以将一批API请求组织成向Facebook服务器的一次调用。

FBML Facebook应用

    现在，你已经对iFrame应用的工作原理有了一个大致把握，接下来我们讨论FBML Facebook应用（见图2）。在前面，你的应用是存在iFrame中的一个独立实体，现在，它将变成Facebook服务器响应请求时返回的HTML 页面的一个部分。在这种情况下，Facebook服务器会代为处理所有对你的应用的调用。当然，除了返回HMTL和JavaScript，你的服务端页面也可以返回FBML代码，Facebook服务器在将它返回给用户浏览器前，会自动将其转换为HTML和JavaScript代码。

    图2 FBML Facebook应用架构

 1.   当用户在Facebook网站上访问你的应用时，浏览器会向Facebook服务器发送一个HTTP请求。

 2.   Facebook服务器将请求转给你的服务器，一般来说都是请求一个服务端页面（如PHP、ColdFusion或JSP）。在这种情况下，Session信息将通过POST请求（而iFrame通常是GET请求）中的URL参数传递，这样你的应用服务器就知道此请求来自 Facebook，以及请求的发送用户是谁。

 3.   服务端页面执行时，可能会根据需要访问数据库或其他服务器，其中也包括通过REST API向Facebook服务器发出请求。调用REST API时，必须包含认证信息，比如在Facebook上注册应用时获得的API Key、该调用的签名（通过传给Facebook方法的参数、用户请求你的应用时指定的Session的MD5哈希串生成）、应用的密钥和其他信息。 和iFrame应用一样，服务端页面通常都借助一个代码库生成对Facebook的请求和签名。因为所有返回都是通过Facebook代理的，你的应用请求Facebook服务器时，就没必要每次单独调用一个API。 FBML提供了大量 标签，可用于获得用户姓名、图片、创建对话框和小组件等。对于这类要求，你只需要直接返回FBML代码，后面的工作留给Facebook服务器就可以了，它在将页面返回给用户浏览器前，会自动将FBML转换为HTML和JavaScript代码。当然，不是所有功能都有标签支持的，比如要取得朋友的生日信息，还是得从你的服务器向Facebook发送对应的API调用请求。

 4.   Facebook服务器向你的服务器返回被请求的数据，格式是XML或JSON。

 5.  你的服务器向Facebook服务器返回HTML/JS/FBML页面。

 6.   Facebook服务器将HTML/JS页面返回给用户浏览器。在用户和你的应用交互过程中产生的交互行为包括：

     ·    如果你的应用包括新的服务端页面请求，重复步骤1-6。

     ·    不同于请求新的页面，你应用程序中的JavaScript可通过使用官方提供的JavaScript库直接向Facebook服务器发出请求（同上面iFrame讨论中的7-10步骤）。

    提示：虽然在FBML应用中，你也可以向你的应用服务器发出异步请求（同图1的步骤7-10），但这些调用必须位于通过<fb:iFrame> 标签在iFrame里加载的内容中。
 

    Flash iFrame Facebook应用

    至此，我们已经介绍了iFrame和FBML的情况，接下来开始讨论在应用中如何集成Flash内容的问题。虽然你完全可以构建一个包含了 HTML/JavaScript/ActionScript的混合应用，但为了说明的方便，我们还是将注意力集中在基本的Flash应用层面——其全部视 觉效果和功能都封装在SWF文件（Flash Player可识别并渲染的、编译后的字节码格式）中。 在上述混合应用中，可以使用到多种API调用，比如服务端API、前面已讨论过的客户端JavaScript API，以及这里将讨论的客户端ActionScript API调用。 你可将SWF文件集成到iFrame或FBML应用中。图3说明了在iFrame应用中的简单实现方法。

    图3 Flash iFrame Facebook应用

 1.   用户在Facebook站点上访问你的应用时，浏览器向Facebook服务器发出一个HTTP请求。

 2.   Facebook服务器返回一个HTML/JS页面，其中包含Facebook站点容器和一个iFrame HTML标签。

 3.   用户浏览器向你的服务器请求包含在iFrame中的页面。和前面讨论过的情况不同，这个页面不再是一个服务端页面，而是一个简单的 HTML页面（内含SWF文件）。此时，Session信息仍通过GET请求的URL参数传递；你的服务器解析这些参数，并转换为内嵌的SWF所需的 flash参数，这样，在SWF中的ActionScript代码就可以根据这些参数，直接向Facebook服务器发出请求了。

 4.   你的服务器将HTML/JS页面返回给用户浏览器，并在iFrame中展示。

 5.   用户浏览器向你的服务器发出其他请求，即请求展示在iFrame中的HTML页面中内嵌的SWF文件。

 6.   你的服务器返回SWF文件。

    当用户和你的应用交互时，SWF可向Facebook服务器、或你的服务器发送异步请求。

     ·SWF文件中的ActionScript脚本直接访问Facebook服务器（步骤7-8）。你可以使用Google代码中的ActionScript 3.0 Library for Facebook Platform。

    出于Flash Player安全性的考虑，SWF文件只能从两类服务器获取数据：（1）提供SWF文件的服务器（这里即你的服务器）；（2）有跨域策略文件（在文件中列 出了SWF来源服务器）的服务器。也就是说，若要你的SWF能直接访问Facebook服务器，Facebook服务器必须在跨域策略文件中开放了访问权 限。如果看过Facebook的跨域策略文件，你会发现它通过一个通配符，授予了来自任何服务器的SWF文件的访问权：

    <cross-domain-policy>

    <site-control permitted-cross-domain-policies="master-only"/>

    <allow-access-from domain="*"/>

    </cross-domain-policy>

     ·   你的ActionScript访问Facebook服务器时，必须像前面非Flash的iFrame和FBML应用部分讲到的那样，传送应用API Key和用于说明访问来自何处的签名信息。利用ActionScript 3.0 Library for Facebook Platform中的类可自动生成签名；为此，你只需向ActionScript session类的构造函数传入应用的API Key和密钥。

    但是，你不应在SWF文件以硬编码方式写入上述数据，因为SWF文件可用多种软件反编译。相反，SWF应该在运行时向你的服务器发出请求（可 HTTP或Flash Remoting方式），从而获得应用的密钥，接下来再传给ActionScript session类的构造函数，从而生成访问Facebook服务器时所需的签名。

    记住，此签名由下列信息组成：传递给Facebook服务器的URL参数、Session Key（用户访问你的应用时分配）的MD5哈希串、应用的密钥等。

    ·    若需实现任何服务端处理功能（如在你的服务器上保存某些数据），可在ActionScript代码中通过远程过程调用方法实现（见步骤 9-10）。对于利用Flex构建的Flash平台应用而言，这些方法包括HTTP、Web Service和Flash Remoting请求技术。其中最便捷的方法当属Flash Remoting——它通过开源的二进制Action Message Format (AMF)实现服务器和Flash Player间的数据交换。当然，服务端代码在向客户端返回数据之前，可根据需要访问Facebook服务器（此点未包含在图3中）。

 Flash FBML Facebook应用

    除了在iFrame中集成你的Flash应用，还可以通过FBML标签<fb:swf>将其植入到FBML应用中。在这种情况中，你的应用会由一或多个服务端页面组成；这些页面包含FBML（用于获取或展示Facebook形式的可视化内 容、对话框和小控件）、不能通过简单的FBML标签实现的服务端API调用，以及包纳了你的Flash内容的<fb:swf>标签。FBML应用的好处是在访问Facebook提供的社会化特性时非常简单，向Facebook传送FBML标签，就可自动渲染为HTML内容。 而其不足，则是此处在多个地方编写表现层和逻辑层的代码更为复杂：SWF文件中、服务端页面中，以及发向Facebook服务器的FBML代码中（见图 4）。有关iFrame和FBML应用区别的更详细信息，请参看iFrame、FBML Flash Facebook应用比较。

    图4 Flash FBML Facebook应用

 1.   用户通过Facebook站点访问你的应用时，浏览器向Facebook服务器发送HTTP请求。

 2.   Facebook服务器向你的服务器发出请求——一般请求的是PHP、JSP或ColdFusion式的服务端页面。在这种情况 下，Session信息通过POST请求（而非iFrame中的GET请求）中的URL参数传递，那么，你的应用服务器就知道该请求来自 Facebook、是哪个用户发出的请求了。

 3.   服务端页面执行时，可根据需要访问数据库和其他服务器，当然包括利用REST API访问Facebook服务器。    API调用必须包含认证信息——包括在Facebook上注册应用时获得的API Key、该调用的签名（通过传给Facebook方法的参数、用户请求你的应用时指定的Session的MD5哈希串生成）、应用的密钥和其他信息。    对于非Flash的iFrame和FBML应用来说，服务端页面通常可利用现成的代码库实现对Facebook的访问，以及生成签名。因此对于所有FBML应用而言，用户浏览器的所有请求都是通过Facebook代理的，你的应用在请求Facebook服务器时，就没必要每次单独调用一个API；同时，诸如获得用户姓名、图片、生成对话框等等，都可以利用FBML 标签实现。    Facebook服务器在将页面返回给用户浏览器前，会自动将FBML转换为HTML和JavaScript代码。当然，不是所有功能都有标签支持的，比如要取得朋友的生日信息，还是得从你的服务器向Facebook发送对应的API调用请求。

 4.   Facebook服务器将被请求数据返回给你的服务器，格式可为XML或JSON。

 5.  你的服务器向Facebook服务器返回包括HTML/JS和FBML内容的页面。

 6.   Facebook服务器向用户浏览器返回HTML/JS页面。该页面包括了（用标签<fb:swf>指定）对你的服务器上SWF文件的引用。

 7.   用户浏览器向你的服务器请求内嵌在HTML页面中的SWF文件。

 8.   你的服务器返回SWF文件。

    在用户和你的应用交互过程中，SWF可向Facebook服务器或你的服务器发出异步调用。

   ·   SWF中ActionScript代码直接访问Facebook服务器（见步骤9-10），这可利用宿主在Google代码上 官方支持的ActionScript 3.0 Library for Facebook Platform实现。当然，Facebook必须通过跨域策略文件开放了访问权限，且API调用中传送了所需参数。有关这部分的详细问题，前面的 Flash iFrame应用中已有讨论。

   ·   若需实现任何服务端处理功能（如在你的服务器上保存某些数据），可在ActionScript代码中通过远程过程调用方法实现（见 步骤11-12）。对于利用Flex构建的Flash平台应用而言，这些方法包括HTTP、Web Service和Flash Remoting请求技术。其中最便捷的方法当属Flash Remoting——它通过开源的二进制Action Message Format (AMF)实现服务器和Flash Player间的数据交换。当然，服务端代码在向客户端返回数据之前，可根据需要访问Facebook服务器（此点未包含在图4中）。

    独立Flash Facebook站点应用

    图5描绘了独立的Flash Facebook站点应用的架构。其主要区别是Facebook服务器不再代为处理全部浏览器请求。另外，现在你还必须在客户端代码中用Facebook API 或 Facebook Connect处理用户的登录。如果使用Facebook API处理登录，用户需在新的浏览器窗口中登录Facebook并返回到你的应用中。为了避免在Facebook站点登录，为用户提供更无缝的登录体验，你可以使用Facebook Connect。

    图5 独立的Flash Facebook站点应用

 1.  当用户在你的站点上访问应用时，浏览器向你的服务器发送HTTP请求——请求一个HTML或任何服务端页面。

 2.  服务器返回包含了对你的SWF文件的引用的HTML/JS页面。如果使用Facebook Connect，该HTML页面会包括部分用于初始化Facebook Connect的JavaScript代码（说明）。

 3.   用户浏览器向你服务器请求内嵌在HTML页面中的SWF文件。

 4.   你的服务器返回SWF文件。

 5.   SWF 文件中的ActionScript 代码直接异步请求Facebook服务器——方法是使用官方提供的ActionScript 3.0 Library for Facebook Platform。你每次可以提交单独一个调用，也可以提交成批调用。在这种情况下，最初对Facebook服务器的调用必须获得授权；一旦用户成功登录 （最好使用Facebook Connect），得到了Session Key，那么后续所有Facebook API调用所需的签名就会由ActionScript 3.0 Library for Facebook Platform的类生成。当然，Facebook必须通过跨域策略文件开放了访问权限，且API调用中传送了所需参数。有关此问题的更多信息，请参看前 面在Flash iFrame应用部分的讨论。

 6.   Facebook服务器向你的Flash应用返回XML或JSON格式的数据，并由你的应用处理这些数据。

 7.   若 需实现任何服务端处理功能（如在你的服务器上保存某些数据），可在ActionScript代码中通过远程过程调用方法实现（可以是 HTTP、Web Service和Flash Remoting）。其中最便捷的方法当属Flash Remoting——它通过开源的二进制Action Message Format（AMF）实现服务器和Flash Player间的数据交换。

 8.   若有必要，服务器可与Facebook服务器进行其他通讯。

 9.   你的服务器处理Facebook服务器返回的结果数据。

10.   你的服务器将数据返回给用户浏览器中的Flash应用。图5中，我们利用Flash Remoting和AMF交换数据，当然你也可用Web Service、SOAP、HTTP实现文本或XML格式的数据交换。

  Flash Facebook桌面应用

    最后，让我们来讨论Flash Facebook桌面应用的架构。基于Flash平台的桌面应用，就是AIR应用（这个地方请再斟酌一下）。有关构建AIR应用的更多信息，请参阅AIR文档和AIR开发者中心。Flash Facebook桌面应用（如图6）的架构，和前面讨论过的独立Flash Facebook站点应用非常类似，唯一的不同是此时不需要浏览器，SWF文件也存在于安装了AIR应用的用户本地计算机上。

    图6 Flash Facebook桌面应用

 1.   用户安装并运行AIR桌面程序。

 2.   SWF文件中的ActionScript 代码直接异步请求Facebook服务器——方法是使用宿主在Google代码上 官方提供的ActionScript 3.0 Library for Facebook Platform。你每次可以提交单独一个调用，也可以提交成批调用。在这种情况下，最初对Facebook服务器的调用必须获得授权；一旦用户成功登录 （最好使用Facebook Connect），得到了Session Key，那么后续所有Facebook API调用所需的签名就会由ActionScript 3.0 Library for Facebook Platform的类生成。当然，Facebook必须通过跨域策略文件开放了访问权限，且API调用中传送了所需参数。有关此问题的更多信息，请参看前 面在Flash iFrame应用部分的讨论。

 3.   Facebook服务器向你的Flash应用返回XML或JSON格式的数据，并由你的应用处理这些数据。

 4.   若 需实现任何形式的服务端处理功能（如在你的服务器上保存某些数据），可在ActionScript代码中通过远程过程调用方法实现 （可以是HTTP、Web Service和Flash Remoting）。其中最便捷的方法当属Flash Remoting——它通过开源的二进制Action Message Format (AMF)实现服务器和Flash Player间的数据交换。

 5.   若有必要，服务器可与Facebook服务器进行其他通讯。

 6.   你的服务器处理Facebook服务器返回的结果数据。

 7    你的服务器将结果数据返回给Flash桌面程序。图6中利用Flash Remoting和AMF交换数据，当然你也可用Web Service、SOAP、HTTP实现文本或XML格式的数据交换。

    总结与引申

    本系列文章介绍了三类基于Flash和Facebook平台的应用：基于Facebook的嵌入式应用、Web站点式的独立应用和桌面应用。对于任何Facebook应用，你都可将Flash程序包纳在iFrame或FBML应用中。具体来说，从架构和处理流程角度可分为六种子类型？(本文的架构图和流程处理适用于）：基于Facebook非Flash的iFrame/FBML应用，基于Facebook的Flash iFrame/FBML应用，以及Flash站点应用、Flash桌面应用。 有关iFrame和FBML应用区别的更多信息，请参考iFrame、FBML Flash Facebook应用比较。有关构架基于Facebook的Flash应用的详细步骤，请观看快速构建Facebook应用视频，或阅读利用Flexible构建Facebook应用快速入门。