In this chapter, we will cover:
Setting up a new application on Facebook
Downloading the Facebook ActionScript 3 SDK
Including the Facebook ActionScript 3 SDK in a Flash Builder project
Including the Facebook ActionScript 3 SDK as a Flash Builder library project
Preparing your Flash Player application's HTML template for Facebook integration
All third-party systems that work with data from Facebook do so through the Facebook API, which is a combination of REST-style techniques, OAuth 2.0, and an ever-evolving combination of web technologies, collectively titled by Facebook as the Graph API.
Facebook provides developers with a number of different code libraries through its developer portal, and of these the only one that's completely client-side is the JavaScript SDK. But anything that JavaScript can do can be done by both ActionScript 3 and the Flash Platform, more or less.
You might think, having looked at the SDKs officially listed by Facebook in their developer portal, that you'd need to build a code library yourself but luckily for us, there's already an existing, officially supported, ActionScript 3 library for working with the Graph API. This library, the Facebook ActionScript 3 SDK, is supported by both Adobe and Facebook, so you can be assured that it will be kept up-to-date and fully functional, even if there is a significant overhaul of the Facebook APIs—after all, who better to support this SDK than Adobe and Facebook themselves?
There's no sense in recreating the wheel, as they say, so the examples in this cookbook will be using the existing Facebook ActionScript 3 SDK almost exclusively for its recipes. We'll also be using the Flex SDK 4.0 for our examples, as it's a quick and easy way to construct user interfaces and put together working prototypes for our recipes. However, using Flex isn't a requirement for the Facebook ActionScript 3 SDK to work—it's just for the examples in this Cookbook. Integrating the Facebook SDK with a normal ActionScript-only project or a Flash Professional-based project is entirely possible—it will just inevitably require a little more time creating the interface, but the ActionScript 3 code behind it all will work pretty much the same.
In this chapter we'll be getting ready to start developing with Facebook—we'll download the Facebook ActionScript 3 SDK, integrate that SDK with our Flash Builder workspace, set up our application on Facebook.com, and generally get everything set up that we need to before we can start communicating with the Facebook APIs.
To access the full range of data available from the Facebook API, you need an API key, and for that, you need to set up an application on Facebook itself. To do this you need to set up an account on Facebook, and use that account to join the Facebook developer program.
Every Facebook application, whether it's based on server-side languages (like PHP), or client-side technologies (like JavaScript or ActionScript), needs an API key to send and receive data through the Facebook API. Alongside the API key, the application also gets a unique Application ID that makes it possible for Facebook to keep track of what actions a user has allowed your application to perform with their data, and an Application Secret, which is used for authentication.
As well as giving you the ability to use more features of the API, setting up your Flash project as an application and promoting it through Facebook greatly improves the chance that users will discover your application organically through the social network. For example, status updates created by your application will all link back to the application's Fan Page.
In this section, we're going to go through the necessary steps to register a new application on Facebook, and what we actually need is the API Key, Application ID, and an Application Secret for Flash.
You can set up your application as soon as you're registered as a developer with Facebook. To register as a developer you first need a Facebook profile. You've probably already got one, but you'll probably want to create at least one other Facebook account for development or testing purposes. I'm sure your existing Facebook friends won't appreciate a wave of "test message" spam in the near future.
Once you've logged in with the Facebook account you want to use for development, go to URL: http://www.facebook.com/developers/ to add the Facebook Developer application to your profile.
From the Facebook Developer center you can see the latest news from the Facebook developer blog, as well as useful links for developers (Documentation, Privacy Polices, Rules, and so on).
Click on the link + Set Up New App or go to the following website address: http://www.facebook.com/developers/createapp.php to start the application setup process.
If you just want to get up and run as fast as possible, the minimal amount of data that's needed to register a new application is its name.
Note
Your application name does not need to be unique—even for yourself. It's acceptable to name two (or more!) of your applications exactly the same, as Facebook assigns every application its own unique Application ID. Good thing to, really—otherwise all the good names would likely be taken in a frantic bout of application name-squatting.
There's far more information you can add, such as application icons, description, contact e-mail addresses, and support URLs—all pretty simple stuff, and you can always return to the settings screen to change or update things later on.
Once you've entered your application name (and any other information you wish) save your changes and you'll get a screen containing the following information:
Now that we've got ourselves an API Key, we can start using it in requests to the Facebook Graph API. We'll also need the Application ID, so make a note of that, but the Application Secret is something we don't actually need for any of the recipes covered in this cookbook.
All applications that integrate with Facebook aren't actually part of Facebook; they're an external application, and that's true for every third-party application that you might have seen appear within the Facebook interface (these are known as Canvas or Tab applications, depending on whether they're on their own page, or a Tab on another page). Technically, they are external websites that are loaded into the Facebook interface using an iframe element in HTML.
Without the API Key an application can't do anything other than retrieve the information that is publicly available. All other actions—such as requesting news feeds or publishing information to Facebook require—the end user to give your application the explicit permission to perform that action, with the API Key being what the Graph API relies upon when generating access tokens and authorizing requests.
Our application can request new permissions at any point, and similarly the end user can modify or reject our application permissions at any point, so generating an access token and passing it in all data requests is an easy way for Facebook to maintain the user's control over their data access.
To get a broader overview of the settings that can be changed for a Facebook application, the best place to look is the Developer Documentation, which is available online on the Facebook Developer center: http://developers.facebook.com/docs/.
There's no single page which gives a description of the settings, but rather the information is distributed around the pages where it's actually relevant.
When we set up an application on Facebook, it also sets up a Profile Page specifically for that application—similar to a Facebook page (but not exactly the same)—and devoted to our new application.
There are two ways to get the source code for the Facebook ActionScript SDK—one is simply download a precompiled version of the source code, and for that all you need is an Internet connection.
The other way to obtain the source code is to download the very latest version directly from a source control repository.
There are in fact two main versions of the Facebook ActionScript 3 SDK. One is the 'Official' version of the SDK, hosted in a Subversion repository on Google code, maintained and updated by teams associated with Adobe and Facebook; and the other is more of a community-driven effort, stored in a Git repository and hosted on GitHub.
In this recipe and all of the recipes in this Cookbook, we will be working with a branch of the community-driven version of the Facebook ActionScript 3 SDK, rather than the 'Official' version of the SDK.
To download the SDK from Git, we need to have Git installed on your computer, which can be downloaded and installed from the URL: http://git-scm.com/.
1. If you have no desire to work with code which includes version-control information, both the precompiled SWC files and the raw ActionScript source code for the Facebook ActionScript 3 SDK can be downloaded from the following URLs:
2. Within the pages at these URLs, select the Downloads button that appears in the top-left of the page, and you'll get popup containing the download options:
3. To download the raw ActionScript files, select the Download .zip option—listed under the DOWNLOAD SOURCE heading—or to download the precompiled SWC file, select the Facebook Web SDK.swc (or the Facebook Desktop SDK.swc) file—listed under the DOWNLOAD PACKAGES heading.
4. Alternatively, if you have Git installed, you can clone the entire repository, including its past history and references to its original source location, with the following command-line statement:
git clone git@github.com:psyked/facebook-actionscript-api.gitor
git clone git@github.com:psyked/facebook-air-api.git
This command will create a new folder with the name 'facebook-actionscript-api' and within that, create three key folders—docs, examples, and src. Unsurprisingly, these folders contain the source code for the library, the documentation for the library, and several sample applications, respectively.
The download locations for this recipe, and the source code for the Facebook SDKs which form the backbone of the recipes in this cookbook, point to Git repositories which are hosted by GitHub.
The source code for this repository is itself originally based on the official version of the SDK which is hosted on Google code, but it has been extended and expanded by other developers, (primarily Mark Walters, of http://yourpalmark.com/). The advantage of using our community-driven version of the SDK over the official one is that the source code is traditionally updated much more frequently, and includes a wide array of value-object classes, which the official version of the SDK does not yet include.
Not sure which version of the SDK is best for your project?
In addition to the different download options, there are also two different versions of the Facebook ActionScript 3 SDK, and the one which we will use depends on whether we're building desktop applications that run in Adobe AIR, or browser-based applications that use the Flash Player.
Both versions of the SDK are available for download from GitHub, but you can only use the Adobe AIR libraries with an Adobe AIR project, and the web-based libraries will only work properly with a web-based Flash Builder project that has the Facebook JavaScript SDK included in the HTML template, which is what we'll look at in the next recipe, Preparing your Flash Player application's HTML template for Facebook integration.
There's nothing 'magical' about this Facebook ActionScript API—everything it can do is built on standard capabilities of ActionScript 3 and the Flash Player. If you wanted to, it's entirely possible to write your own code that works with Facebook without using this library, but why, as mentioned in the introduction, should you re-invent the wheel?
That doesn't mean that the official API isn't subject to an occasional change—the move by Facebook to the 'Open Graph' in 2010 is evidence of that—but it does mean that there's always going to be someone maintaining the project and making sure it works with the latest version of the Facebook API.
Your situation, experience, personal preferences and the complexity of your final project dictate exactly how you'll integrate the Facebook ActionScript 3 SDK into your project. In this recipe we're going to use the precompiled SWC files that we've downloaded in our earlier recipe, Downloading the Facebook ActionScript 3 SDK, and integrate them with a new Flash Builder project.
Within your project structure you will, by default, have a libs folder. Copy your downloaded SWC file into that folder, and at a basic level, that's all there is to it.
The classes from the Facebook ActionScript 3 SDK will now be available to your project—you should get auto-complete code suggestions as you type, and more importantly, be able to compile your code!
An SWC file is a compiled set of source files—which could be ActionScript source code or symbols and images—and is a useful way of making your source code available for others to use, while still protecting the actual original code. Anyone with the SWC can get access to the classes it contains and all their properties and methods, but can't actually see the code behind those methods. Of course, protecting the code isn't a huge concern for the Facebook ActionScript 3 SDK, as we can get all of the source code from other sources anyway.
The great thing about using a SWC file is that it minimizes the clutter of source files in your project—you don't need to include anything more than the SWC, whereas if you wanted to use the actual source files, you'd need to add 20-odd additional ActionScript files. That might not sound bad, but when you start using the source-code versions of multiple ActionScript libraries, you can easily end up with 10, 20, 50, or more ActionScript files that aren't actually written by you for this project.
Another little plus with SWC files are that they're precompiled, which theoretically means lower compile times for your project. I don't think it actually makes much of a difference for this SDK, but every little bit helps I guess!
What about the downsides of SWC files? Well, the main downside of a SWC file is also partially the reason it exists—that you can't see the actual source code. If you want to browse through the source code, but still get the advantages of using a SWC file in your project, follow the next recipe Including the Facebook ActionScript 3 SDK as a Flash Builder library project.
If you're using a SWC exclusively then you'll be flying blind if you should trigger errors on the classes you don't have the source code for, and will be presented with a dialog similar to this:
Informative, but really not helpful when you're trying to find out where your code is breaking down. Luckily there's a solution for that, and it is by linking source files to an included SWC.
Of course, when it comes to Runtime Errors, it's more likely that the error is in your code, rather than the Facebook ActionScript 3 SDK. Linking to the source is more about helping you find and debug your own errors, rather than searching for errors in the SWC.
Before we start out, it's important to note that linking source files to an included SWC file doesn't actually have any effect on the SWC itself. Instead, what we're doing is giving Flash Builder the location of the SWC's source files.
When Flash Builder tries to open your project in debug mode it will use this information, but it won't magically enable Flash Builder to recreate the SWC file for you—for that you need to set up the code as a Flash Builder library project (which is, coincidentally, the subject of the next recipe).
Once you've downloaded the Facebook ActionScript 3 SDK source files, place them in a sensible location somewhere on your computer—it doesn't matter where exactly, only that you remember the location.
Open your project preferences screen, and switch to the tab Flex Build Path and within that, Library path:
In the preceding screenshot, you can see the GraphAPI_Web_1_0.swc file, and underneath that you can see there is a Source attachment option—double-click on that to open a new window, labeled Edit Folder Path:
From this dialog you can select the location of the source files for the SWC. There won't be any visual confirmation whether the location you've selected is correct or not, but when you start coding or debugging, you should be able to explore the source code of the classes in the SWC, and see far less of the Code Navigation Error dialog.
An alternative to including the Facebook AS3 SDK in its precompiled SWC form is to set up the SDK as a Flash Builder library project.
The end result, as far as the compiler and the user are concerned, is no different, but our own way of developing, reusing, and exploring the code is a little simpler. And unlike the precompiled SWC files that can be downloaded from the GitHub repositories, by using a Flash Builder library project, we can make modifications to the source code.
Using a Flash Builder library project makes it easy to reuse the code in the library in multiple other projects, and for the remaining recipes in this cookbook we're going to be linking to the library projects that we set up in this recipe.
There are two versions of the Facebook ActionScript 3 SDK, and just as there are two versions of the precompiled SWC to download, we will also need to create two Flash Builder library projects. In this recipe we're going to cover setting both of these library projects up and linking to these library projects from other projects.
1. Create a new library project in Flash Builder, using the basic Flex SDK only (don't include the Adobe AIR libraries), and call it Facebook Web SDK.
2. Copy the files and folders from the downloaded facebook-actionscript-api folder to the root folder of our project, setting up the following folder structure:
That will create a library project which we can use in basic Flash Player-based web projects. Next, we'll create a project that gives us the Adobe AIR version of the SDK.
3. Keep the Facebook SDK Web project open, and create a new Flash Builder library project; call it the 'Facebook Desktop SDK', only this time, be sure to include the Adobe AIR libraries in your project.
4. As with the web version of the SDK, copy the files you've downloaded from the facebook-air-api folder into our new library project, creating the following folder structure:
Not much to see in terms of source code, is there? Unlike the web version of the SDK, the desktop version isn't completely standalone; it relies on core classes from the web project—so what we need to do now is add the web project to the desktop project as a linked library.
5. Open your project preferences, go to the Flex Library Build Path and then the Library path' tab, then click Add Project... and select the Facebook Web SDK project.
Once the web project is added as a library for the desktop library project, both of those projects should be able to compile, and that's it for this recipe.
The complexity in this setup is just realizing that the Desktop version of the SDK is not a standalone library, and does, in fact, require all of the code from the web version. The source code files aren't duplicated for both versions because that would make things more complex to manage, and rather than merging the two sets into a single library project, we have to set things up in a way that keeps all of the AIR-specific source code in its own project.
Both versions of the Facebook ActionScript 3 SDK—Web and Desktop—rely on a core set of classes. The source code for the web version of the library contains all of these classes, whereas the desktop version of the library contains only the classes that require the AIR libraries, which is why it needs to be set up like this—to inherit those core files from the web project.
The original release version of the Graph API—version 1.0—included an additional JavaScript file—the FBJSBridge.js file. Since version 1.5 of the SDK there's no need for this additional JavaScript file—the Facebook ActionScript 3 SDK works to inject the original contents of that file into the containing HTML page, removing the necessity for those additional files, leaving only the ActionScript SDK as a requirement.
Before our web-based application will be able to work with the Facebook Graph API, it will need the Facebook JavaScript SDK to be included in the host HTML page, and it will have to be hosted on a domain or subdomain specified in our Facebook Application settings.
The Facebook JavaScript SDK is what makes it possible for our Flash Player application to obtain details of any active Facebook sessions, and it allows our application to perform actions such as prompting for authentication or requesting additional permissions.
In this recipe we will be extending our web project's default HTML template file to include the Facebook JavaScript SDK. In addition, we also have some more settings to change for our application in the Facebook Developer center—setting up the online Canvas or Tab page URLs, as well as the domains and subdomains which are allowed to access the Graph API.
For our Flash Player application to integrate with Facebook, we will need some form of HTTP server, so that we can run our application from an http://-based URL, rather than simply launching a file from a local folder on your computer. Ideally we need a live, publicly-accessible domain under our control, and we'll configure our Facebook Application to use pages on that domain as the basis for our Canvas and Tab applications.
In addition, if we can, it would be most efficient (but not essential) to have an HTTP server set up on our local machine—allowing us to test and debug our Flash Player applications locally, without having to re-upload files to a remote site every time we need to test new functionality.
1 The first thing we'll need is a web-based Flash Player application, which we can get by specifying Web (runs in Adobe Flash Player) when we create our Flex project:
2. Open the folder in your project named html-template. If that folder doesn't exist, open your project settings, and make sure that the option Generate HTML wrapper file under the Flex compiler section is checked.
Note
Downloading the example code for this book
You can download the example code files for all Packt books you have purchased from your account at http://www.PacktPub.com. If you purchased this book elsewhere, you can visit http://www.PacktPub.com/support and register to have the files e-mailed directly to you.
3. The first change we're going to make to our file is to import the Facebook JavaScript SDK. Into the head section of the HTML page (between the opening
<head>and closing</head>tags) add the following code:<script type="text/javascript" src="http://connect.facebook.net/en_US/all.js"></script>
4. This script tag imports the JavaScript SDK into our HTML page, but to activate it we need to add a specific HTML element—a div element with a specific ID. Jump to the bottom of the page, before the penultimate closing tag,
</body>, and add a new DIV element, with the ID of fb-root:<div id="fb-root"></div>
5. With these additions, our final HTML code for the entire page template should be similar to this (with our additions to the HTML highlighted):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!-- saved from url=(0014)about:internet --> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <title>${title}</title> <style type="text/css" media="screen"> html, body { height:100%; } body { margin:0; padding:0; overflow:auto; text-align:center; background-color: ${bgcolor}; } #flashContent { display:none; } </style> <script type="text/javascript" src="swfobject.js"></script> <script type="text/javascript"> var swfVersionStr = "${version_major}.${version_minor}.${version_revision}"; var xiSwfUrlStr = "${expressInstallSwf}"; var flashvars = {}; var params = {}; params.quality = "high"; params.bgcolor = "${bgcolor}"; params.allowscriptaccess = "sameDomain"; params.allowfullscreen = "true"; var attributes = {}; attributes.id = "${application}"; attributes.name = "${application}"; attributes.align = "middle"; swfobject.embedSWF( "${swf}.swf", "flashContent", "${width}", "${height}", swfVersionStr, xiSwfUrlStr, flashvars, params, attributes); swfobject.createCSS("#flashContent", "display:block;text-align:left;"); </script> <script type="text/javascript" src="http://connect.facebook.net/en_US/all.js"></script> </head> <body> <div id="flashContent"> <p>To view this page ensure that Adobe Flash Player version ${version_major}.${version_minor}. ${version_revision} or greater is installed.</p> </div> <div id="fb-root"> </div> </body> </html>6. These additions are all we need to attempt communication with the Graph API from a technical point of view, but before our API requests are successful, we must make sure that our application is configured correctly on Facebook.com.
8. Edit our existing application, and switch the Web Site tab, which contains two key fields—Site URL and Site Domain:
9. Our Site URL will be the location of our application when we upload it to a publicly-accessible HTTP server, and should be expressed as an URL (starting with
http://).10. The Site Domain (expressed without the
http://prefix) allows us to control the domain and subdomains that are allowed to access the Graph API, while identifying as our application. Once this property is set, only requests that appear to come from that specified URL (or part URL) will be allowed to make requests, and all others will be summarily rejected by the Graph API with the error message:Given URL is not allowed by the Application configuration.
11. Change the Site URL property to point at our Flash application's live location, such as: http://facebook.psyked.co.uk/packt/.
12. Change the Site Domain property so that it lists the main domain of our application's live location, for example: psyked.co.uk.
13. Now, with the Site's URL and Domain settings established, our next step should be to upload our application and its HTML files to the location we've specified in the Site URL field. Once those files are uploaded and available from the domain we specified in the Site Domain field, we should see no more of those Given URL is not allowed... errors.
14. Finally, to test our application we will need to upload our HTML and SWF files to a live web server—one that is able to serve up our application's HTML file from within the domain that we specified in the Site Domain setting in the Facebook Developer center. For example,
http://psyked.co.uk/packt/Facebook.html.
The web-based version of the Facebook ActionScript 3 SDK has been developed with a reliance on the Facebook JavaScript SDK being included in the containing HTML page—hence the requirement for us to extend our HTML template to incorporate this SDK.
When we add the script tag to our HTML template—using the URL http://connect.facebook.net/en_US/all.js as the source location—we are importing the Facebook JavaScript SDK from the Facebook.com servers. There are a few fringe benefits to loading the JavaScript SDK in this way—it keeps the SDK up-to-date and it helps with caching resources, but the primary reason for loading the SDK from the Facebook.com domain, rather than downloading it and packaging it alongside the HTML and SWF files on our own servers, is that this avoids a lot of potential for cross-domain scripting issues, and makes domain-restricted information such as cookies available to our application.
The addition of an HTML element with an ID of fb-root is part of the basic requirements for the JavaScript SDK, which are also discussed in more detail in the Facebook Developer documentation:
http://developers.facebook.com/docs/reference/javascript/
In short, the JavaScript SDK needs an actual element on the HTML page to hook into, and that element is one with an ID of fb-root—which is hardcoded into the SDK itself.
What we've done is in this recipe is simply to set up our project so that it will be able to work with the Facebook APIs, when it's uploaded to the domain that we've specified for our application, in the applications' settings, in the Facebook Developer center.
The Graph API automatically rejects requests that use our Application's API Key if those requests come from a domain other than the domain specified by the Site URL and Site Domain settings—which means that if we try to test our code using URLS like:
C:\Workspace\Facebook Example\bin-debug\Facebook.html
or
file://Users/Admin/Workspace/Facebook Example/bin-debug/Facebook.html
the Graph API would automatically reject requests originating from those URLs, because they're not on the domain specified in our Facebook Application settings.
In actual fact, trying to work with these URLs would likely throw a Security Sandbox Error from the Flash Player before things even got to the point of communicating with the Graph API. The ideal setup to avoid this is instead to have a HTTP server running locally that can deliver these same HTML files, but from an http:// protocol, such as:
http://localhost/Facebook%20Example/bin-debug/Facebook.html
This would avoid any Flash Player security issues, but requests to the Graph API would still be rejected, because the domain, localhost, is not the same as the domain specified in our application settings (in my case, psyked.co.uk).
To develop efficiently for Facebook, we should expect to be able to code and test frequently, without the constant need to upload and re-upload our Flash application to a remote domain, yet still have everything work as if our application were online at the domain outlined in the Site Domain setting we previously specified.
Note
To test our application locally, we must have an HTTP server installed and running on our computer, something like the Apache HTTP Server, which is available from: http://httpd.apache.org/.
Support for server-side languages isn't important for our needs—all we require is the ability to launch our Flash Player application from an http://-based URL, rather than a local or network path.
There are two approaches we can take to get a Project that we have running locally to work with the Graph API:
1. Adjust the Site Domain project setting to work exclusively with the domain
localhost.or
2. Use setup a subdomain (such as
localhost.psyked.co.uk) on our live website domain that points at our local machine.
Either of these solutions is valid—they both conspire to ensure that the Site Domain in our Facebook Application settings and the current URL that we're viewing match up.
If we choose the first option—adjusting our Site Domain property to say localhost—it should allow our local machine to work with Facebook, but at the cost of our live, publicly-accessible website not being able to communicate with the Graph API. Of course, that doesn't preclude us from setting up more than one Facebook application—a local development and live deployment application, if necessary.
The other alternative—using a subdomain—assumes that we can manage our top-level domain and create entries for new subdomains. All that is actually required for domain validation with the Graph API is that the computer on which the code is running believes that it is running on a specific domain—not that the domain is actually valid, or even that the domain even exists.
Thus we could create a new subdomain on our live website, such as localhost.psyked.co.uk, and have it point at the IP Address 127.0.0.1. For users without an HTTP server installed, they'll see nothing, and for developers like us, we'll see our own local HTTP server.
With our allowed domain effectively being *.psyked.co.uk the requests from localhost.psyked.co.uk will be accepted by the Graph API, and we can test our code much faster.
There are (currently) three main kinds of Facebook-enabled applications. These are:
This categorization represents the route by which users discover our application, as much as anything else. From a technical perspective, our application is always an HTML page, with a Flash Player application nested inside.
Canvas and Page Tab applications are actually HTML iframe elements on the Facebook.com website—they appear within the normal Facebook website interface, but the content that's being displayed comes from your own web server, and the same content is technically available from outside those iframe elements, if you have a direct link.
For example, we can have a Canvas application accessible from the URL:
http://apps.facebook.com/packt_facebook/
But the HTML source for this Canvas application is actually located at the URL:
http://facebook.psyked.co.uk/packt/
The integration of these two separate websites is seamless for the end user, but the context of each places different constraints on our application in terms of the dimensions of the application.
To set up our application so that it appears within the Facebook.com website as a Canvas or Page Tab we need to visit the Facebook Developer center and edit the settings of our Facebook Application, which we can do via the URL:
http://www.facebook.com/developers/apps.php
Select an application, click Edit settings, and then go to the Facebook Integration section, where you can make specific entries for the Canvas URL and Tab URL parameters—choosing exact URLs that point to an HTML page that would be formatted correctly for the dimensions of the iframes. Canvas applications are 760 pixels wide and Tab applications are only 520 pixels wide.
Not every application has to be a Canvas or Page Tab application, however. It doesn't even have to be an application on Facebook—it can just be one that interacts with Facebook, so long as our Flash application remains within the Site Domain boundaries we've specified in the Facebook Developer center.
If you are adding Flash elements to a Facebook application you've already developed in a server-side language, then you may find that you don't need to worry about adding additional JavaScript files to the mix.
Say for example you've already developed a Facebook login process; using Facebook's own PHP SDK, you could simply forget about including the JavaScript SDK and instead use FlashVars to pass in the session data and authorization tokens at the point the page is generated. Not only would you not need to load an additional JavaScript file, but you'd also not have to make duplicate session requests with Facebook, which should speed things up a little.
The key point is that Facebook cannot always know—and doesn't really care—how you're making requests to its APIs, only that you do so with valid authorization tokens and request parameters.