Adobe Flex goes open source
April 26, 2007 on 11:37 am | In Flex, Programming | 4 CommentsI have a release to get out the door this week, it’s almost time to go to the office, and I haven’t had breakfast yet. What am I doing writing a post right now?
It must be because Adobe has announced they’re open sourcing Flex. I have to hand it to Adobe: this is a great move on their part, for a bunch of different reasons:
- There’s a large, able body of developers who are ready to put their energy behind making Flex a standout platform. The quality and the feature completeness can improve greatly if the project is managed well.
- These days, information about a platform that remains proprietary and under wraps is an adoption barrier, not a competitive advantage. Although the framework code was already available, we didn’t have public access to the dev tool sources, the bug database, the development roadmap, and many other staples of OS projects.
- Flex vs. the competing MS Silverlight/WPF is no longer a mere feature comparison game, it’s a philosophy comparison.
- In contrast to the more balkanized AJAX platform world, this creates a clearly dominant open-source platform in the rich-internet-client space.
Now the big questions are going to be the little questions. For instance, from the Flex Open Source FAQ:
Our goal is to make the initial open source distribution as close to the commercial distributions of the Flex SDK as possible. Due to restrictions on some components that have been licensed from third parties or come from other Adobe products, some portions of the current free Flex 2 SDK may be made available in binary form only.
Hmmm…. what will those pieces be?
Anyway, I’m pleased and pumped that my favorite client platform of the present day is heading in a really constructive direction.
Wii be rollin’…
April 16, 2007 on 11:58 am | In Bicycling, Miscellaneous, Uncategorized | No CommentsI’ve just emerged from my thrice-weekly morning session with the bike trainer. It’s gotten a lot easier to deal with the boredom of stationary pedaling thanks to the Wii that we bought “for the kids”.
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…
An ActionScript interpreter, courtesy of JavaScript and Apollo
April 12, 2007 on 10:28 pm | In Flex, Programming, Uncategorized | 3 CommentsI’ve been experimenting quite a bit this week with Apollo, in preparation for a wee talk on the subject at Harvard. I’ve been building out that dependency analysis tool in Apollo and exploring the cool Javascript/Actionscript bridging capabilities in a series of examples.
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.
The Secret Life of SWFs: Flex 2’s undocumented SwfxPrinter tool
April 8, 2007 on 12:35 am | In Flex, Programming, Uncategorized | 12 CommentsIt’s apparently a well-kept secret, but the Flex SDK includes a very useful tool for examining the structure and contents of SWF files. The Java class flash.swf.tools.SwfxPrinter, which lives in the Flex 2 SDK’s lib/swfkit.jar library, is an undocumented utility that dumps AS3 SWF files as XML documents. These dumps can provide really useful insight into what is taking up space in a compiled AS3 Flash or Flex application.
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.)
Entries and comments feeds.
Valid XHTML and CSS.
All content copyright (c) 2006-2007 Joseph Berkovitz. All Rights Reserved.