I recently discovered a great podcast that is put out by Thoughtworks. I can’t remember at the moment who turned me on to this thing (probably Ali), but it really is fantastic.

http://www.thoughtworks.com/what-we-say/podcasts.html

Podcast #4 “REST – Representation State Transfer” is well worth a listen. Especially for those of us that build SWFs and even more so for those of you that push for binary data protocols.

In a bit of a meta joke, there doesn’t seem to be a link directly to the REST entry, so as this post gets older, the link above will become less meaningful!

I’m sure much of this is old news to many of you, but some key points that I took away were:

Is it just me? or is this a strange decision?

After installing CS3, debugging in Flex Builder suddenly launches Flash Authoring and stops sending trace output to Eclipse.

Ali and I have been providing support for the past couple of months on a large application that we built and deployed earlier this year. We had an interesting bug filed today and I set about trying to address it.

The bug is this:

If I click around in the SWF application, and especially if I select a text input field at some point, I can no longer edit the Firefox Location bar (Address bar).

In addressing this issue, I immediately suspected our focus/selection management layer, then moved on to our TextInput controls, and eventually wound up scouring the web to see if anyone else reported the same problem. As it turned out, I still haven't found anyone else reporting this issue, but in my searching - I did discover the root cause.

It's the "wmode" parameter of the embed tag. As far as I can tell, this attribute can be set to "opaque", "transparent" or not set at all. Setting it with an empty value, or an unexpected one appears to default to the opaque behavior. NOT declaring it at all behaves very differently as I soon discovered...

I was surprised to find an issue with this setting because we're using the swfObject deployment package and it came highly recommended. As it turned out, there doesn't seem to be much the swfObject folks could have done, and by not declaring this property at all, they in fact chose the least of 3 evils...

After finding out about this attribute, I immediately set it to "opaque" in my embed tag and found that my bug disappeared. I was so excited I started integrating and was just about to check in to version control, when it occurred to me that this setting might actually have side-effects beyond the background opacity... As a last minute double-check, I began searching google for the meaning of this parameter and quickly learned that this seemingly innocuous little attribute was sitting on top of a giant mountain of subtle bugs...

Following are the side-effects that I discovered:

To make the most universally available application today (multiplatform / cross-platfrom / cross-software / cross-hardware) that runs on win, mac, and nix desktops; multiple palmtops; and all modern browsers, you need to publish to the Flash Player 7. That’s right, the SWF format that’s two versions old.

The most recent mobile phone player, Flash Lite 2.0, is based on the Flash Player 7, so by targeting Flash Player 7 you can develop for phones. Flash Player 7 also runs on Pocket PCs and is the most recent version of the player for Linux, so you also get Pocket PC and Linux support by deploying to it.

If you’re interested in developing a code-base that’ll be able to run in as many environments as possible, write that code-base in a language that will compile to Flash Player 7 bytecode. Languages to choose from today are ActionScript 2.0, C#, XAML, RVML, and haXe.

Have fun building the future today!