Dynamic Flash

In attempting to upgrade the AirShows application to use the new AIR 1.5 runtime, I tried to simply change the target SDK to Flex 3.2 in the project settings. However, this was giving me all sorts of strange errors, from not launching to displaying the following error dialog when trying to launch the application in debug mode:

On a hunch, I checked the application configuration file AirShows-app.xml file and noticed that it uses the following namespace declaration:

<application xmlns="http://ns.adobe.com/air/application/1.0">

Since the Flex 3.2 SDK actually expects to be building AIR 1.5 applications, I had a feeling that this was the root cause of my problem. A quick change in the namespace to the following solved my problem:

<application xmlns="http://ns.adobe.com/air/application/1.5">

Thankfully I didn’t waste a whole lot of time trying to figure this out, but I do wish Adobe had provided slightly more useful error messages.

Productivity and motivation are strange and often elusive things when it comes to your personal projects. You start a project with the best of intentions, have a hyper-productive 2 to 3 day burst right at the start, and then get distracted by some new shiny project. You convince yourself that these projects have been postponed rather than abandoned, but your subconscious knows that they will never see the light of day. Your projects directory becomes a haven for rotting, neglected and increasingly obsolete code that will eventually be lost or deleted.

This is a situation I had accepted as a normal part of being a developer, right up until a week ago when a number colleagues past and present started to upload their personal projects to GitHub. GitHub is an online code hosting service that integrates with Git, a distributed version control system originally written by Linus Torvalds.

Code hosting services have been around for a while, and big hitters like SourceForge and Google Code have done wonders for open source projects. However, GitHub has one important feature that makes it so much more useful than the more established project hosting sites: a social graph. The ability to join a network of friends and automatically see when they’re updating their projects (or adding new ones), to watch or fork those projects for my own ends, gives me the impetus to keep my own projects moving a long.

Right now I only have two projects on GitHub: as3base64 (which was released a few years ago on this site) and AirShows. AirShows is a Adobe AIR-based GUI for editing the configuration file for pytvshows. It’s far from finished, and the code is really quite ugly, but the very fact that it’s now out in the open where my friends can see when I’m working on it (and when I’m not) means that I feel I’m more likely to keep up development.

If Git doesn’t suit your style you don’t have to use GitHub; there are plenty of other code hosting services that offer similar features, such as LaunchPad (Bazaar) and BitBucket (Mercurial). The important thing is that you chose the one that most of your friends are actively using, otherwise you’ll lose out on the very feature that makes these sites so useful for productivity.

A word about licensing

If you’re going to go to the effort of making your projects public, you might as well make them as useful as possible. A lot of developers have heard of the GNU General Public License and often use it for their projects. However, this license requires that the source code for all changes made to your code by third parties must be made available to the public. This means that businesses are often wary of using code licensed under the GPL as part of a project.

All the code I release publicly is licensed under the more liberal MIT License. This license grants developers the freedom to use the code in any way they choose without restriction, so long as the copyright notice remains in the source code. The BSD License is similarly liberal. I urge you to choose one of these two licenses for the code you make available, or at least make sure you understand the implications of the license you end up choosing.

I find it shocking that the Flash Player still lacks the ability to properly interact with RESTful web services. I keep running into this issue, and every time I scour the Internet hoping that someone, somewhere has found a solution. Every time I return disappointed, hating the Flash Player just a little bit more.

REST stands for REpresentational State Transfer, and describes a technique to organise a web service into resources that can be uniquely identified by a URI. The actions that can be performed on that resource map directly to the standard HTTP methods: GET, POST, PUT, DELETE, HEAD and OPTIONS. With properly organised resources it’s possible to do virtually everything you can do with an RPC-style web service with REST. The benefit of REST is that it goes with the grain of the web, not against it.

The problem with the Flash Player is that the URLRequest class, which is the basis for all HTTP requests, only supports GET and POST operations¹. This is due to a limitation in the NPAPI pseudo-standard used by non-IE browsers that only exposes the ability to make GET and POST requests. Unless NPAPI is updated to allow other HTTP methods, and browser vendors and plugin authors update their implementations to match that new API, we need to find other ways of interacting with RESTful web services.

Now, If you’re lucky, the web service you’re trying to interact with will support some way of overriding the request method, such as a X-HTTP-Method-Override header. If this is the case, you can use the requestHeaders property of your URLRequest object to set the appropriate method:

// Create request object with appropriate resource URL
var req:URLRequest = new URLRequest( 'http://rest.example.com/v1/book/1234' );
 
// Use POST because DELETE is non-idempotent
req.method = URLRequestMethod.POST;
 
// Specify DELETE method in X-HTTP-Method-Override header
req.requestHeaders = [ new URLRequestHeader( 'X-HTTP-Method-Override', 'DELETE') ];

If your web service isn’t quite so forgiving, the only option you have is to use the ExternalInferface class and some JavaScript magic to make requests on behalf of your Flash project and send the response back. It’s an ugly hack, but a developer’s gotta do what a developer’s gotta do. If you’re interested in this workaround, leave a comment and I’ll knock up a simple example.

For what it’s worth, Silverlight fares no better in this regard. This is not surprising since Microsoft are stuck with the same browser plug-in APIs as Adobe, but that doesn’t make it any less annoying for developers on both sides of the fence.

Dynamic Flash had a bit of an outage there, but I think we’re all good now. The DNS and web servers at my old company (who were kindly still hosting this site) stopped responding around mid-afternoon UK time today, and I’ve been scrambling to get the site back up since about two hours ago when I realised that this appears to be a permanent issue.

In record time, i’ve managed to acquire new hosting, repoint the domain, set up wordpress, restore the blog database backup that I took first thing this morning, upload all the example files from a backup I did way back in April, fix an issue with the theme, and finally write this blog post. Phew!

There’s a good chance that I’ve missed more than a few things whilst doing this, so please let me know if the comments if you find something on the site that’s not working as it should.

The slides and example code from my Beg, Borrow or Steal: The Art of Flashing Without Flashing session at <head> ‘08 are now available for viewing/download from the My Talks section.

See <head> over heels for a full conference write-up.