Flash

Background

There has been some discussion about the state and future of ActionScript 3 and the Flash player from the Flash/Flex community recently. Ted Patrick is spurring some of this discussion - kudos to Ted for touching the community and getting a great response - and others at Adobe have also taken part. Several articles have also been posted such as:

• Joa Ebert: This is an outrage
• Nicolas Cannasse: The failure of AS3 ?
• Andre Michelle: AS3 Failure?
• Nate Lokers: Flash Scheme, Lisp, and jQuery-like $ugar
• Peter Elst: Making the case for ActionScript
• Keith Peters has also been talking on Twitter about this.

I have come to Flash somewhat reluctantly, being a fan of open software and environments. I have done a share of Microsoft work in the ancient past, but I generally enjoy a more open environment such as Java, Ruby, Python, HTML, JavaScript, et. al. I use Flash (and selected it as a technology of choice when I was architecting for a massive new release of our market leading debt collection software at Ontario Systems) primarily because of its ubiquity, power, and consistency across platforms. Flash reigns because of these three factors and they are the most necessary places for Adobe to concentrate its efforts.

From the Java fan club to the latest dynamic cult

However, ActionScript 3 as a language is less than exciting to me, as I have sought to avoid the drudgery of Java in the past and have yearned for more dynamic alternatives in Ruby, Python, Objective-C, and even Lisp. It was for this reason that I began working on Red Sun, a project to port Ruby to the Flash VM. My initial work on Red Sun centered on generating SWF files from Ruby. I implemented a SWF parser and creator with support for creating and modifying the ABC sections and other critical sections of the file format. The SWF format is tag based, so I simply ignored and passed through sections my tool didn't comprehend. The ABC (ActionScript Byte Code) section was fully parsed and could be modified and written out. The tool could also generate a new SWF from scratch and translate simple Ruby code into ABC functions.

This route was extremely illuminating to my understanding of the Flash player, but ultimately I found it was too difficult to actually complete a reasonable implementation of Ruby in time for my presentation at RubyConf 2008. So, in a flurry of activity that I had between jobs I instead ported the MRI Ruby interpreter from C to ActionScript 3. This task was completed and using Red Sun you are able to run a significant portion of Ruby in the Flash VM. The major limiting factors remain:

1. Dependence on Ruby 1.9 to parse and compile Ruby code into Ruby bytecode
2. Poor coverage of the Ruby standard library (implemented in C and only small portions ported to ActionScript 3)
3. Little production testing and likely large memory leaks remain

The interest in Red Sun was decent for the conference, but really I don't think anyone has used it. I have received sporadic questions about getting it running but that is all. I know that much of this is my own fault due to lack of promotion or compelling examples, so I am not really frustrated or anything. I learned enough in that work about Ruby and Flash and writing languages to make the effort more than worthwhile.

There is a big difference in the Ruby culture of openness and the closed source Flash player culture. Also, Ruby is driven by developers, albeit creative ones, and not designers like the Flash world. Few full time Ruby developers are trying to generate interactive graphics experiments for the web or enterprise RIA solutions. I think in general the allure of Flash is small for Rubyists.

Flash Forward!

So what does my experience lead me to look forward to in the future of Flash? It is a difficult question, as there are countless frustrating limitations of ActionScript 3 in relation to Java or C#, not to mention dynamic languages and even JavaScript. As others have pointed out, ActionScript 3 is in a limbo between the dynamism of JavaScript and the structure of Java. The ActionScript 3 prototype is hampered to near-uselessness but we are missing important object oriented basics such as method overloading, true enums, covariant return types, etc.

In terms of my current "day job," I care about advancing ActionScript 3 so it is easier to use, and upgrading the capabilities of the Flash VM so we can do our job more effectively. Primarily, what I find as major issues are related to working with Flex and its love of private variables and deep class hierarchies. Flex 4 is addressing some of this and I think it will be a big improvement.

What seems to be more important than changing ActionScript 3 are the broader issues such as performance, a global error handler, and possibly threading. Although everyone that begs for threading needs to consider the complete and utter breakage that will occur if it is enabled. If you think it is difficult to write asynchronous code, it is much more difficult to write proper multithreaded code. I see Flash and Flex code that will regularly break when multithreaded that used to make me cringe, having come from an inherently multithreaded server environment and also time working with Java. The Flash VM will be forced to break locks to keep from stalling the VM and that could easily cause major issues.

