Flash Player Application's HTML Template for Facebook Integration

Exclusive offer: get 0% off this eBook here

— Save 0%

$0.00    $0.00
by James Ford | August 2011 | Cookbooks Web Development

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.

In this recipe by James Ford, author of Flash Facebook Cookbook, 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.

 

Flash Facebook Cookbook

Flash Facebook Cookbook

Over 100 recipes for integrating the Flash Platform applications with the Graph API and Facebook.

        Read more about this book      

(For more resources on this subject, see here.)

The reader will be benefit from referring the previous article on Getting Started with Flash and Facebook.

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.

Getting ready

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.

How to do it...

  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.

  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='//dgdsbygo8mp3h.cloudfront.net/sites/default/files/blank.gif' data-original="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='//dgdsbygo8mp3h.cloudfront.net/sites/default/files/blank.gif' data-original="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='//dgdsbygo8mp3h.cloudfront.net/sites/default/files/blank.gif' data-original="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.
  7. Open the Facebook Developer center, from the URL:

    http://www.facebook.com/developers/apps.php

  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.

 

        Read more about this book      

(For more resources on this subject, see here.)

How it works...

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.

There's more...

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.

Testing and debugging our Flash Builder project locally

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.

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.

Where can users access our Facebook application from?

There are (currently) three main kinds of Facebook-enabled applications. These are:

  1. Facebook Canvas applications
  2. Facebook Page Tab applications
  3. Websites with Facebook integration

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.

Setting up a Canvas or Tab application on Facebook.com

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.

Working without the JavaScript SDK?

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.

Summary

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.


Further resources on this subject:


Unpublished

n/a
Published: January 1970
eBook Price: $0.00
Book Price: $0.00
See more
Select your format and quantity:

About the Author :


James Ford

James Ford lives and works in the relatively sedate Midlands of England, and is constantly thankful that he doesn’t have to contend with public transport or large volumes of traffic on a regular basis. Occasionally being stuck behind a tractor for several miles is a small price to pay for that!

Macromedia Flash 8 represented his first serious interaction with a programming language, an epiphany whereupon his BA in Design for Interactive Media became far more focused on the Programming side of things than the Art (although it turned out okay).

He considers himself to be fortunate to have encountered the Flash Platform when he did, as during that time between first contact and today, the Flash Platform has evolved at just the right pace to enable him to keep up with the latest shiny new features.

In addition to developing Facebook-integrated Flash Player applications, James has also developed a few AIR applications, built a couple of Apps for iOS and Android devices, helped develop a load of websites, and blogs about all of this on his website: http://www.psyked.co.uk/.

Books From Packt


Facebook Graph API Development with Flash
Facebook Graph API Development with Flash

Facebook Application Development with Graph API Cookbook
Facebook Application Development with Graph API Cookbook

Flash Development for Android Cookbook
Flash Development for Android Cookbook

Flash iOS Apps Cookbook: RAW
Flash iOS Apps Cookbook: RAW

Flash Game Development by Example
Flash Game Development by Example

Flash 10 Multiplayer Game Essentials
Flash 10 Multiplayer Game Essentials

Flash Multiplayer Virtual Worlds
Flash Multiplayer Virtual Worlds

Learning Facebook Application Development
Learning Facebook Application Development


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
e
e
2
P
E
4
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software