Before we begin, the author would like to gratefully acknowledge the hard work of the AMFPHP team. I'd like to especially thank Patrick Mineault who proactively updated this tutorial following the release of AMFPHP 1.0, as I would not have had time to do so. If you find yourself using AMFPHP, please drop the team a quick email to say thanks!

In this tutorial, we'll examine how to integrate Flash and PHP using Flash Remoting and amfphp. amfphp and Remoting make Flash data exchange simple and efficient. Here's what we're shooting for:

Pretty cool huh? The messages are stored in a database on the amfphp website. You can post your own message (watch your language!)

Can I Complete this Tutorial?
I always do my best to make my tutorials as easy to understand as possible. In cases where not only Flash is involved this becomes more difficult because I'm not a PHP guru and I can't teach you PHP before we begin (or even as we go). Having said that, if you're an intermediate ActionScript user, the PHP code used herein shouldn't daunt you very much; while different from ActionScript, it's decipherable.
If you have some PHP experience, that's great, as it will make understanding this tutorial easier still.
If you have absolutely no idea about PHP, I'd suggest you read this tutorial anyway; what I'm trying to do is teach you the basics and the benefits of this methodology, then, if you think it's going to be useful for you, you can go off and learn PHP (which is dead easy).

So now I can cover my back and say this: I'm not going to explain every line of code in this tutorial. The code is well commented and both PHP and ActionScript are very well documented. Fool around, have a go and if you hit a wall, post questions on the Forums, that's what they are there for.

What is Flash Remoting?
Flash Remoting allows you to execute Remote Procedural Calls (RPCs) via the Flash player. It allows you to transfer serialized, type-persistent objects directly between the server and a Flash MX client. The major use for Flash Remoting is in creating Rich Internet Applications (RIAs). In other words, using Flash not just as an animation tool, or even a jazzy HTML interface, but as the GUI and client for a full-scale, service providing, Internet application.
If you've built XML-based RIAs you know how much of a pain it can be to serialize the data, debug, and integrate into your application. With Flash Remoting, you can call remote methods from the Flash client and the arguments will end up in the native remote language, and will come back to Flash correctly typed, so there's no messing with serialization at all.

What Flash MX Remoting isn't.
Flash Remoting is not the same as Flash Media Server (FMS, previously FlashCom). FMS allows for video and audio streaming and recording, Server Side ActionScript, Remote Shared Objects among other things. In a way, Flash Remoting provides data-centric exchange while FMS2 is focused on multimedia. While FMS2 can be prohibitively expensive, Flash Remoting server components are available in many languages, like PHP, Java and Python, for free.

What is PHP Remoting?
Macromedia designed Flash Remoting mainly as a direct link between the Flash player and ColdFusion MX. The message format used in Flash Remoting is called ActionScript Message Format (AMF). After the release of Flash Remoting for Java, .Net and Cold Fusion, open-source developers who favored PHP as their server-side language of choice decided to create their own gateway so that Flash MX Remoting could be integrated with PHP.
The result is the amfphp project. Since then there have been many spin-offs of amfphp, like OpenAMF, FLAP (Perl), amf4r (Ruby) and more. amfphp is now more a mature project, with a stable 1.0 release three years after its creation.

Why use Remoting?
Remoting will drastically reduce the amount of work you have to do when exchanging data between Flash and a server because it allows for direct exchange of Objects; meaning you don't have to break down delimited strings or pass lengthy XML.
Further, the AMF format used in Remoting is binary, so it is considerably less verbose than XML and XML-based methods such as WDDX serialization, so it will download faster. That's not to say XML isn't great, XML has lots of uses. However, Remoting does one thing, and one thing only, data exchange between Flash and the server, and it does it very well.
Because of its object oriented nature, Flash Remoting allows you to develop a single set of server side scripts which can serve both a Flash and a non-Flash front end for your site. You can separate the presentation and formatting of data from the application layer, creating application layer scripts which just output objects and don't care what is done with them, whether they are used by Flash or read in by another server side script and formatted for an HTML or AJAX page. If your customers want both a Flash and a non-Flash front-end for their site, look no further than Remoting.
Finally, Remoting is just easier than doing it in any other way. Less coding is involved, bug testing is made simpler and coupling is tight.