Speed improvements both to the AVM2 and to rendering would be one of the biggest attractions to keeping developers and designers on Flash. On a competing platform I have built effect mockups and received them from designers that had to be scaled way back for performance. This was extremely irritating and destroyed our vision. We were used to designing for Flash and this platform just couldn't keep up with our creative vision. I hear people ditching Flash for Silverlight for this very reason. C# does have some nifty language features, but you can still argue for Flash in general until performance kills you (which is rare, but happens).

Personal aspirations with Flash

I don't expect Adobe to create a language that I love, given the current direction, but fixing a few issues and spending their time on performance could really be a boon for the life of Flash. Adobe has put a lot of effort into MXML and it's easy and flexible binding is a great tool for building a DSL. Degrafa and Axiis are prime examples of the power of MXML. If Adobe can push the performance of the ActionScript generated by the compiled MXML it could be a saving grace.

I have been researching the possibility of creating an expressive language that is also efficient and interactive for visual experimentation. I then to think that the Flash player is the best environment for it, since sharing via the web is so ubiquitous. Processing already exists for offline rendering and I don't have any hope or desire to compete with it, but I don't think it works so well for integrating into the web (it does offer the best applet experience I've seen, however). The major downside of working in Flash is performance and device access. There are popular workarounds for accessing devices in AIR, but if my work will run in AIR and use a custom language I would rather just build a native executable.

The bottom line

I will favor Flash as long as the install base stays as high as it as and as long as it is fast enough to be compelling above Silverlight, JavaFX, and JavaScript solutions. The community can work around language frustrations and even build better frameworks alongside Flex or as replacements to Flex. Adobe can benefit from all of this excitement as long as the player remains the dominant technology.

This is a teaser for my upcoming talk at 360|Flex San Jose. I will be talking about how to improve your programming by reading the Flex source code. You should come to the conference (even if you aren't interested in my talk). There are lots of other great speakers.

Choosing a base class for your Flex component involves understanding the base classes that Flash provides. The primary classes in Flash that you should recognize are Sprite, Shape, and TextField. These classes are by far the most common in Flex code and you need to know what capabilities and limitations they have.

The TextField class is one of the most basic classes in Flash for dealing with text. The TextField class is designed for dynamic and potentially interactive text. The text can be selectable or not and it supports multiline text and text formatting using basic HTML and CSS. Its inheritance is TextField < InteractiveObject < DisplayObject.

The Shape class is the most basic Flash class that supports rendering through the graphics property. The Shape hierarchy is: Shape < DisplayObject.

The InteractiveObject class is a core class in Flash player. InteractiveObject is an abstract base class so you cannot create instances of it. Also, you cannot subclass it yourself because it is not a complete class. InteractiveObject is a subclass of DisplayObject and adds support for interacting with the user of the Flash application. Flash classes which are not subclasses of InteractiveObject, such as Shape and StaticText, do not respond to mouse or keyboard actions.

Some of the core classes in the Flash player are actually abstract classes. Even though you cannot instantiate these classes directly, they are still very important to understand. These classes are the parent classes for all of the visual display classes in Flash and they contribute functionality to the concrete classes that you will use in your application.

The display list is the mechanism that Flash uses to render itself onto the users screen. The display list is rooted in the Stage class and consists of all of its descendants (children, grandchildren, and so forth). DisplayObjects on the display list have a specific rendering lifecycle and event propagation mechanism. Objects which are not on the display list will not be rendered and cannot interact with user events.

More to come...

The Flash drawing API is the primary mechanism for rendering interactive graphics outside of the Flash editing environment. The drawing API is a low-level interface that draws primitives such as lines, curves, and triangles (in Flash 10). It can style those primitives with line styles and fill styles that get their content from vector gradients or bitmaps.

The Sprite class is one of the most basic rendering classes available in Flash. It supports the Flash drawing API, can contain other DisplayObjects, and supports user interaction events. Sprite does not have a timeline like MovieClip which makes it smaller and faster if you are not running timeline-based animations. The Sprite class is the base class which most UI components inherit from such as the UIComponent in Flex.

The addedToStage event fires when a component becomes part of the display list. The display list is rooted in the Stage component and contains all of its descendants. When your component is on the Stage it participates in the standard render loop and the event dispatching loop.

Keep in mind that even though your component is not in the display list, it can still be asked to render itself using the draw method of BitmapData.