Ready to start learning how to develop Flash Facebook applications? You will be in a few pages.
In this chapter, we will:
Learn what the big deal is about Facebook, and why you should be interested in developing an application for it
Get you set up with a web host, which you'll need for developing any online Facebook application
Establish how much AS3 you need to know already, and what to do if you don't
Take a quick look at the project that you'll be building throughout most of this book
Find out how to deal with the debugging complications that arise when developing a "browser-only" application like this
So let's get on with it...
Seems like everyone's on Facebook these days—people are on it to socialize; businesses are on it to try to attract those people's attention. But the same is true for other older social networks such as LinkedIn, Friendster, and MySpace. Facebook's reach goes far beyond these; my small town's high street car park proudly displays a "Like Us On Facebook" sign.
More and more Flash games and Rich Internet Applications (RIAs) are allowing users to log in using their Facebook account—it's a safe assumption that most users will have one. Companies are asking freelancers for deeper Facebook integration in their projects. It's practically a buzzword.
But why the big fuss?
Facebook benefits from the snowball effect: it's big, so it gets bigger.
People sign up because most of their friends are already on it, which is generally not the case for, say, Twitter. Businesses sign up because they can reach so many people. It's a virtuous circle.
There's a low barrier to entry, too; it's not just for techies, or even people who are "pretty good with computers;" even old people and luddites use Facebook. In February 2010, the technology blog ReadWriteWeb published an article called "Facebook Wants to Be Your One True Login," about Facebook's attempts to become the de facto login system throughout the Web. Within minutes, the comments filled up with posts from confused Facebook users:
Evidently, the ReadWriteWeb article had temporarily become the top search result for Facebook Login, leading hundreds of Facebook users, equating Google or Bing with the Internet, to believe that this blog post was actually a redesigned Facebook.com. The comment form, fittingly, had a Sign in with Facebook button that could be used instead of manually typing in a name and e-mail address to sign a comment—and of course, the Facebook users misinterpreted this as the new Log in button.
And yet… all of those people manage to use Facebook, keenly enough to throw a fit when it apparently became impossible to use. It's not just a site for geeks and students; it has serious mass market appeal.
Even "The Social Network"—a movie based on the creation of Facebook—held this level of appeal: it opened at #1 and remained there for its second weekend.
According to Facebook's statistics page (http://www.facebook.com/press/info.php?statistics), over 500 million people log in to Facebook in any given month (as of November 2010). For perspective, the population of the entire world is just under 7,000 million.
Twitter is estimated to have 95 million monthly active users (according to the eMarketer.com September 2010 report), as is MySpace. FarmVille, the biggest game based on the Facebook platform, has over 50 million: more than half the population of either competing social network.
FarmVille has been reported to be hugely profitable, with some outsider reports claiming that its parent company, Zynga, has generated twice as much profit as Facebook itself (though take this with a grain of salt). Now, of course, not every Facebook game or application can be that successful, and FarmVille does benefit from the same snowball effect as Facebook itself, making it hard to compete with—but that almost doesn't matter; these numbers validate Facebook as a platform on which a money-making business can be built.
As the aforementioned ReadWriteWeb article explained, Facebook has become a standard login across many websites. Why add yet another username/password combination to your browser's list (or your memory) if you can replace them all with one Facebook login?
This isn't restricted to posting blog comments. UK TV broadcaster, Channel 4, allows viewers to access their entire TV lineup on demand, with no need to sign up for a specific Channel 4 account:
Again, Facebook benefits from that snowball effect: as more sites enable a Facebook login, it becomes more of a standard, and yet more sites decide to add a Facebook login in order to keep up with everyone else.
Besides login capabilities, many sites also allow users to share their content via Facebook. Another UK TV broadcaster, the BBC, lets users post links for their recommended TV programs straight to Facebook:
Blogs—or, indeed, many websites with articles—allow readers to Like a post, publishing this fact on Facebook and on the site itself:
So half a billion people use the Facebook website every month, and at the same time, Facebook spreads further and further across the Internet—and even beyond. "Facebook Messages" stores user's entire conversational histories, across e-mail, SMS, chat, and Facebook itself; "Facebook Places" lets users check into a physical location, letting friends know that they're there.
No other network has this reach.
With all this expansion, it's difficult for a developer to keep up with the Facebook platform. And sometimes there are bugs, and undocumented areas, and periods of downtime, all of which can make development harder still.
But the underlying system—the Graph API, introduced in April 2010—is fascinating. The previous API had become bloated and cumbersome over its four years; the Graph API feels well-designed with plenty of room for expansion.
This book mainly focuses on the Graph API, as it is the foundation of modern Facebook development. You'll be introduced to it properly in Chapter 2, Welcome to the Graph.
If you're not on Facebook already, sign up now (for free) at http://facebook.com. You'll need an account in order to develop applications that use it. Spend some time getting used to it:
Set up a personal profile.
Post messages to your friends on their Walls.
See what all the FarmVille fuss is about at http://apps.facebook.com/onthefarm.
Check in to a location using Facebook Places.
Log in to some blogs using your Facebook account.
Share some YouTube videos on your own Wall from the YouTube website.
"Like" something.
Go native!
If you've already got a publicly accessible web server or are signed up to a web host to which you can upload SWFs and HTML pages via FTP, skip to the How much AS3 knowledge is required? section.
I'll assume that you roughly know how the Internet works: when you type a URL into a web browser on your computer and hit Go, it retrieves all the pages and images it needs from another computer, the web server, and displays them. The exact methods it uses to find the web server and the protocols for how the information gets back to your computer aren't relevant here.
You could go out and buy a computer, install some server software, and hook it up to your Internet connection, and you'd have a functional web server. But you'd have to maintain it and keep it secure, and your ISP probably wouldn't be very happy about you sending all those pages and images to other people's browsers. A better option is to pay another company to take care of all of that for you—a web host.
In order to build an online SWF-based application or game that allows users to log in with their Facebook account (with the SWF being able to access their profile, list of friends, Wall, and so on), you will require control over a web page.
Technically, you could probably come up with some hack that would allow you to get around this—perhaps by hosting everything on Google sites and MegaSWF—but in the long run it's not going to be worth it. Splash out on a web host for the sake of learning; you will definitely need access to one if you do professional Facebook application development in the future.
There are a huge number of web hosts to choose from, and an even bigger number of configurable options between them. How much disk space do you need? How much bandwidth per month? How much processing power? Some hosts will give you a server all to yourself, while others will put your files on the same computer as other customers. And of course, you have to wonder how good the customer service is and how reliable the company is at keeping their servers online. Throw in a few terms such as "cloud hosting" and it's enough to make your head spin.
All you need is a host that allows you to upload HTML files and SWFs; this book also assumes that you'll be able to use FTP to transfer files from your computer to the host, though this isn't strictly necessary.
Want to just get started without wasting time comparing hosts? Go with Media Temple. The code in this book was all tested using a Media Temple Grid Service account, available at http://mediatemple.net/webhosting/gs/. It provides much more than what you'll need for completing the projects in this book, granted, and at $20/month. It's not the cheapest option available, but the extra service and features will definitely come in handy as you build your own Facebook applications and games.
You'll need an HTML editor for editing web pages. FlashDevelop and Flash Builder both do good jobs at this; otherwise, try:
Notepad++ for Windows (free): http://notepad-plus-plus.org/
Text Mate for Mac: http://macromates.com/
Komodo Edit for Mac and Windows (free): http://www.activestate.com/komodo-edit
And in order to transfer your files from your computer to your web host, you'll probably need an FTP client. Check out FileZilla (it's free and available for both Windows and Mac) at http://filezilla-project.org/. Documentation for this is available at http://wiki.filezilla-project.org/Documentation, and your web host will almost certainly provide instructions on connecting to it via FTP (Media Temple's instructions can be found at http://kb.mediatemple.net/questions/131/Using+FTP+and+SFTP)
Web hosts will generally assign you a very generic address, such as http://michaeljw.awesomewebhost2000.com/ or http://sites.awesomewebhost2000.com/michaeljw. If you want to have a more condensed personal address such as http://michaeljw.com/, you'll need to pay for it. This is called a domain name—in this specific example, michaeljw.com is the domain name.
Media Temple allows you to buy a domain name for $5/year at the point where you sign up to their web hosting package. If you go with another host, you may need to buy a domain name elsewhere; for this, you can use http://www.moniker.com/.
You don't need to own a domain name to use this book, though. The generic addresses that your web host assigns you will be fine. Throughout the book, it'll be assumed that your website address (either generic or domain name) is http://host.com/.
Pick a web host, get your credit card out, and sign up for one of their packages.
Create a new directory called
/test/in the public path of your web host.Create a new plain text file on your hard drive called
index.html. (It's a good idea to create a new folder on your computer to store all your work, too.) Open this file in your HTML editor.Copy the HTML below into the file:
<html> <head> <title>Test</title> </head> <body> <h2>Hello!</h2> </body> </html>Hopefully, you know enough HTML to understand that this just writes Hello! in big letters.
Transfer
index.htmlto the/text/directory on your host. Again, you'll probably need to use an FTP client for this.Open a web browser and type http://host.com/test/index.html into the URL bar. Of course, you should replace http://host.com/ with the path to your public directory, as given to you by your web host. You should see Hello! appear in a glorious default font:
If not, check the documentation and support for your host.
You'll need to know some AS3 before you start using this book. Sure, it's a "Beginner's Guide", but beginner refers to your knowledge of Facebook development, not Flash development!
All of the code in this book is written using classes inside AS files; there's no timeline code at all. You don't have to be an OOP guru to follow it, but you must be familiar with class-based coding. If you aren't, check out these two resources:
How To Use A Document Class In Flash—A short tutorial to get you up to speed with using document classes in Flash CS3 and above: http://active.tutsplus.com/tutorials/actionscript/quick-tip-how-to-use-a-document-class-in-flash/.
AS3 101—A series of tutorials to walk you through the basics of AS3 development. In particular, read from Part 8 onwards, as these deal with OOP in AS3: http://active.tutsplus.com/series/as3-101/.
You should also know how to create and compile a SWF project, and be familiar enough with HTML to be able to embed a SWF in it. We'll use SWFObject for this purpose (this is the default embed method used by Flash CS5); if you're not sure what this means, familiarize yourself here: http://code.google.com/p/swfobject/.
All important AS3 classes and keywords used in this book will be briefly explained as they become relevant, so don't worry if you haven't memorized the LiveDocs yet. Speaking of LiveDocs, remember that you can always use them to look up unfamiliar code: http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/index.html.
At the start of Chapter 2, Welcome to the Graph, you'll be given a Flash project that's just an empty user interface—it'll be up to you to build the backend using the lessons you learn from Chapters 2 through 6.
This project is called Visualizer, and contains the class structure and all the UI for an application that can be used to represent all of the information stored on Facebook. You'll go far beyond simply allowing people to log in to the application and grabbing their username; there is so much more that can be achieved with AS3 and the Graph API, and you'll learn about all of it.
Although the project is complex, the classes have been arranged in such a way that you need to modify only a small number of them, and these have little or no code in them to begin with. This means that you don't have to dive into mountains of code that you didn't write! You can focus entirely on learning about the Facebook side of Flash development.
Each of the Chapters from 2 to 6 has two associated ZIP files: one for the start of the project at the start of the chapter, and one for the end. This means you could skip through those chapters in any order, but you'll find it must easier to learn if you go through them in sequence. All project files are available in forms that are compatible with Flash CS3 and above, Flash Builder, and FlashDevelop—and if you use a different Flash editor, you should find it easy to convert the project.
When you first compile the project, it'll look like this:
Nothing much to see. But before long, you'll have added features so that it can be used to explore Facebook, rendering different Pages and Photos:
By the end of Chapter 6, you'll be happily adding code to search for users by name, exploring their personal profiles, and posting images and links to their Wall:
…plus plenty more besides!
In September 2010, Adobe released an official Adobe ActionScript 3 SDK for the Facebook Platform Graph API, which will remain fully supported by Adobe and Facebook. Read more about it at http://www.adobe.com/devnet/facebook.html. This book will teach you how to use this SDK, as it is a standard technology.
However, the main aim of this book is to teach you the underlying concepts of Facebook Flash development; once you understand these, the actual code and the SDK used don't matter. For this reason, this book will also teach you how to program every sort of Facebook interaction you might need from scratch. The code will be all yours, and you'll understand every line, with no abstraction in the way.
Besides the Adobe AS3 SDK for Facebook Platform, two other code libraries are used heavily:
MinimalComps: Keith Peters' excellent, lightweight user interface components, available at http://www.minimalcomps.com/ under an MIT license.
as3corelib: A collection of classes and utilities for working with AS3, including classes for JSON serialization, available at https://github.com/mikechambers/as3corelib under a BSD license.
From Chapter 3 onwards your SWF will need to be run from your server, through a web browser, in order to work. (Find out why in that chapter.) This makes debugging tricky—there's no Output panel in the browser, so trace statements aren't automatically visible.
The Visualizer contains a dialog feature which you can use to work around this. It can be created from any class that is in the display list. To do so, first import the DialogEvent class:
import events.DialogEvent;
Then, dispatch a DialogEvent of type DIALOG with an argument containing the text you wish to see output:
dispatchEvent(new DialogEvent(DialogEvent.DIALOG, "Example"));
It will look like this:
Of course, that's useful only for the Visualizer project. What can you do when you build your own?
There are a few tools that will help:
De MonsterDebugger: Excellent tool for general AS3 debugging: http://demonsterdebugger.com/.
Flash Tracer for Firebug: This Firefox tool lets you see
tracestatements from any SWF, as long as you have the debug version of Flash Player installed in your browser: http://blog.sephiroth.it/firefox-extensions/flash-tracer-for-firebug/.Vizzy Flash Tracer: Similar to Flash Tracer for Firebug, but also works for Internet Explorer and Chrome: http://code.google.com/p/flash-tracer/.
SOS max: Creates a socket server on your computer to which an AS3 project can send data; this data will then be logged and can then be viewed: http://www.sos.powerflasher.com/.
In Chapter 3, you'll learn how to run a JavaScript function in your web page from the AS3 in your SWF. One JavaScript function, alert(), creates a little window containing any String passed to it, like so:
This is a quick and simple way to display one-off messages without using trace.
When you run a SWF using Flash Player on your desktop, it loads and runs the SWF. Well, of course, why wouldn't it?
When you run a SWF in a browser, this isn't always the case, though. Sometimes, browsers cache SWFs, meaning that they save a copy locally and then load that copy—rather than the online version—the next time you request it. In normal browsing, this is a great idea—it saves bandwidth and reduces loading times. You can lose huge amounts of time trying to figure out why your new code isn't working, only to finally realize that the new code isn't being run at all because you were seeing only a cached copy of your SWF.
Different browsers require different solutions. It's usually possible to disable caching for one browsing session, and it's always possible to delete some or all of the cache.
In Google Chrome, you can do this by clicking on [Spanner] | Tools | Clear Browsing Data…, selecting Empty the cache, and choosing an appropriate time period:
You should easily be able to find the equivalent option for your browser by searching Google for «browser name» delete cache.
Facebook's developers are always tweaking the platform. This can make it exciting to develop on because new features are being added all the time, but it can also make it very frustrating to develop on because old features can be removed, or their implementations changed; anything could be altered at any time.
The new Platform API (the Graph API) is a strong foundation, and looks likely to be around for a while—remember, the previous Platform API lasted four years. But it's modular, and individual pieces might change, or even be removed.
It's possible then that parts of this book may be out-of-date by the time you read it, and some of the instructions might not give the same results with the current version of Facebook platform as they did when this book was written. If you're concerned about this, you can find out how to keep up-to-date with any platform changes in the last section of Chapter 8, Keeping Up With The Zuckerbergs.
But for now, dive into Chapter 2, Welcome to the Graph and start developing!
