Well, today was my last day at Adobe. I’m taking a year off to race motorcycles and tinker with Ideas and think Big Thoughts.
I will be setting up a new blog at http://v0.net/rg where I’ll continue to post the occasional article on Flex and Flash (and who knows what else!) I’ll have contact info up for questions and contract gigs. 🙂
Here is an archive file containing my slides and demos from MAX. Hopefully they will be of some use to you!
Turn on the “notes” view in Powerpoint to see some accompanying description for the slides.
I’ve removed most of the assets and SWFs for a variety of size and copyright reasons, so you’ll need to tweak the projects a bit to get them to work.
So, my first attempt at live coding failed. It turned out it wasn’t the code – it was a silly thing I forgot to do in FlexBuilder in the heat of the moment! I wanted to show how trivial it was to write a dynamically loadable module that used bidirectional communication between the loader and loadee, so I prepared a WidgetShell (like a dumb portal) that would read an XML file containing a list of Widget SWFs to load.
Basically, FB doesn’t present a way for you to create a new ActionScript project where the main class extends a particular base class or implements an interface. You have to hand-add that. However, if you add a class, you get prompted and it will codegen the interface methods for you. Very handy when you’re on stage and can’t remember all the methods you need to implement for that module project.
So the trick I discovered was that you can delete the autogenerated class, and add it back at your leisure. For my preso, I left the (empty) project stub in place (which mostly just contained overrides of the src and bin directories) and planned to add the live-coded widget implementation.
I totally forgot that you then need to mark that new class as the executable application for the project! D’oh! It never even compiled my widget!
Oh well. Perhaps my 4:30 Thursday preso will be a bit more coherent and less coffee-addled. 🙂
Stay tuned, I’ll be posting my demo code as a zip in the next day or so. The copy of the preso in the library doesn’t have the best notes in it, so I’ll post that as well.
I’ve been incommunicado in the blogosphere because I’ve been tweaking the compiler to fix some issues discovered in 2.0 that would get in the way of modularizing your app.
If you’re one of the lucky few who have had a chance to play with 2.0.1, you’ll also notice that mx.modules is official!
IM IN UR BETA OPTIMIZING UR SWFS
I’ve put in numerous refinements since the prototype I posted to my blog a while back, including:
– Both low-level AS API and high-level MXML-oriented declarative API supported
– MXML modules fully work and do the CSS thang
– Runtime stylesheets are now possible and are built using modules!
– You can stream extra classes after the application by using the -frame configuration option.
– There’s a dictionary weak-key approach for releasing but reacquiring modules such that they may reload quickly if they didn’t get dumped via GC. This should be handy for apps where you’re only ever visiting one giant module at a time.
I’m pretty happy with it all, and hey, guess what? I’ll be talking a lot about modularizing your app (the general issue, but I’ll touch on mx.modules) at MAX in two workshop sessions titled “Techniques for Delivering Modular Flex Applications”, on Wednesday at 10:30 am and on Thursday at 4:15 pm.
In other news, I’ve decided to move over to the Player team. The compiler has started to stabilize, which is good for you but not as much fun for me. I’ll be dusting off my C++ and getting my hands dirty at a lower level. I’ve gotta say, I’m looking forward to it!
See you at MAX!
So, back to where we were going before the digression on ApplicationDomain. One effective way of partitioning an application is to create an application shell that dynamically loads modules.
What exactly should a module look like?
ApplicationDomains are pretty much a neverending source of confusion and suffering, but they provide an interesting palette of class definition partitioning.
Anyone building an application that dynamically loads SWF files needs to learn and love the AppDom rules…
There are lots of crazy ways that one can imagine partitioning an application into multiple independently downloadable chunks. At one end of the spectrum, perhaps every single class is in a separate file, downloaded on demand by a classloader. This would be pretty inefficient, obviously – class references have significant “locality of reference”; if you need one class, odds are pretty good that there are a bunch of other classes that you will also need immediately, and it would be much more efficient to package them all together.
Determining a good packaging scheme is a pretty hard decision for the compiler to make automatically. Perhaps you would run some sort of profiler on your application during development, and monitor the class references over time. By seeing when things are referenced, in what order, and more interestingly seeing when things aren’t referenced, you could build up statistics to use for computing the optimal partitioning scheme for how many SWFs your application should be built from, and what classes should be in which. I don’t know about you, but while that sounds like a fun research problem, it doesn’t seem like its very practical, and I’d hate to have to tell my deadline-obsessed boss how long it would take to “get it working”. (Not to mention the fact that the Flash AVM+ gets really grouchy if it touches an Actionscript Bytecode (ABC) block that contains unknown type references.)
Lets look at a much more practical way of partitioning things.
In most cases, the Flex compiler constructs applications by building a two-frame Flash movie, where the first frame contains a preloader (with download progress bar graphic) and the second frame contains the bulk of the application. This allows the application to start up fairly quickly so that the user isn’t staring at a dead window during SWF download.
However, the application is still fundamentally a single monolithic SWF file. This has a few benefits, but several down sides.
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!