Many of my speaking topics have to do with architecture, patterns, or some kind of preaching about best engineering practices. I love all that, but, to be completely frank, it feels a bit abstract and windy sometimes. I like to build concrete stuff that does something useful, and that’s where my real interests lie. (”Dammit, captain, I’m an engineer, not a methodologist…”) So this year I’ve made a pact with myself to only do talks about real live projects.

At 360 Flex I’ll be sharing a detailed case study of the architecture and implementation inside the most challenging and interesting product we’ve built at Allurent to date: the Allurent Display Platform. This system includes an engine that visually renders XML markup as Flex components — but unlike MXML or HTML, the markup resolves bindings to nonvisual data objects (usually products or product categories) that can live anywhere in a “virtual namespace” of content. Allurent Display also includes a fully-featured visual authoring tool for this markup similar to Flex Builder Design View.

This talk is a case study, not a product demo: I will be sharing the big decisions we made, the Flex or Flash technologies we used, the implementation tricks we had to resort to, the alternate approaches we considered (maybe the audience will propose something better). I think it’ll be a fun time. Anyway, hope to see you there, if this kind of thing interests you!

“The pain, the pain…”
– Jonathan Harris as Dr. Zachary Smith in the original Lost in Space

Dr. Smith was famous for whining, and so am I. Here’s my latest: Flex Builder does not work very well with multiple source folders in a project’s path. Probably the worst breakage is that integrated SVN source control (via the Subclipse plugin) doesn’t work inside them (FB-9989). Second worst would be that library projects can’t compile classes from multiple source folders (FB-9988). Yet another baddie: FB-5564: if you use Ctrl-click to navigate to a definition in a class which is in a linked source folder, a new window is opened unnecessarily, as if FB didn’t know that two files were actually the same. All this is too bad, because source folders are a really good solution to another serious problem with Flex Builder, and one that is probably harder for Adobe to fix: poor performance with multiple library projects.

If you’re using Flex Builder on some large applications with a number of library projects, you may have noticed it gets real slow. Yeah, I’ve noticed that too. It’s too bad, because using lots of small-to-medium libraries forces developers to be much more careful about dependencies between packages.

At Allurent, our approach to this problem has been to structure our Flex Builder projects for speed rather than strict dependency checking. We use Ant for all production builds (it builds multiple .swcs for dependency checking), while developers can use Flex Builder for incremental builds while they work on a project, if they want. To get around the big slowdown problem, we create mega-projects that include all the libraries’ source code directly via multiple source paths. While such projects are slow to open and start up, once you build them and warm up Eclipse’s caches they perform quite well.

The big fly in the jam jar — I know it’s usually ointment that metaphorical flies get stuck in, but that phrase gets kind of old, doesn’t it? — is that source folders are kind of semi-functional in Flex Builder. The fact that Subclipse doesn’t treat the contents of source folders as versioned (even if they are) is really frustrating. Maybe some folks out there are frustrated too. If you are please consider voting on the above bugs!

But today, courtesy of the New York Times, I read:

About five billion years from now, astronomers say, the Sun will run out of hydrogen fuel and swell temporarily more than 100 times in diameter into a so-called red giant, swallowing Mercury and Venus and dooming life on Earth, but perhaps not Earth itself. Astronomers are announcing that they have discovered a planet that seems to have survived the puffing up of its home star, suggesting there is some hope that Earth could survive the aging and swelling of the Sun.

So it appears that Earth may instead be destined for some kind of galactic curbside recycling bin.

If so, I think it would make sense for us to leave the planet in some kind of reasonable shape after all. You wouldn’t recycle filthy, unwashed food containers out on the street, where they would attract flies. Would you? No, I thought not. Likewise, you shouldn’t leave a nasty, polluted planet lying around the solar system where it might attract… well, I’m not sure what. Anyway, my plea stands: let’s clean this place up so it’s ready for recycling. We can do this any time in the next 5 billion years or so.

No, dear reader, I am not in fact coordinated enough to play Zelda or Wii Sports while pedaling furiously. (OK… make that semi-furiously.) What I am able to do is surf the web using the Wii’s built-in web browser, pointing and clicking the Wii Remote in one hand while maintaining pace and position on the bike. And this, from my point of view, is one very good reason to get hold of one of these gadgets. Now I can read a wide variety of stuff while doing my workout, and exercise free choice over it. That’s progress!

There are plenty of other reasons to check out the Wii. The remote (which has 6 degrees of free motion as well as buttons and internal accelerometers) is a really interesting input device, and it can interface via Bluetooth with a PC or Mac, and folks are coming out with some great homebrew hardware and software to provide connectivity for developers. Combine the remote with Flex, WiiFlash and Papervision3D, and suddenly you’re looking at an impressive 3D visualization platform. Hmmm…

Something amusing came up in the course of exploring script bridging: because JavaScript has the eval() function, and because AS3 objects are visible in an Apollo HTML DOM as fully fledged Javascript objects, one can easily use eval() in a Javascript context to evaluate live AS3 function calls, property assignments, and so on. Very, very nice!

For example,

<head>
<script>var obj;</script>
</head>

<body>
<input id="expr" type="text" size="80"/>
<a href="#" onClick="eval(document.getElementById('expr').value)">
  Evaluate
</a>
</body>

If you stuff this HTML into an HtmlControl, set that control’s window.obj to some AS3 object (say a Label for argument’s sake), then you can eval expressions like obj.setStyle(”fontFamily”, “Tahoma”) inside the HtmlControl and watch them take effect before your eyes. Should be a great debugging hack in Apollo.

If you’re in the FLEX_HOME/lib directory you can run it as follows:


java -classpath asc.jar;swfkit.jar flash.swf.tools.SwfxPrinter [options] swfFilename