Why PHP Remoting specifically?
I spent three hours the other day learning Cold Fusion (using Macromedia's trial). I'd never touched it before. In three hours, with a good book I was able to learn basically everything I needed to make a database driven website. Cold Fusion is a great server side language but, being a proprietary product, it's not within everyone's price range (myself included at the moment).

This tutorial is really just a tutorial on Flash Remoting (whether you use PHP, Cold Fusion, .Net or J2EE is irrelevant). As far as I know, the ActionScript herein will work just fine with other server-side modules (compatible with Flash Remoting) which output objects of the same format as the PHP files used herein. I decided to go the PHP route to enforce the "assume nothing" line I use in my tutorials; specifically, "don't assume people can afford or want to buy proprietary products when they can do most of the same stuff with PHP for free". The great thing about PHP is that it's already installed on most web servers, it comes with a bunch of useful libraries, and has a very active open-source community behind it. PHP is also syntactically very close to ActionScript so it is pretty easy to learn for Flashers.

Preparing Your System
With the general introductions out of the way, let's get into it. Since this involves PHP, a server side scripting language, you are going to require an account with a web-hosting company that supports PHP (and mySQL for this tutorial), or a local web server such as Apache or IIS, with PHP and mySQL setup and running. The machine I'm on at the moment has IIS 5.0 and PHP 4.2.2 and everything works just fine.

Running a local web server is highly recommended over using an online account, because it makes testing and debugging that much easier and faster. If you've never setup a local web server before, I suggest you try a package like XAMPP which provides a free, all in one Apache, PHP and mySQL pack, preconfigured and ready to go. All you need to do is unzip the package basically. Before proceeding with this tutorial you need to make sure your server is running and working so create a new file called 'phpinfo.php' in a text editor and add the following code:

<?php
 phpinfo();
?>

then drop it in your local web server directory and access it via your browser (http://localhost/phpinfo.php or similar will be the URL). If it brings up a big diagnostics screen, you're in business. If not, debug. If anyone has a link to a great tutorial on setting up a local web server, please send it to me and I'll add it here. (So far users have suggested these articles: 1.)

Also, to do any sort of Flash Remoting you need the Flash Remoting Components for ActionScript 2 for Flash 8 or Flash MX 2004 which come free from Macromedia. Note that these aren't 'Components' in the standard sense of the word; they're more like an extension to the Flash Authoring environment. Resist the temptation to download the AS1 components; they are not available for Flash 8 and it's unlikely that Macromedia will support them in future versions.

Now you need to grab the open source Remoting Gateway implementation from the amfphp crew over at http://www.amfphp.org/. Also, send them an email to thank them for their great work. That's required. If you don't do it, the Flash Gods will know and none of your scripts will execute properly ;)

This tutorial will assume you extract the files in the manner described here as the paths to various files are important so please be sure you have the following directory structure, or adjust the example code given to match the structure you choose. Your HTML document root (under IIS it's the "C:\Inetpub\wwwroot\" directory, under Apache it's generally "C:\Program Files\Apache Group\Apache\htdocs\" or similar) shall be referred to herein as 'document root'. The amfphp archive contains a single directory called 'amfphp'. Extract the archive such that the amfphp directory sits immediately below your document root. E.g. "C:\Inetpub\wwwroot\amfphp\" or "C:\Program Files\Apache Group\Apache\htdocs\amfphp\". If you've extracted the files correctly you should be able to access the amfphp gateway.php via http://localhost/amfphp/gateway.php. Try this now. You should get a prompt to download a file, like so:

That's perfectly normal, since amfphp sends back binary data, which browsers will try to download instead of displaying. If you get an error instead, please check you've observed the structure stated above and post on the forums if you continue to experience problems.

With that all out of the way, you're ready to start coding, but first, some more background information.