Adobe Flex to JavaScript… why Conversion is Hard

I recently had a conversation with Simeon Bateman regarding the woes of mobile web development. We realized one of the reasons why Flex developers as in general have a hard time embracing JavaScript development.

The Problem

The particular JavaScript quirk we were discussing was window.innerHeight functions on mobile devices.  During our development on mobile devices, we ran into two frustrating issues.

Simeon’s issue was with the way window dimensions get messed up when an Android device is re-oriented.

My issue was with the way that window.innerHeight tells you how much space you have with the url bar on the screen, until the url bar is scrolled off the screen, then it reports the actual space that you can work with (since this is my post we’ll talk about my problem). This issue if frustrating because I’m trying to get a webpage to take up the whole screen on the mobile device, with the url bar scrolled out of view.

To illustrate what I’m discussing, I’ll show side by side screenshots.  The screenshot is of a page that reports the screen height and width and the window innerHeight and width and updates them on an interval.  On the left you have the URL bar, on the right the URL bar has been scrolled off the screen.  Notice how the screen size has remained the same, but the window.innerHeight has changed.

Window Size with URL barWindow Inner Height without URL bar

We both understood the problems we faced, but both believed there had to be a good and right way to solve the problem, a “best practice” if you will.  Having spent time working in the Flex community, we had come to expect an elegant way of solving the issues we faced.

Neither of us are foreign to forging our own paths through new territory, but we’re generally used to coming to a solution that feels right.  When things start getting hacky we feel like we’re in the wrong place and try to research the problem looking for a more elegant solution.

Finding A Solution

In our scenario with window.innerHeight we were trying to think how we could go about getting the height of the space we can use in an elegant fashion, and couldn’t come up with anything.  We knew how to accomplish our tasks in an inelegant fashion, but thought it was a common enough task that there would be a “right” or elegant solution.

Finally we realized that we knew of people out there who were doing what we wanted, and this is JavaScript after all, so we went and looked at the source. We checked in a few places, and discovered that most of the places we checked handled this problem in a similar way.  The great guys over at Sencha had this in their code for handling this problem and making sure the application is the correct size.

