There are workarounds. Clunky at best and mostly proprietary, they’re seldom used by the third party agencies who audit the traffic claims of major sites (and thereby influence the rates those sites can charge advertisers). In other words, they don’t rate with the moneymen.

There have been efforts to emphasize other metrics, such as the amount of time a user spends on a site, but they haven’t amounted to much yet. At least not enough to free us from traffic woes when playing anywhere remotely near the bleeding edge.

It’s quite plain this state of affairs is holding these technologies, and the Web, back. Enough so that Adobe has apparently decided to take matters into its own hands, at great expense, by plunking down a king’s ransom to acquire Omniture, a major player in the business of counting site traffic.

With this purchase, Adobe clearly intends to construct a bully pulpit from which it can influence this state of affairs for its benefit, serving their deeply vested interest in Flash. Good for them.

So this begs a question.

Is anybody working on a solution for AJAX?

It would seem like the work currently underway on HTML5, a specification fittingly dubbed “Web Applications 1.0″ at one point, provides a choice opportunity to establish some clear guidance on trackable AJAX events in Web apps for everyone involved, and help steer the ship forward.

I’ve been scanning the spec-in-progress, but haven’t yet seen anything that seems to fit the bill. It’s a big spec. I could easily be missing something. Maybe we can use the ping attribute? Perhaps it’s in how resource fetching is defined? I don’t know. But I’m sure minds more knowledgeable than mine have some ideas. Ideas that wouldn’t constitute a proprietary hack.

The major sites won’t budge until the auditors move. The auditors won’t move until the corporate coalitions make some decisions. The corporate coalitions are comprised of the owners of said major sites. Lather, rinse, repeat.

What’s needed now is a standards body to break this stalemate. Otherwise we remain locked into a stagnant scenario where no one wants to be the first mover, and the proprietary solutions pass us all by.

class TestArray {
    private var foo:Array = new Array();
    public function TestArray() {
         this.foo.push("bar");
         trace("this.foo.length ––> " + this.foo.length);
     }
}

I know, I know. Bad form. ‘Tis true. The class property foo isn’t really a compile-time constant. But the compiler says nary a word in protest. No errors thrown. Nada. Zip. Zero. Nothing. Which would be fine if the Flash IDE didn’t get all butterfingered on you.

But try creating a new instance of TestArray in your Flash movie and invoke “Test Movie” a few times without closing the window. The length of foo will just grow and grow and grow. It’s only cleaned up between tests if you close out the Test Movie window and start over again.

I could be wrong, but methinks I smell a compiler garbage collection issue (albeit one surrounding bad code). Shouldn’t the compiler be smart enough to let you know when you’ve done something that’s basically foolish?

All that smashing and crashing generates a whopping pile of (sometimes quite thorny) data. The challenge was to come up with a visual metaphor that conveyed all that information clearly, and in a fairly compact column space. So pretty early on I figured that using an actual color-coded crash test dummy was the way to go. From there it was off to the races with ActionScript and Photoshop. (Though I can’t take credit for the 3D rendering—that goes to one of our Maya techs and a handy stock library of prebuilt 3D objects.) Back-end coding was handled by newly-minted BusinessWeek cohort Mike O’Malley, who is without a doubt one of the most talented coders I’ve ever met.

Make sure to check out the videos. They’re stunning, sobering affairs—particularly the newer side impact tests. You can see where work from the Institute has clearly had an effect (Ford F-150, I’m looking at you).

All in all, a fun, meaningful project. Though I was occasionally taken with the urge to pop on the iPod and crank up Mmm Mmm Mmm Mmm. (Hey, I don’t care what anybody says, I liked that band!)

While this isn’t the first time Apple has used Flash on their site (see the Final Cut Studio pages, and the image galleries for the iPod nano that neatly mimic the side-to-side browsing of the iTunes Music Store), it’s certainly the most prominent. A far cry from the days of tinkering with sprites in QuickTime tracks. (How many old copies of LiveStage Pro are out there just hanging around collecting dust?)

This time the joy came in the form of a seemingly mundane preloader I threw together using the drawing API. No need for anything in the library, just a nice, svelte little progress bar drawn in at runtime. Nothing too exotic, right? Pop it into my Flash file and blam-o! The unmistakable sound of breaking glass. My movie is playing after the preloading is done, but my progress bar is still there, stuck at 100%. “What the–? Oh brother, here we go again…”

A little Googling turns up this gem. Turns out the V2 button component drags mx.managers.DepthManager along for the ride, which nabs the highest and lowest available depths from the Flash player and then proceeds to sit on them for future use. No big deal, but if you’re a good scout and use the MovieClip.getNextHighestDepth() method guess whaaaaaaat… your next highest depth (1,048,576 to be precise) will be beyond the reach of MovieClip.removeMovieClip(). Never mind all those other open slots. All together now… “D’OH!”

The solution? If you use getNextHighestDepth() and the V2 components together in the same movie be prepared to use swapDepths() to drag that clip back down to Earth where you can do something useful with it.

So now the real question is, think anybody’s done anything about this in Flash 8?