Controlling Flash Player 8 SWFs in Flash Player 9 SWFs

One of the things I’ve been promoting the last year is encouraging people not to mess with loading legacy Flash Player 8 content into Flash Player 9, usually with regards to Flex 2 content loading Flash 8 content.

ExternalInterface gives you less browser support, the calls are blocking which locks up your visual display depending on speed, and causes security debugging challenges if you don’t know exactly what you are doing. The last is the kicker because you DON’T have to know, you just know it works, and you move on. When under a deadline crunch with a boss yelling at you, it’s really frustrating to not know why a SWF is yelling about security rules. You don’t need another headache. LocalConnection is asynchronous, and has little strong-typing, and has a limit on the size of messages you can send. Furthermore, you have no guarantee every call you make will… make it. There have been abstraction attempts which really end up with about the same amount of code had you not abstracted it.

Bottom line, it’s a major headache, painful to debug, and gets really funky when you start loading multiple pre-Flash Player 9 SWF’s into the same app. My guess is, it shares the same security & application domain sandbox which you’re code is not allowed access to. Therefore, any static variables I’m guessing are stuck there too (aka, classes on _global). Never really figured out the exact reason, but it’s just blatantly crazy how bad things are and just flat out don’t work as you’d expect.

…but there is something far worse, and foreboding. Flash Player 9’s DisplayList + Garbage Collection. In Flash 8 and below, we’re pretty spoiled. We do a my_mc.removeMovieClip(), and poof, everything is gone. All sounds stop, everything stops showing, and most RAM goes with it, immediately. Not in Flash Player 9. Since you don’t have access to this AVM1Movie “sandbox”, whatever the heck it is, you can’t stop the stuff either. Case in point, load in a SWF with a video player, and then unload the SWFLoader. You’ll still hear the video, and it’ll STILL be using resources… that is, until Garbage Collection decides to nail it, if ever. In effect, Flex speaks Espanol, and Flash speaks English. You need a translator.

In the past I’d do what I’ve been doing the last 2 years; reverently exclaim you need to go to management and explain the benefits of AS3, and just rewrite your legacy content. Since I wasn’t the one who had to deal with the ramifications & implementations of those decisions, it was pretty easy for me to do so upon a high horse.

…then I started working for an Internet TV company. Thousands upon thousands of customers using Flash Player 8. Existing customers, entrenched, with working software. Boat loads of existing Flash Player 8, 7, and 6 content that works for a variety of existing customers and clients. In effect, Flash Player 8 content AND development isn’t going away for at least another year. Bugger…

I tried eating my own dog food, but you can’t just immediately demand thousands of people upgrade their rigs without incurring significant costs and losses doing so. Then I tried my best to sequester myself away from said Flash Player 8 content. No dice. The amount, and thoroughness of some of the implementations was too great for me to just re-write in AS3. I can only code so fast.

So, in the end, I’ve settled on a 3 tier setup. A Flex component that uses a SWFLoader via composition with 2 LocalConnections; 1 for talking to the SWF, and for the SWF to talk to it. A Flash Player 8, AS2 SWF that has 2 LocalConnections, 1 for talking to Flex, and another for Flex talking to it. This Flash SWF manages all content it loads, usually written for a specific piece of content. If you have control of the servers you are loading from, you can either have yourMovieClipLoader check the policy file, and boom, you’ve got no problem with loaded Flash content talking to Flash content. Even if it’s not yours, it’s very easy to dig around in someone else’s classes and “make stuff work” since everything is public in Flash Player 8 and below bytecode.

The important job of the proxy.swf is clean up the mess when you unload stuff. In the case of a Video Player, you have to stop the video, stop all sounds, and unload the player. It’s ok if the Flex component holding the proxy.swf doesn’t die immediately; the proxy.swf has basically done his job well: stopped all multimedia, and lessened the RAM & CPU damage. An ancillary benefit is you can issue commands through this proxy.swf to control your content. I just send string messages in this case and the proxy.swf knows what to do with them.

If you find yourself in this situation, don’t go down the ExternalInterface route; it’s too painful. Don’t load it using a simple Flex SWFLoader either since you’ll have no control over the content. Yes, it sucks you have to build a seperate SWF as a Mediator Pattern implementation, but if you don’t, you won’t have any control over the SWF you’re loading in. Remeber, test and get it working in Flash first before you start involving Flex in the mix.