How to debug Flex/AIR and PHP applications

LATER UPDATE: I wrote another article that is up to date. You can read here the new one.

Another question I get quite often is “How do I debug my Flex (or AIR) and PHP application?”. Usually I take some time to show a few debug methods when I am presenting Flex/AIR and PHP workflows.

There are several methods that you can use to debug Flex/AIR and PHP applications, each with its own advantages and disadvantages:

  1. Use Flex Builder and Zend debuggers.
    1. Pros: it is arguably the most elegant and efficient way; it is not intrusive
    2. Cons: you need to have Flex Builder and Zend Studio installed together; it does not work for AIR applications
  2. Use a server side logging function for PHP, and Flex Builder debugger for Flex
    1. Pros: it works great for both Flex and AIR apps; you need only Flex Builder
    2. Cons: it isn’t so straight-forward; you need to walk through the code and call the logging function until you pin-point the problem. It is very much like doing JavaScript debugging with Alert or PHP debugging with Refresh and die(var_dump($myVar)). It is intrusive because you have to add code to the PHP that is not needed in production.
  3. Use a proxy sniffer, such as Charles
    1. Pros: it understands AMF format; it is not intrusive
    2. Cons: it is shareware, and it can’t be used for AIR apps
  4. FirePHP. This is actually similar to method two above. The only difference is that you need to install a Firefox extension, and then using this extension and some PHP code you can see the output of the FirePHP logging functions directly inside of your Firebug console.
    1. Pros: it is easy to read the four different types of messages (log, info, warn, error) in the console, and it may be familiar for those who already use Firebug (such as AJAX developers)
    2. Cons: it works only in Firefox because of the dependency on Firebug; it doesn’t work for AIR, and it is intrusive (you have to add code for it)

Using Flex Builder and Zend debuggers

This is my favorite, and I believe it is the fastest way to debug your code. Although you can’t use this approach for debugging AIR projects, I think it is worth it to create a twin Flex project just to be able to use this approach.

You can read more about this method here, or you can watch my video tutorial here.

Using a server side logging function

Actually, this was my first approach for debugging AIR and PHP applications back in 2007 when I created my first AIR application. At that time, I was using XML-RPC to communicate between the client and server, and as I started to hit bugs I needed something to debug (at that time the PHP debugger wasn’t so reliable, and it was hard to make it work in the Eclipse IDE).

I still use this approach today, when I want to log some variables on the PHP side. I use this function:

   1: function logMe($var) {
   2:     $filename = dirname(__FILE__) . PATH_SEPARATOR .'__log.txt';
   4:     if (!$handle = fopen($filename, 'a')) {
   5:         echo "Cannot open file ($filename)";
   6:         return;
   7:     }
   9:     $toSave = var_export($var, true);
  10:     fwrite($handle, "[" . date("y-m-d H:i:s") . "]");
  11:     fwrite($handle, "\n");
  12:     fwrite($handle, $toSave);
  13:     fwrite($handle, "\n");
  14:     fclose($handle);
  15: }

This function uses a text file (__log.txt) to dump its single argument, together with a time stamp. I can use this function to log primitives as well as complex types. Here is an example of how the file looks after I dump some variables:

   1: [09-03-11 21:56:01]
   2: NULL
   3: [09-03-11 21:56:10]
   4: VOAuthor::__set_state(array(
   5:    'id_aut' => 2,
   6:    'fname_aut' => 'William11',
   7:    'lname_aut' => 'Shakespeare',
   8: ))
   9: [09-03-28 15:18:37]
  10: array (
  11:   0 =>
  12:   VOAuthor::__set_state(array(
  13:      'id_aut' => '1',
  14:      'fname_aut' => 'Dante',
  15:      'lname_aut' => 'Alighierie',
  16:   )),
  17:   1 =>
  18:   VOAuthor::__set_state(array(
  19:      'id_aut' => '4',
  20:      'fname_aut' => 'Niccolo',
  21:      'lname_aut' => 'Machiavelli',
  22:   )),
  23:   2 =>
  24:   VOAuthor::__set_state(array(
  25:      'id_aut' => '3',
  26:      'fname_aut' => 'Umberto',
  27:      'lname_aut' => 'Eco',
  28:   )),
  29:   3 =>
  30:   VOAuthor::__set_state(array(
  31:      'id_aut' => '2',
  32:      'fname_aut' => 'William',
  33:      'lname_aut' => 'Shakespear',
  34:   )),
  35: )

