The Flash Player Knows Enough About Itself To Generate Itself During Run-time #Adobe #Flash #CS5
Or that statement should be - The Flash player knows enough about the .swf file format to be able to generate .swfs during run-time.
I think this is a feature that Adobe should consider for future versions of the Flash player.
Let me explain:
There are a handful of new and really exciting features found in the new Adobe Flash CS5 Professional currently in Beta 2 (http://cs5.org/?p=179).
I know everyone's attention has been focused mainly on the new iPhone export feature - Don't get me wrong I'm excited about this too ;),
but I thought I should blog about one feature that I think is almost as exciting as the iPhone export feature.
Namely, the ability to save your Adobe Flash CS5 content (authored in the IDE) to an uncompressed format called .XLF - instead of the usual binary format .FLA.
The uncompressed/exploded .XLF format saves everything (paths to bitmaps, vectors and all other binary assets etc) in your project to an XML file project and you can re-open it up later on into the IDE, in a "round-trip" fashion.
View Adobe Flash Platform evangelist Lee Brimelow's most recent screencast for a detailed example here - (scrub to 7:25) http://www.gotoandlearn.com/play?id=118
Great, .XLF export is cool, but what can you do with it?
Use cases:
- Create tooling that extends the IDE, using the xml file generated from the Flash IDE as it's input and the output could be whatever you want to do with it really
For example, you could develop a tool (an AIR app perhaps or even a Web app?) that would generate a .swf file from the xml representation of the project (a bit farfetched I know but read on for more)
- Easier versioning control (no need to commit/import binary .FLA into your versioning repository - some purists hate this)
- Allow me as a 3rd party developer to extend my work-flow beyond what was earlier possible with the .FLA format alone.
However, I'd like this approach to be taken further, as hinted above, I would like it to be used in the same way as SWFMILL/MTASC combo generates a .swf from XML and vice versa but take it even further - to the Flash player during run-time.
Why can't the Flash player generate .swf files during run-time to be saved to a user's hard drive?
Ignoring all security implications for a moment.
a) The AS3 language is powerful and speedy enough (for example using the FileReference object in player 10 you can load and save files to users filesystem during runtime).
b) The low-level .swf file format is well-known (especially to Adobe) and could easily be mapped from binary to xml format (see SWFMILL and the .XLF file export mentioned above)
But why - Use cases?
- Since the format would only be an XML file, you could "write Flash" or any inner workings or representation of your .FLA/SWF from other tooling or any client-or server-side language and have it spit out the .swf on demand.
- The ability to add a very simple plug-in architecture, letting 3rd party developers extend your Flash work without your involvement - as long as they abide to your API.
Extension in this case could be skins, themes etc using Flash Builder 4 new Spark component architecture.
You may be thinking "why not use LCDS/AMF/AMFPHP/SWX etc etc. These are great client-server technologies but does not fit the bill here - which is to generate .swfs run-time same way as a server spits out XHTML, but with the added bonus
of using all of what we've come to love about the Flash Platform.
Amidst all this talk about competition coming soon from HTML5 as it relates to video and rich content on the Web and the future role of the Flash Platform for creating rich content applications,
I think re-visiting features like this would certainly be wise. After all, Macromedia (before it was acquired by Adobe) used to have a server solution called "Generator" that use to serve templatized content
and Flex 1 used to enable pre-compiled delivery of .swfs as well as run-time compilation of .mxml files to .swf.
