a1基于Facebook和Flash平台的应用架构解析.docx
- 文档编号:6228507
- 上传时间:2023-01-04
- 格式:DOCX
- 页数:11
- 大小:160KB
a1基于Facebook和Flash平台的应用架构解析.docx
《a1基于Facebook和Flash平台的应用架构解析.docx》由会员分享,可在线阅读,更多相关《a1基于Facebook和Flash平台的应用架构解析.docx(11页珍藏版)》请在冰豆网上搜索。
a1基于Facebook和Flash平台的应用架构解析
本系列文章(共分三部分)将为你介绍基于Facebook和Flash平台的应用程序架构,解析你能在此平台上构建的各种应用类型,并说明这些应用如何与你的服务器、Facebook服务器通讯。
可构建的应用类型
你可构建三种Flash与Facebook平台集成的应用:
基于Facebook的嵌入式应用、对外服务的Web应用和桌面应用。
基于Facebook的嵌入式应用,部署在你自己的服务器上,但其用户通过Facebook站点访问。
用户看到的是一个将你的应用包容其中的Facebook容器。
你访问Facebook上的某个应用(通常是因为收到朋友邀请,或搜索某个应用时得到一个链接)时,Facebook服务器会将请求转发给你的应用服务器,得到一个页面(HTML和Javascript代码),最后在Facebook站点上展示出来。
这种方式对于访问Facebook站点的用户而言,提供的体验是无缝的。
这类应用的例子很多,比如来自Playfish和Zyng德克萨斯扑克的谁有最聪明的大脑应用。
提供对外服务的独立Web应用,也部署在你自己的服务器上,但用户通过你提供的URL而不是Facebook站点来访问该应用。
在外部站点中,你可以通过FacebookAPI和FacebookConnect来增加Facebook的特性。
比如利用FacebookAPI实现用户登录,应用在一个新的浏览器窗口中打开Facebook登录页面,用户必须在这里登录后,才能访问你本身的应用。
为了避免在Facebook站点上登录,为用户提供无缝体验,你就需要使用FacebookConnect了。
比如,某用户阅读一篇博客后,可能想写点评论。
那么不必让用户在你的站点上再注册一个账号吧,用他/她在Facebook上的帐户就好了。
为提升用户体验,FacebookAPI和FacebookConnect还允许你访问用户的全部数据,比如在评论旁边显示评论者的姓名和个人图片。
类似的如购物网站,通过让用户用他们的Facebook帐户登录,你可以查看其朋友是否推荐或评论过什么商品。
这类的应用如RedBullConnect和CitySearch,在这些网站上你可发表评论、阅读朋友的评论,或将自己的评论发表到FacebookWall或朋友的新闻种源中。
桌面应用,除了基于Flash平台的桌面AIR这个特点外,其他和对外服务的Web站点是大致相同的。
AIR桌面应用同样是借助FacebookConnect为用户提供无缝的Facebook登录体验。
这类应用的例子有Seesmic和Nomee。
在开发Facebook应用之前,必须在Facebook开发者应用上注册,获得API授权和应用的密钥。
至于具体步骤,请参考构建你的第一个Facebook应用快速入门。
在注册过程中,需要你指定要开发应用的一些设定,例如应用是基于Web还是桌面的,是否使用FBML或iFrame。
开发基于Facebook的嵌入式应用时,你需指定为Web应用类型,并选择使用iFrame或FBML。
开发对外服务的独立Web应用时,你需指定FacebookConnect信息。
开发桌面应用时,你需指定为桌面应用类型。
现在,在我们深入分析基于Flash平台的嵌入式应用、对外Flash平台站点和Flash桌面应用的架构前,先让我们大致了解一下常规嵌入式的、非Flash的、基于iFrame和FBML的Facebook应用的架构。
iFrameFacebook应用
当用户访问Facebook的某个应用(比如
图1iFrame应用架构
当用户在Facebook网站上访问你的应用时,浏览器会向Facebook服务器发送一个HTTP请求。
Facebook服务器返回一个HTML/JavaScript(JS)页面,其中包含了Facebook站点容器和一个iFrameHTML标记。
用户的浏览器向你的服务器请求将显示在iFrame中的页面(一般是一个PHP、ColdFusion或者JSP式的服务端页面)。
Session信息会通过GET请求中的URL参数传递,这样你的应用服务器就知道此请求是来自Facebook,以及请求是哪个用户发出的。
服务端页面执行时,可能会根据需要访问数据库或其他服务器,其中也包括通过RESTAPI向Facebook服务器发出请求。
调用RESTAPI时,必须包含认证信息,比如在Facebook上注册应用时获得的APIKey、该调用的签名(通过传给Facebook方法的参数、用户请求你的应用时指定的Session的MD5哈希串生成)、应用的密钥和其他信息。
通常来说,服务端页面会利用标准的代码库生成对Facebook的请求,并且其签名也在服务端脚本中产生。
尽管Facebook官方只提供了一个服务端用户库(支持PHP5),不过其他的服务端库已由社区开发了很多。
另外,Facebook官方还提供了两个客户端库,分别支持JavaScript和ActionScript3.0。
Facebook服务器将被请求的数据(XML或JSON格式)返回到你的服务器。
你的服务器向用户浏览器返回HTML/JS页面,并由客户端浏览器显示在iFrame中。
在用户和你的应用交互时,交互行为包括:
如果你的应用包含了新的服务端页面请求,将重复步骤3-6。
如果你的应用包括对你的服务器的JavaScript异步调用,那么步骤7-10将被执行。
和上面有所不同的是,此时向用户浏览器返回的通常是XML或JSON数据,由页面的JavaScript脚本负责处理。
还有一种情况,是页面中的JavaScript代码直接访问Facebook服务器,而不通过你的应用服务器中转(步骤11-12)。
Facebook官方提供了对应的JavaScriptAPI库。
利用这个库,你可将多个API调用打包,通过一个HTTP请求向Facebook服务器发出。
这项技术有利有弊。
好处是减少了总的HTTP访问次数,缺点是导致页面大小和复杂度的上升。
提示:
你也可以通过XFBML技术,在你的应用中放置一些简单的FBML标签(具体会在下一个部分中讨论);当然为了使用这些标签,你必须用JavaScript代码扫描标签的DOM,然后也可以将一批API请求组织成向Facebook服务器的一次调用。
FBMLFacebook应用
现在,你已经对iFrame应用的工作原理有了一个大致把握,接下来我们讨论FBMLFacebook应用(见图2)。
在前面,你的应用是存在iFrame中的一个独立实体,现在,它将变成Facebook服务器响应请求时返回的HTML页面的一个部分。
在这种情况下,Facebook服务器会代为处理所有对你的应用的调用。
当然,除了返回HMTL和JavaScript,你的服务端页面也可以返回FBML代码,Facebook服务器在将它返回给用户浏览器前,会自动将其转换为HTML和JavaScript代码。
图2FBMLFacebook应用架构
当用户在Facebook网站上访问你的应用时,浏览器会向Facebook服务器发送一个HTTP请求。
Facebook服务器将请求转给你的服务器,一般来说都是请求一个服务端页面(如PHP、ColdFusion或JSP)。
在这种情况下,Session信息将通过POST请求(而iFrame通常是GET请求)中的URL参数传递,这样你的应用服务器就知道此请求来自Facebook,以及请求的发送用户是谁。
服务端页面执行时,可能会根据需要访问数据库或其他服务器,其中也包括通过RESTAPI向Facebook服务器发出请求。
调用RESTAPI时,必须包含认证信息,比如在Facebook上注册应用时获得的APIKey、该调用的签名(通过传给Facebook方法的参数、用户请求你的应用时指定的Session的MD5哈希串生成)、应用的密钥和其他信息。
和iFrame应用一样,服务端页面通常都借助一个代码库生成对Facebook的请求和签名。
因为所有返回都是通过Facebook代理的,你的应用请求Facebook服务器时,就没必要每次单独调用一个API。
FBML提供了大量标签,可用于获得用户姓名、图片、创建对话框和小组件等。
对于这类要求,你只需要直接返回FBML代码,后面的工作留给Facebook服务器就可以了,它在将页面返回给用户浏览器前,会自动将FBML转换为HTML和JavaScript代码。
当然,不是所有功能都有标签支持的,比如要取得朋友的生日信息,还是得从你的服务器向Facebook发送对应的API调用请求。
Facebook服务器向你的服务器返回被请求的数据,格式是XML或JSON。
你的服务器向Facebook服务器返回HTML/JS/FBML页面。
Facebook服务器将HTML/JS页面返回给用户浏览器。
在用户和你的应用交互过程中产生的交互行为包括:
如果你的应用包括新的服务端页面请求,重复步骤1-6。
不同于请求新的页面,你应用程序中的JavaScript可通过使用官方提供的JavaScript库直接向Facebook服务器发出请求(同上面iFrame讨论中的7-10步骤)。
提示:
虽然在FBML应用中,你也可以向你的应用服务器发出异步请求(同图1的步骤7-10),但这些调用必须位于通过 iFrame>标签在iFrame里加载的内容中。 FlashiFrameFacebook应用 至此,我们已经介绍了iFrame和FBML的情况,接下来开始讨论在应用中如何集成Flash内容的问题。 虽然你完全可以构建一个包含了HTML/JavaScript/ActionScript的混合应用,但为了说明的方便,我们还是将注意力集中在基本的Flash应用层面——其全部视觉效果和功能都封装在SWF文件(FlashPlayer可识别并渲染的、编译后的字节码格式)中。 在上述混合应用中,可以使用到多种API调用,比如服务端API、前面已讨论过的客户端JavaScriptAPI,以及这里将讨论的客户端ActionScriptAPI调用。 你可将SWF文件集成到iFrame或FBML应用中。 图3说明了在iFrame应用中的简单实现方法。 图3FlashiFrameFacebook应用 用户在Facebook站点上访问你的应用时,浏览器向Facebook服务器发出一个HTTP请求。 Facebook服务器返回一个HTML/JS页面,其中包含Facebook站点容器和一个iFrameHTML标签。 用户浏览器向你的服务器请求包含在iFrame中的页面。 和前面讨论过的情况不同,这个页面不再是一个服务端页面,而是一个简单的HTML页面(内含SWF文件)。 此时,Session信息仍通过GET请求的URL参数传递;你的服务器解析这些参数,并转换为内嵌的SWF所需的flash参数,这样,在SWF中的ActionScript代码就可以根据这些参数,直接向Facebook服务器发出请求了。 你的服务器将HTML/JS页面返回给用户浏览器,并在iFrame中展示。 用户浏览器向你的服务器发出其他请求,即请求展示在iFrame中的HTML页面中内嵌的SWF文件。 你的服务器返回SWF文件。 当用户和你的应用交互时,SWF可向Facebook服务器、或你的服务器发送异步请求。 SWF文件中的ActionScript脚本直接访问Facebook服务器(步骤7-8)。 你可以使用Google代码中的ActionScript3.0LibraryforFacebookPlatform。 出于FlashPlayer安全性的考虑,SWF文件只能从两类服务器获取数据: (1)提供SWF文件的服务器(这里即你的服务器); (2)有跨域策略文件(在文件中列出了SWF来源服务器)的服务器。 也就是说,若要你的SWF能直接访问Facebook服务器,Facebook服务器必须在跨域策略文件中开放了访问权限。 如果看过Facebook的跨域策略文件,你会发现它通过一个通配符,授予了来自任何服务器的SWF文件的访问权: 你的ActionScript访问Facebook服务器时,必须像前面非Flash的iFrame和FBML应用部分讲到的那样,传送应用APIKey和用于说明访问来自何处的签名信息。 利用ActionScript3.0LibraryforFacebookPlatform中的类可自动生成签名;为此,你只需向ActionScriptsession类的构造函数传入应用的APIKey和密钥。 但是,你不应在SWF文件以硬编码方式写入上述数据,因为SWF文件可用多种软件反编译。 相反,SWF应该在运行时向你的服务器发出请求(可HTTP或FlashRemoting方式),从而获得应用的密钥,接下来再传给ActionScriptsession类的构造函数,从而生成访问Facebook服务器时所需的签名。 记住,此签名由下列信息组成: 传递给Facebook服务器的URL参数、SessionKey(用户访问你的应用时分配)的MD5哈希串、应用的密钥等。 若需实现任何服务端处理功能(如在你的服务器上保存某些数据),可在ActionScript代码中通过远程过程调用方法实现(见步骤9-10)。 对于利用Flex构建的Flash平台应用而言,这些方法包括HTTP、WebService和FlashRemoting请求技术。 其中最便捷的方法当属FlashRemoting——它通过开源的二进制ActionMessageFormat(AMF)实现服务器和FlashPlayer间的数据交换。 当然,服务端代码在向客户端返回数据之前,可根据需要访问Facebook服务器(此点未包含在图3中)。 FlashFBMLFacebook应用 除了在iFrame中集成你的Flash应用,还可以通过FBML标签 swf>将其植入到FBML应用中。 在这种情况中,你的应用会由一或多个服务端页面组成;这些页面包含FBML(用于获取或展示Facebook形式的可视化内容、对话框和小控件)、不能通过简单的FBML标签实现的服务端API调用,以及包纳了你的Flash内容的 swf>标签。 FBML应用的好处是在访问Facebook提供的社会化特性时非常简单,向Facebook传送FBML标签,就可自动渲染为HTML内容。 而其不足,则是此处在多个地方编写表现层和逻辑层的代码更为复杂: SWF文件中、服务端页面中,以及发向Facebook服务器的FBML代码中(见图4)。 有关iFrame和FBML应用区别的更详细信息,请参看iFrame、FBMLFlashFacebook应用比较。 图4FlashFBMLFacebook应用 用户通过Facebook站点访问你的应用时,浏览器向Facebook服务器发送HTTP请求。 Facebook服务器向你的服务器发出请求——一般请求的是PHP、JSP或ColdFusion式的服务端页面。 在这种情况下,Session信息通过POST请求(而非iFrame中的GET请求)中的URL参数传递,那么,你的应用服务器就知道该请求来自Facebook、是哪个用户发出的请求了。 服务端页面执行时,可根据需要访问数据库和其他服务器,当然包括利用RESTAPI访问Facebook服务器。 API调用必须包含认证信息——包括在Facebook上注册应用时获得的APIKey、该调用的签名(通过传给Facebook方法的参数、用户请求你的应用时指定的Session的MD5哈希串生成)、应用的密钥和其他信息。 对于非Flash的iFrame和FBML应用来说,服务端页面通常可利用现成的代码库实现对Facebook的访问,以及生成签名。 因此对于所有FBML应用而言,用户浏览器的所有请求都是通过Facebook代理的,你的应用在请求Facebook服务器时,就没必要每次单独调用一个API;同时,诸如获得用户姓名、图片、生成对话框等等,都可以利用FBML标签实现。 Facebook服务器在将页面返回给用户浏览器前,会自动将FBML转换为HTML和JavaScript代码。 当然,不是所有功能都有标签支持的,比如要取得朋友的生日信息,还是得从你的服务器向Facebook发送对应的API调用请求。 ∙Facebook服务器将被请求数据返回给你的服务器,格式可为XML或JSON。 ∙你的服务器向Facebook服务器返回包括HTML/JS和FBML内容的页面。 ∙Facebook服务器向用户浏览器返回HTML/JS页面。 该页面包括了(用标签 swf>指定)对你的服务器上SWF文件的引用。 ∙用户浏览器向你的服务器请求内嵌在HTML页面中的SWF文件。 ∙你的服务器返回SWF文件。 ∙在用户和你的应用交互过程中,SWF可向Facebook服务器或你的服务器发出异步调用。 SWF中ActionScript代码直接访问Facebook服务器(见步骤9-10),这可利用宿主在Google代码上官方支持的ActionScript3.0LibraryforFacebookPlatform实现。 当然,Facebook必须通过跨域策略文件开放了访问权限,且API调用中传送了所需参数。 有关这部分的详细问题,前面的FlashiFrame应用中已有讨论。 若需实现任何服务端处理功能(如在你的服务器上保存某些数据),可在ActionScript代码中通过远程过程调用方法实现(见步骤11-12)。 对于利用Flex构建的Flash平台应用而言,这些方法包括HTTP、WebService和FlashRemoting请求技术。 其中最便捷的方法当属FlashRemoting——它通过开源的二进制ActionMessageFormat(AMF)实现服务器和FlashPlayer间的数据交换。 当然,服务端代码在向客户端返回数据之前,可根据需要访问Facebook服务器(此点未包含在图4中)。 独立FlashFacebook站点应用 图5描绘了独立的FlashFacebook站点应用的架构。 其主要区别是Facebook服务器不再代为处理全部浏览器请求。 另外,现在你还必须在客户端代码中用FacebookAPI或FacebookConnect处理用户的登录。 如果使用FacebookAPI处理登录,用户需在新的浏览器窗口中登录Facebook并返回到你的应用中。 为了避免在Facebook站点登录,为用户提供更无缝的登录体验,你可以使用FacebookConnect。 图5独立的FlashFacebook站点应用 当用户在你的站点上访问应用时,浏览器向你的服务器发送HTTP请求——请求一个HTML或任何服务端页面。 服务器返回包含了对你的SWF文件的引用的HTML/JS页面。 如果使用FacebookConnect,该HTML页面会包括部分用于初始化FacebookConnect的JavaScript代码(说明)。 用户浏览器向你服务器请求内嵌在HTML页面中的SWF文件。 你的服务器返回SWF文件。 SWF文件中的ActionScript代码直接异步请求Facebook服务器——方法是使用官方提供的ActionScript3.0LibraryforFacebookPlatform。 你每次可以提交单独一个调用,也可以提交成批调用。 在这种情况下,最初对Facebook服务器的调用必须获得授权;一旦用户成功登录(最好使用FacebookConnect),得到了SessionKey,那么后续所有FacebookAPI调用所需的签名就会由ActionScript3.0LibraryforFacebookPlatform的类生成。 当然,Facebook必须通过跨域策略文件开放了访问权限,且API调用中传送了所需参数。 有关此问题的更多信息,请参看前面在FlashiFrame应用部分的讨论。 Facebook服务器向你的Flash应用返回XML或JSON格式的数据,并由你的应用处理这些数据。 若需实现任何服务端处理功能(如在你的服务器上保存某些数据),可在ActionScript代码中通过远程过程调用方法实现(可以是HTTP、WebService和FlashRemoting)。 其中最便捷的方法当属FlashRemoting——它通过开源的二进制ActionMessageFormat(AMF)实现服务器和FlashPlayer间的数据交换。 若有必要,服务器可与Facebook服务器进行其他通讯。 你的服务器处理Facebook服务器返回的结果数据。 你的服务器将数据返回给用户浏览器中的Flash应用。 图5中,我们利用FlashRemoting和AMF交换数据,当然你也可用WebService、SOAP、HTTP实现文本或XML格式的数据交换。 FlashFacebook桌面应用 最后,让我们来讨论FlashFacebook桌面应用的架构。 基于Flash平台的桌面应用,就是AIR应用(这个地方请再斟酌一下)。 有关构建AIR应用的更多信息,请参阅AIR文档和AIR开发者中心。 FlashFacebook桌面应用(如图6)的架构,和前面讨论过的独立FlashFacebook站点应用非常类似,唯一的不同是此时不需要浏览器,SWF文件也存在于安装了AIR应用的用户本地计算机上。 图6FlashFacebook桌面应用 用户安装并运行AIR桌面程序。 SWF文件中的ActionScript代码直接异步请求Facebook服务器——方法是使用宿主在Google代码上官方提供的ActionScript3.0LibraryforFacebookPlatform。 你每次可以提交单独一个调用,也可以提交成批调用。 在这种情况下,最初对Facebook服务器的调用必须获得授权;一旦用户成功登录(最好使用FacebookConnect),得到了SessionKey,那么后续所有FacebookAPI调用所需的签名就会由ActionScript3.0LibraryforFacebookPlatform的类生成。 当然,Facebook必须通过跨域策略文件开放了访问权限,且API调用中传送了所需参数。 有关此问题的更多信息,请参看前面在FlashiFrame应用部分的讨论。 Facebook服务器向你的Flash应用返回XML或JSON格式的数据,并由你的应用处理这些数据。 若需实现任何形式的服务端处理功能(如在你的服务器上保存某些数据),可在ActionScript代码中通过远程过程调用方法实现(可以是HTTP、WebService和FlashRemoting)。 其中最便捷的方法当
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- a1 基于 Facebook Flash 平台 应用 架构 解析
![提示](https://static.bdocx.com/images/bang_tan.gif)