Debugging Flash/Server Interaction with Charles

Using the program Charles to find those really annoying bugs in record time.
2005-01-16

Recently I had a problem with one of my flash projects not working. I could run it in Flash fine, but it didn't work when I uploaded it to the server. Flash just popped up an error that 'something was wrong' which was the worst kind of error. I found out there were two problems. The first was that I was actually sending data to the wrong subdomain. The second was that my php file couldn't do its thing because my databases's user permissions were wrong. These sources of errors are not the most obvious when you're working in Flash.

Flash is great when things go your way. And when they don't go your way, they're also pretty good. Flash's ActionScript will quietly fail, without much of a whimper. But sometimes you need something beyond a whimper to help diagnose problems. One of the biggest time wasters is when you've got a swf talking to a server, the swf is supposed to get some information from the server, but it doesn't. You don't know why, you don't know how, but for some reason your php/asp/perl didn't give Flash what it wanted, and you've got a swf with a permanent 'loading' screen.

Wouldn't it be cool if you could record everything that's happening between Flash, the browser, and the server? Then you could inspect what's being sent to flash and vice versa. But there's no way to see what's happening between Flash and the server. Or is there?

Enter Charles.

Charles is a 'web debugging proxy'. Probably the reason Charles isn't well-known in the Flash world is because noone knows what a web debugging proxy is. The makers of Charles should probably work on a snappier description. Perhaps 'web session analyzer' would be more appropriate. Anyway, its insanely useful. It has helped me out loads, which is why I'm spreading the love here. If you're a hardcore Flash developer, you need Charles.

Let's Get Started.

Let's do a simple debugging session with Charles to give you an idea of how it works.
Since the audience here is web developers, we'll be using Firefox.
First install Java, if you don't already have it.
Then install the Charles demo.
Then download these Flash test files.
You need to upload these files to your web server for testing. Its important that you use a web server to view the Flash. Don't just choose 'Publish' and view it from your hard drive.

Firing Up Charles

Run Charles. It should look like this:

Charles sits between your web server and your browser, recording everything it sees. This allows you to inspect what's happening is what you really want to happen. Now we need to configure Firefox to use Charles. Click on Tools->Options and then in the General tab, click 'Connection Settings...' Change your settings to:

Note: Once you are done using Charles, you must set your settings back to normal or your browser will not work!!

Note 2: If your testing server is 'localhost' or '127.0.0.1' you will need to clear the field 'No Proxy For:localhost,127.0.0.1' so that Charles will work!

Our broken file is go.

Let's open our broken flash file to see what happens. Open up charlesTest.html on your web server(not from the hard drive, but the server).

We've got a .swf file, and its supposed to be loading another file called 'picture.swf' but its not. For whatever reason, we can't determine by looking at the code why it's not working. So when we're in the web browser, how can we even be sure if Flash is receiving picture.swf? Charles can tell us.

Charles has recorded the 'interactions' between the web server and Firefox. You can see that when Firefox asked for charlesTest.html it got it from the server dev.ubergeek.tv. You can see the time taken, mime type, url, status, and lots more technical information. Firefox then grabbed 'charlesTest.swf'. and then finally tried to get a file called _level0.pictureClip.picture, which sounds a bit suspect. Click on it in the right pane to view the details.

But what's this? Flash was supposed to load a file called picture.swf, not '_level0.pictureClip.picture'. Click on the 'Response' tab.

Looks like there is no file called _level0.pictureClip.picture, which you probably guessed. Picture.swf is nowhere to be seen, so something's definitely in backwards. We're able to view not only the url requested by Flash, but the HTTP headers and the actual data being sent back to Flash! This is invaluable when you have a server sending dynamic data to Flash from PHP/ASP/etc. You can see exactly what is being sent to your Flash movie, and make sure that its functioning properly.

Sometimes the problems with developing in Flash don't have much to do with Flash. Its important to look at all steps of the process. One of the steps that's often overlooked is the interaction of flash with its environment. Charles works to analyze what's happening between Flash and friends.

You can look at the .fla and determine why picture.swf isn't being loaded as an exercise to take home :).