Here’s a somewhat random excerpt from some output; this includes some Flash sprite definitions:

  <DefineSprite id='28'>
    <!-- sprite framecount=1 -->
    <PlaceObject2 idref='27' depth='2' matrix='t0,0'/>
    <ShowFrame/>
  </DefineSprite>
  <ScalingGrid idref='28' grid='(80,80),(1200,360)'/>

The valuable -showoffset option causes the output to include the offset and size of each element in the file. For instance, the following DefineFont3 element shows the size of an embedded font from a Flex CSS stylesheet:

  <!-- offset=86441 size=35356 -->
  <DefineFont3 id='112' font='Myriad' numGlyphs='232' italic='false' bold='false' ansi='false' wideOffsets='false' wideCodes='true' shiftJIS='false' langCode='0' hasLayout='true' ascent='17019' descent='5120' leading='614' kerningCount='0' codepointCount='232' advanceCount='232' boundsCount='232'>

Sadly, in a regular application SWF, there is no information about how the code is broken up; all you get is a single element representing the entire code of the application in a single lump:

  <!-- offset=291066 size=1338571 -->
  <DoABC2 name='frame2'>
  </DoABC2>

Not to worry. Far more useful are the results of using SwfxPrinter on the SWF that’s inside a SWC (just use any ZIP decompression tool to unpack library.swf from a SWC file). Now you’ll see information like this:

  <!-- offset=2130104 size=4192 -->
  <DoABC2 name='mx/effects/CompositeEffect'>
  </DoABC2>
  <!-- offset=2134296 size=670 -->
  <DoABC2 name='mx/effects/Parallel'>
  </DoABC2>
  <!-- offset=2134966 size=4111 -->
  <DoABC2 name='com/allurent/containers/AnimatedViewStack'>
  </DoABC2>

Now that’s more like it!

So… I’m in the process of writing an Apollo-based tool that analyzes SwfxPrinter dumps, along with the linkage dependency information found in a SWCs, and allows developers to analyze both code size, linkage dependencies and associated source code/documentation in a single environment. Granted, it would probably make more ultimate sense to do this as an Eclipse plugin alongside Flex Builder, but which would you rather do to read in swfx dumps: deal with the Java XML APIs or hack some E4X? Also a lot of the analyzed information is easy to display in HTML, and Apollo has that nice built-in web browser.

Here’s a screen shot of some work in progress:

One can use a tool like this to find out exactly how much space each individual class or package in the application takes up, and use that to tune its space requirements, Module loading strategy, and so on — this takes a lot of work, of course, but it’s a lot easier with the right information at one’s fingertips.

I’m thinking about the dependency-analysis angle. My current thought is to support two complementary approaches: 1) discover what other classes a given class/package depends on (and thus drags into the SWF), and 2) discover which dependencies caused the inclusion of a given class/package in the SWF. The first approach is useful when one has a good heuristic notion about what should be separated out (like a complex but rarely displayed view). The second is useful when you can see a large bunch of code and you’d like to understand what other stuff is using it, so you can separate out that stuff and avoid dragging the expensive code into the SWF up front. Either way, you identify candidate classes for modification, removal, or placement in a loadable module, in the name of a smaller download size.

Note: A somewhat more convenient way to run SwfxPrinter is to just copy this swfxprinter.jar file into FLEX_HOME/lib; then you can run it in any directory as follows:


java -jar %FLEX_HOME%/lib/swfxprinter.jar [options] swfFilename


(I’m not redistributing any Adobe code here of course; the JAR file just contains a manifest with references to class and library names.)

Some links:

• CSRF exploits and crossdomain.xml
• Death of open crossdomain.xml’s?
• YouTube, crossdomain

Possibly due to an exploit, they abruptly changed their crossdomain.xml file to only allow access from the youtube.com domain. As a result, YouTube developer API calls from Flash no longer work if the SWF was downloaded from a non-youtube.com domain. This broke a few aspects of ReviewTube that used that API.

I quickly got around the problem by proxying the YouTube requests through my own web server. Recall that ReviewTube was created to demonstrate an architecture for remote Flex applications. Well, in a validation of that architecture, it took changes to about 3 lines in 3 source files to make this change. Two changes were to code in the Service layer, and one change was to the component configuration file. (Full disclosure: also about 10 new lines of Rails code on the server side to do the proxying.)

So… we’re back live.

YouTube, if you want to be safe and not screw up Flash/Flex developers, please move your API to a different domain and put a liberal crossdomain.xml on that host. Thanks.

This morning broke with a crystal-clear blue sky: my prayers for good weather had been finally answered, or so I thought. I dropped off the rental car in Durango and rode to the rendezvous in back of Mountain Bike Specialists on Main Street to meet the Western Spirit truck, the guides, and the other folks with whom I’d be riding the next 5 days. Our guides were Rachel, Scott and Jason; Rachel and Scott were a married couple looking to be in their 40s and were veteran guides for Western Spirit, while Jason was in his 20s and guiding the route for the first time. (more…)

If you are rolling your own ICollectionView implementations like we are, this means you’d better extend flash.util.Proxy so you can implement []. Fortunately we already had, for other reasons.

Furthermore, data paging is not respected for these child node collection views. Whatever you return from getChildren() will be scanned in its entirety, and any ItemPendingErrors thrown during the process will be ignored. So you’d better not return some huge collection there that you hope will be paged in gradually as the user scrolls through the expanded node’s children. Ain’t gonna happen that way. This probably does affect FDS remote collections, so if you return one of those from getChildren() it might not page in the way you’d hope for.

Suggestive patterns in my tea leaves have led me to retain hope that this will be fixed in some reasonable timeframe. I’m working around the problem for now.