init: function (c, b) {
    var d = this,
        e = Math.max(window.innerHeight, window.innerWidth) * 2,
        a = Ext.getBody();
    this.initialHeight = window.innerHeight;
    this.initialOrientation = this.orientation;
    setTimeout(function () {
        setTimeout(function () {
            d.initialHeight = Math.max(d.initialHeight, window.innerHeight);
            if (c) {
                c.apply(b || window)
        }, 500)
    }, 500)

The variable names are not great as its beautified code that was minified, but if you follow it you can see what they’re doing.

In order to size the app to the proper height and be able to have the url bar scrolled off the top, they have to double the size of the container, to ensure that they can scroll past the url bar. Then they scroll… twice on 500ms timeouts, and then they can fix the size of the app to bring the size down to what it really is without the url bar, since window.innerHeight will now report they value they want.

The Difference

This is where JavaScript development diverges from Adobe Flex development.  The fractured landscape of so many browsers and the impossibility of getting users to upgrade in a timely manner has left JavaScript developers with no choice but to hack their way through.

This is not to say that JavaScript lacks elegance… but that there are some areas where the hack is just what you need to do.

In Flex there are times where you need to implement a hack, but you generally implement it as a patch to the Flex SDK and your application code is spared the hack. This example underscores one of the big issues that Flex developers face as they move from the world of the Flash Player to the fractured world of browsers. To a Flex developer this feels like an inelegant hack, but to a JavaScript developer this is a great solution, because it works across all the different platforms we need to support.


I don’t present this information as a way of excusing Flex Developers from exploring HTML/JS development, but wanted to help developers understand this difference that can help on both platforms.

With this new found understanding if you feel like hopping into some HTML/JS development, may I suggest another article, by Simeon Bateman.

Adobe Flash ExternalInterface issues with Internet Explorer

On a recent project, I was asked to build a simple Flash mp3 player that could be controlled with JavaScript by using ExternalInterface.  I built and tested the whole application in under an hour and was feeling pretty good about myself.  QA filed a bug saying that JavaScript was throwing an error, and it only occurred when my mp3 player was present.

The error only happened in IE8, so I was stuck with IE’s debugger and error messages.  The error was being thrown when the loaded SWF attempted to add callbacks to ExternalInterface using ExternalInterface.addCallback  As soon as this function was called my script threw an error:

Object doesn’t support this property or method

IE 8 Error Screen

The stack trace showed an anonymous JScript block with a function named __flash__addCallback which was throwing the error when trying to append a property to a JScript object. The debugger for this particular error looked like this.

I scoured the internet searching for solutions to this problem as I was sure it had to be something that was well documented.  I came across some solutions that appeared to work for people such as: ensure your object tag has an id, ensuring you set the type or class id on the object tag. These solutions worked for some people, but didn’t solve the problem I was having.

After a little more investigation I realized that some of my ExternalInterface calls were successful, while others were not.  I then realized that play and stop were probably reserved names for IE8 and might be the root of my problem.  I adjusted the names of the callback functions to playSong and stopSong and things started working.

This Doesn’t Work:

ExternalInterface.addCallback("play", play);
ExternalInterface.addCallback("stop", stop);

This Works:

ExternalInterface.addCallback("playSong", play);
ExternalInterface.addCallback("stopSong", stop);

The moral of the story is to avoid common names when using ExternalInterface. Play and Stop I know are reserved, and I’m sure there’s a host of others out there.

Tip of the Day – Getting a SWF’s background color

Recently at ZaaLabs, I’ve been working on a really cool tooling platform called Eden. One of the features that Eden has is a Screen Capture plugin. Eden can send a request to a remote SWF to return a bitmap of the stage.

For example, here is Eden pulling a screen capture from HanClinto’s Platformer Starter Kit.

Really cool! However, I quickly ran into an issue when I tried to take a screen capture of a more basic game.

On the right is the game running in Flash, and on the left is the screen capture.

As you can see, my screen capture doesn’t include the green background. So what happened?

Well it turns out the background color of a SWF isn’t actually part of the stage. The background color that you set using the SWF Metadata tag, or set in Flash Professional is drawn directly by Flash Player.

	import flash.display.Sprite;
	[SWF(backgroundColor="0x00FF00")] // <--- How can I get this programmatically?
	public class SwfBackgroundExample extends Sprite
		public function SwfBackgroundExample()

So I had a dilemma… how could I access the backgroundColor of the SWF? I scoured the API docs, I asked the Twitter-sphere, but no luck. All I learned was that the backgroundColor was hard coded into the bytes of the SWF. So I decided that’s where I needed to look for it.

SwfData to the rescue.

I read up on the Adobe SWF specification, and consulted with my good friend James Ward. He pointed me in the direction of loaderInfo.bytes, which gives us access to the bytes of the currently running SWF.

After a few hours, I had a fun little class I like to call SwfData, which parsed the background color out of the currently running SWF’s bytes… as well as some other fun things. Here’s how you use it:

	import com.zaalabs.utils.SwfData;
	import flash.display.Sprite;
	public class SwfDataExample extends Sprite
		public function SwfDataExample()
			var data:SwfData = new SwfData(loaderInfo.bytes);
			trace("version \t"+data.version);
			trace("frameRate \t"+data.frameRate);
			trace("frameCount \t"+data.frameCount);
			trace("fileLength \t"+data.fileLength);
			trace("bgColor \t0x"+data.backgroundColor.toString(16));

Using SwfData, I could now use the background color as the fill color of my BitmapData class.

Get It Here

SwfData is MIT licensed under ZaaUtils (do with it what you will). It is available on GitHub

Questions, comments, complaints are all welcome below.

== UPDATE ==

So I just found out that Claus Wahlers has an awesome, more feature complete version of an AS3 SWF parser. It’s also available on GitHub. I’m still going to keep SwfData up since it’s much more specific to getting the background color of the swf. If you need more features, use as3swf by Claus, it’s very well done.

RIARadio, GangstaCast, TheFlexShow and Tech News Today…

Recently I’ve had the opportunity to participate in a few podcasts, and they all seem to have come out this week. Check them out:

The Flex Show – Episode 115

RIARadio – Episode 17

GangstaCast Episode 1: Celebrity Stalker Edition

Also, I was thrilled to find out that I was mentioned on’s Tech News Today for an article I wrote regarding tracking celebrities by scraping exif data from photos uploaded to TwitPic, yfrog, TweetPhoto and TwitGoo.  The part when they talk about the article is about 15 minutes into the episode.

Tech News Today 34: Take Off Your Pants, America

Article on ZaaLabs

So all in all, it’s been a very interesting week.