The architecture of applications built on the Flash and Facebook Platforms

Introduction

The Flash Platform lets you build rich, user experiences. The Facebook Platform lets you build rich, social experiences. Put the two together, and you can build killer applications incorporating social capabilities in highly interactive, expressive, and responsive applications.

This article introduces you to the architecture of applications built using the Flash and Facebook Platforms. It provides an overview of the different types of applications you can build and how the applications communicate with your server and Facebook.

Be sure to also read the article, The technologies for building applications on the Flash and Facebook Platforms.

You can build four types of Flash Platform applications to integrate with Facebook: applications on Facebook, external web applications, desktop applications, and mobile applications.

• Applications on Facebook.com are web applications that are hosted on your own server but which users access from the Facebook website. The user sees the Facebook chrome with your application inside of it. You visit an application on Facebook (often by either responding to a friend's invitation or by following a link when searching for an application) and the Facebook server proxies the request to your server and retrieves an application page (containing HTML and JavaScript that embeds the Flash Platform application) to display on the Facebook website. This provides a seamless experience to users when they are on the Facebook website; users never leave the Facebook website. The Flash Platform application retrieves and/or sends data back and forth to Facebook using the Adobe ActionScript 3 SDK for Facebook Platform, which is a wrapper for the Facebook Graph API. Example applications include Who Has the Biggest Brain from Playfish and Zynga's Texas Hold'em Poker.
• External web applications are also hosted on your own server, but users access them through your URL, not through the Facebook website. You add Facebook social features to the application by adding single sign-in and sign-out for the application and Facebook using the Adobe ActionScript 3 SDK for Facebook Platform in conjunction with the Facebook JavaScript SDK. You add login and logout buttons in the application and when a users log in, she gets the Facebook login and/or application authorization dialog as appropriate in a pop-up widow. A popup window is necessary for security reasons so the user knows she is logging into Facebook. This single sign-in with Facebook lets you streamline your application's login process and gives it access to a user's profile, letting you personalize the website (by displaying the user's name, picture, and so on) and the user's experience (by showing products friends purchased, displaying friends comments or reviews, posting comments or reviews to a user's wall and friend's new feeds, and more). Just as for applications on Facebook.com, the Flash Platform application retrieves and/or sends data back and forth to Facebook using the Adobe ActionScript 3 SDK for Facebook Platform, which is a wrapper for the Facebook Graph API. Example web sites include Ben and Jerry's, RedBull Connect, and City Search.
• Desktop applications are similar to external web applications except that you deploy your Flash Platform application as an AIR application to the desktop instead of hosting it on a web server. Like external websites, desktop applications use the Adobe ActionScript 3 SDK for Facebook Platform to add login functionality and social features from Facebook. Example applications include Seesmic for Facebook and Nomee.
• Mobile applications are like desktop applications except you deploy them to a device instead of the desktop. Just as for the other types of applications, they use the ActionScript 3 SDK for Facebook Platform to add login functionality and social features from Facebook. An example application is Zynga's Farmville.
  

When a user requests an application on Facebook.com (for example, http://apps.facebook.com/someapp/), Facebook returns a Facebook web page with the Facebook chrome that contains an iFrame into which your application is loaded (see Figure 1).

1. The user requests your application while on the Facebook website; the browser makes an HTTP request to Facebook.
2. The Facebook server returns an HTML/JavaScript (JS) page containing the Facebook website chrome and an iFrame HTML tag.
3. The user's browser makes a request to your server for the page to display inside the iFrame. This is usually an application server page (for example, PHP, ColdFusion, or JSP) but it can also be an HTML page. This page should contain logic checking to see if the user is logged in to Facebook. When a user logs in to Facebook, session data is stored in a cookie called fbs_applicationID, where the application ID is the ID assigned to the application when it is registered with the Facebook Developer application. The cookie contains a variable called access_token that you retrieve and then pass with all subsequent calls to the Facebook Graph API.  If the user is not logged in to Facebook, i.e. the cookie does not have an access_token property, the browser should be redirected to the appropriate Facebook login page.
4. The application server page is executed, making any calls to databases or other servers as needed, including calls to Facebook using its Graph API. Each API call must include the access token retrieved from the session cookie.
5. Facebook returns the requested data to your server as JSON formatted data.
6. Your server returns an HTML/JS page to the user's browser that is displayed in the iFrame.

As the user interacts with your application, several things may occur:

• If your application contains links to new server-side pages, steps 3–6 are repeated.
• Alternatively, your application may contain asynchronous JavaScript calls to your server. In this case, steps 7–10 in Figure 1 are executed with the only difference being that JSON is returned to the user's browser to be processed by the page's JavaScript.
• Another option is for the JavaScript code in your page to directly make calls to the Facebook server using the Facebook JavaScript SDK instead of having to go through your application server (steps 11–12 in Figure 1).

Note: You can also place a small set of FBML tags in your application that work in conjunction with the JavaScript SDK which scans the DOM for the tags and then sends the API requests to Facebook.

Now that we have covered the basics of non-Flash Platform applications on Facebook.com, let's take a look at integrating Flash Platform content into your application (see Figure 2).

1. The user requests your application while on the Facebook website; the browser makes an HTTP request to the Facebook server.
2. The Facebook server returns an HTML/JS page containing the Facebook website chrome and an iFrame HTML tag.
3. The user's browser makes a request to your server for the page to display inside the iFrame. As before, this is either an HTML page or an application server page but now this page also embeds a SWF file, the Flash Platform application.
4. Your server returns an HTML/JS page to the user's browser, which is displayed in the iFrame. This page must still contain logic checking to see if the user is logged in to Facebook, but now this check can be done in the embedded SWF using the Adobe ActionScript 3 SDK for Facebook Platform. The application contains code to check for the existence of an access token. If there is no access token, you must add code to redirect the user to the Facebook login page as before.
5. The users' browser makes another request to your server, this time for the SWF to embed in the HTML page in the iFrame.
6. Your server returns the SWF file.
7. As the user interacts with the application, it makes asynchronous calls to Facebook using the Adobe ActionScript 3 SDK for Facebook Platform. Every API call must include the access token; this is handled automatically by the SDK.

Due to security restrictions of Flash Player, SWF files can only make data calls to the server from which the SWF file was served (that is, your server) or to servers that have a crossdomain policy file listing the server that the SWF file came from. This means that for your SWF file to make calls directly to the Facebook server, the Facebook server must have a crossdomain policy file giving SWF files from your server access. If you take a look at the Facebook cross-domain policy file, you will see a wildcard entry granting access to SWF files from all servers.

8. Facebook returns JSON data to the application.
9. As the user interacts with the application, it can also make asynchronous calls to your server (to save any data on your server or do any other server-side processing) using typical remote procedure call methods. For Flash Platform applications built with Flex, this includes HTTP, web service, and Flash Remoting requests. The quickest and smallest calls result from using Flash Remoting, which uses the open-source binary protocol Action Message Format (AMF) to exchange data between the server and Flash Player.
10. If the server needs to talk to Facebook for any reason, it does.
11. Your server-side code handles results from Facebook.
12. Your server returns any data to your Flash Platform application in the user's browser. 

External Flash and Facebook Platform web applications (see Figure 3) are very similar to web applications on Facebook.com. The main difference is how you handle user login and application authorization. Instead of simply redirecting the browser to Facebook login and/or authorization pages, you use the Facebook JavaScript SDK in conjunction with the Adobe ActionScript 3 SDK for Facebook Platform to display the Facebook login and/or authorization pages in a pop-up window. Although the Facebook login is handled with JavaScript, you usually don't need to write any JavaScript code; you just call methods of classes in the Adobe ActionScript 3 SDK for Facebook Platform. Internally what happens is that code in the ActionScript SDK (specifically methods in the facebook.graph.core.FacebookJSBridge class) calls methods of the Facebook JavaScript SDK. The wrapper page for the application must include the Facebook JavaScript SDK.

1. The user requests your application on your website; the browser makes an HTTP request to your server. This request is for an HTML page or any application server page but will just be referred to as the HTML page from here on.
2. Your server returns an HTML/JS page embedding your SWF file. The wrapper page must include the Facebook JavaScript SDK whose methods are called by some of the methods in the Adobe ActionScript 3 SDK for Facebook Platform.
3. The users' browser makes a request to your server for the SWF file to embed in the HTML page.
4. Your server returns the SWF file. The application uses the Adobe ActionScript 3 SDK for Facebook Platform code (which calls methods of the Facebook JavaScript SDK) to check and see if there is a current access token for this user and application. If there is not, it presents the Facebook login and/or authorization web page in a pop-up browser window.
5. As the user interacts with the application, it makes asynchronous calls to Facebook using the Adobe ActionScript 3 SDK for Facebook Platform. Every API call must include the access token (this is handled automatically by the SDK) and the Facebook server must have a crossdomain policy file giving SWF files from your server access (which it does).
6. Facebook returns JSON formatted data to your application and your application handles the data.
7. If you want to save any data on your server or do any other server-side processing, your ActionScript code can make calls to your server using typical remote procedure call methods (HTTP, web service, and Flash Remoting requests).
8. If the server needs to talk to Facebook for any reason, it does.
9. Your server-side code handles results from Facebook.
10. Your server returns any data to your Flash Platform application in the user's browser. 

Next, let's look at the architecture of Flash and Facebook Platform desktop applications (see Figure 4). Desktop applications are very similar to external Flash and Facebook Platform web applications, except that the SWF lives on the user's computer after the user installs the application and login is handled solely by the Adobe ActionScript 3 SDK for Facebook Platform. To deploy a Flash Platform application as desktop application, you create an AIR application for users to install.

1. The user installs and opens your AIR desktop application. The application uses the Adobe ActionScript 3 SDK for Facebook Platform code to check and see if there is a current access token for this user and application. If there is not, it presents the Facebook login and/or authorization web page in a new operating system window.
2. The ActionScript code in your SWF file makes asynchronous calls directly to Facebook using the Adobe ActionScript 3 SDK for Facebook Platform. The access token is automatically passed with each API call.
3. Facebook returns JSON formatted data to your application and your application handles the data.
4. If you want to save any data on your server or do any other server-side processing, your ActionScript code can make calls to your server using typical remote procedure call methods (HTTP, web service, and Flash Remoting requests).
5. If the server needs to talk to Facebook for any reason, it does.
6. Your server handles results from Facebook.
7. Your server returns any data to the Flash Platform desktop application. 

Flash and Facebook mobile applications are like desktop applications; the application lives on the user's device after the user installs the application and login is handled solely by the Adobe ActionScript 3 SDK for Facebook Platform. On Android and Blackberry Tablet OS devices, the application is deployed as an AIR application (see Figure 5).

1. The user installs and opens your mobile application. The application uses the Adobe ActionScript 3 SDK for Facebook Platform code to check and see if there is a current access token for this user and application. If there is not, it presents a Facebook login or authorization screen.
2. The ActionScript code in your SWF file makes asynchronous calls directly to Facebook using the Adobe ActionScript 3 SDK for Facebook Platform. The access token is automatically passed with each API call.
3. Facebook returns JSON-formatted data to your application and your application handles the data.
4. If you want to save any data on your server or do any other server-side processing, your ActionScript code can make calls to your server using typical remote procedure call methods (HTTP, web service, and Flash Remoting requests).
5. If the server needs to talk to Facebook for any reason, it does.
6. Your server handles results from Facebook.
7. Your server returns any data to the Flash Platform desktop application.

For deployment on iOS devices, the AIR application must be converted to a native iOS application using Flash Builder 4.5 or later or Flash Professional CS5 or later and then deployed (see Figure 6).

This article presented architecture diagrams and process flows for non-Flash Platform applications on Facebook.com, Flash Platform applications on Facebook.com, external Flash and Facebook Platform web applications, Flash and Facebook Platform desktop applications, and Flash and Facebook Platform mobile applications..

For detailed steps on creating a Flex and Facebook application that is deployed as either a desktop application, an external web application, or an application on Facebook.com, complete the tutorial series Create your first Flex and Facebook application.