As I watch Flex roll through the GMC builds, heading inexorably towards release, I realize that there’s a lot of insider knowledge that might be of interest to hardcore Flex/Flash folks – undocumented APIs, clarifications of why we made certain design decisions, details on subtle bugs that we deferred fixing and why they’re hard or risky, insight on weird player behavior, and so forth. A bunch of this knowledge only exists in my head, and since I risk lanesplitting a motorcycle across the Bay Bridge twice a day, it would probably be a good idea for me to share some of this information with the community ASAP, just in case!
A little about me, so that you can decide whether you want to read this blog. I work on the Flex compiler team. Everybody on my team tends to touch on code all over the product, but my main area of expertise is the low level construction of SWF files; how bytecode blocks are linked together with assets and put together to form something that the Flash player can consume. As such, a lot of the code that I provide here will be low-level Actionscript, without fancy MXML effects or deep use of the Flex Frameworks components. Before Macromedia (Adobe), I was doing a lot of network software development for the web, but my background is really rooted in game development, writing AI software for distributed defense simulators, and robotics. The applications I write don’t look like traditional Flex applications. You might have seen one of them (a fishtank running the Boids algorithm) used as a benchmark for the Flash player, up on the big screens at the conferences to demonstrate how fast the new VM is. In short, if you’re looking for how to write sophisticated and pretty business applications, this isn’t for you. If you want to learn how to exploit crazy un- and semi-documented tricks in Flash and Flex, keep reading.Next up, I’ll share some of my thoughts on how Flex applications will be built in the future.