This method is very simple, however it is intrusive since you will have calls to the function in your code, and you don’t want these calls to end up in your production code/server. Second, debugging in this way is not so fast, especially if you don’t have a good idea about where in your code base the problem could be.

Using Charles to debug

You can use Charles (which is a  Proxy Sniffer) to see what messages are exchanged between the Flex client and the server. This method doesn’t work for AIR applications. Charles knows how to decode AMF messages, thus if you are using Remoting, then you can still see the communication.

After you start Charles, be sure you configure your browser to use Charles as a proxy:


Next, start your Flex application and make a call to the server. In Charles, you can see the request, what method was called from Flex, and the response sent back by the server. In the screen capture below, you can see the information for a remote call on a PHP class using Zend AMF.


This method is great for quickly pin-pointing what Flex sends to a PHP script. If your problem is not solved here, then you have to switch back to method 1 or 2. Or you can alter your code to output the variables from your script, and in Charles you can see the dump (for the example below I just added to my script something like die(var_dump($result));:


Using FirePHP to debug

You can find information about how to use FirePHP here and here.


If you are using Zend Framework, then it is even easier beacause you don’t have to download and install the FirePHPCore library. You need only Firefox, Firebug, and FirePHP extensions installed. Again, you cannot use this with AIR projects. Zend Framework lets you enable and disable the logging very easily:

   1: $writer->setEnabled(false);
   2: $profiler->setEnabled(false);

This means that you don’t have to remove the debug calls when you go to production.


There are many ways to debug Flex/AIR and PHP applications. Depending on the nature of your project, and the nature of your problem, you can use more than one. I hope this post will help you, especially when you take the first steps in Flex and remoting.

16 thoughts on “How to debug Flex/AIR and PHP applications

  1. What about Fiddler2? It’s free and I can do a lot with it. If the argument will be that shareware (Charles/ServiceCapture) have a better GUI, that is not a valuable argument.
    Keep it up! :)

  2. @Adinel

    I know Fiddler. Excellent tool. However I see two issues with Fiddler:
    1. No version for Mac OS (I’m working on a Mac :D)
    2. It doesn’t seem to “understand” AMF format.

  3. @Mihai
    True. My bad. I guess I like debugging the hard way. I’m thinking on going with Charles on Mac even though until right now I’m using different tools such are those made for Mac by Corsaire. Elaborating on these it will touch another domain so we should stick to debugging.

  4. Pingback: 7/05/2009 « Robertopriz’s Weblog

  5. Pingback: How to debug Flex/AIR and PHP applications : Mihai CORLAN | The Hoover

  6. Ex: How to profile your flex-php application, what are the best php profilers used in combination the Flex Builder profiler. How you can easily discover what are the methods in your app that are using a lot of time to complete … etc.

  7. @Razvan
    Hmmm… I can’t really answer what is the best combination, but I can recommend a good PHP profiler. xhprof was originally developed at Facebook, was open sourced in Mar, 2009.
    Give it a spin and comment here if it was of any help comment here.

  8. How about Flex and Xdebug? It’s also non intrusive and doesn’t require Zend Studio. Works well with Eclipse or vim…

  9. I found that debugging air application talking to php server is simple using fiddler, eclipse pdt (xdebug), optional i can parallel debug actionscript part with flexbuilder

  10. If you are developing on your localhost you CAN use Charles Proxy to debug your AIR application.
    Instead of pointing your remoting service to “http://localhost/MyService” use “http://localhost./MyService” (note the fullstop)

    Then you need to add “localhost.” to your hosts file: localhost localhost.

    See here how to amend it on win & mac:

    Give it a try and should see your remoting calls passing through Charles.

  11. It is possible to use for sniffing with AIR, at least with ServiceCapture (ShareWare as well), and it should be same with Charles, since they are not simple proxy sniffers, but working at least on TCP hooking level.

    > Use a proxy sniffer, such as Charles
    > 1. Pros: it understands AMF format; it is not intrusive
    > 2. Cons: it is shareware, and it can’t be used for AIR apps

Leave a Reply