Ted Patrick - Demos & MAX @ Adobe Systems
Note: This is the personal blog of Ted Patrick. The opinions and statements voiced here are my own.
Flex - The Generative ActionScript Framework
DIGG IT!
11
Comments
Published
Monday, July 20, 2009
at
12:47 PM
.
If I were making a drink called Flex it would be 2 parts component, one part language (MXML), one part compiler, and 3 parts Flash Player. As RIA frameworks go, Flex is a bit different.
Today I want to dive into the unique elements of Flex and highlight the things that I think are critically important to understand. In many cases the patterns that operate within Flex are largely misunderstood and once you see them, the whole framework becomes much easier to use and more powerful. Here we go:
Flex is a generative framework and within each stage of the compiler code and graphics are translated into lower level application behavior. Basically you put MXML and FXG in and the compiler translates this into lower level features that mesh with Flash Player internals. Lets start with the 4 basic stages of the MXMLC compiler:
Stage 1 - Translate MXML to ActionScript Classes
Stage 2 (NEW in FX4) - Translate FXG to either ActionScript or SWF Bytes
Stage 3 - Compile ActionScript to ABC (Actionscript Byte Code)
Stage 4 - Embed media, graphics, bytecode into SWF
Stage 1 & 2 are the generative stages of the compiler and provide the foundation for many features of Flex that are not available in ActionScript alone like data binding, @Embed[], generating event listeners, member naming, AS class generation, component instantiation, and layout management. As all MXML is translated to classes, any component in MXML becomes a member variable via the @id attribute. Additionally MXML generation handles all component creation and instantiation logic and even supports lazy instantiation (see @creationPolicy ).
One of the key features during MXML to ActionScript Class generation is data binding. Binding works by isolating expressions within {} pairs and generating getter/setters to detect property change via the observer pattern. When a value changes on the target, it uses the expression to calculate a value automatically. example:
<mx:Button label="{ name.labelValue }"/>
What is very nice is that this code would take a ton of time to create and resuse reliably, yet leveraging code generation it seems easy and automatic.
Seeing is believing! Within your Flex project, I want you to add in a compiler flag "-keep" like so:
This flag tells the compiler not to delete the generated ActionScript classes within your project. This small flag lets you see inside the code generation in Flex. You will see a "generated" folder appear magically within your project and will find parallel ActionScript classes for all parts of your application. This feature exposes how your applications work internally and shows you that seemingly minor MXML changes result in lots more ActionScript.
Code generation is the lever within Flex and is the feature that I feel makes it so great. Why do I need to write tons of instantiation code when this can and should be generated consistently? In many ways this is raw productivity as it makes the language of creating RIA's simpler and removes the tedium of low level details (without removing anything). The other benefit is that this methodology takes nothing away from the developer, nothing! You are free to instantiate your components in raw ActionScript as you see fit but MXML automates this for you. In essence you can mix AS and MXML classes and extend Flex into the framework you need. No it doesn't do everything, what does, but it doesn't prevent you from adding more in.
In Flex 4 there are 2 new features that leverage code generation, States and Flex Graphics. The new states syntax allows you to define state transitions much easier in that you now define them within dot notation using the state name on properties you need to change over time. The compiler then takes these calls and generates transitions between states within your application. Simply adding in a value is all you do like so:
<Button label="DefaultLabel" label.A="A State Label" label.B="B State Label" />
This is key to much of the behavior within Flash Catalyst as a complete design tool. By just drawing you can edit and manage states with components or within components easily. Additionally feature support for @excludeFrom and @includIn are also supported to assist state management.
Flex Graphics add in a whole new graphics compiler into MXMLC and largely change the capability of Flex. Prior to FXG Flex has been largely dependent on the drawing API. Basically anytime Flex wanted to change a component state, it executed ActionScript based drawing instructions to draw a surface in Flash Player. In Flash Player 10 the drawing API was extended to support commands that were in sync with the full vector capability of Illustrator and the addition of persistent/editable drawing surfaces. Some FXG:
<Rect width="200" height="200">
<fill>
<SolidColor color="#FF0000" />
</fill>
<stroke>
<SolidColorStroke weight="10" color="#0000FF" alpha="0.5" />
</stroke>
</Rect>
The first generation drawing API allowed you to draw graphics additively on a single canvas, the second generation allows you to modify the graphics that have already been drawn. The other way to draw is using Flash Players native renderer, SWFBytes. Prior to FXG any embedded SWF assets could use SWFBytes that came out of Flash Professional. To provide flexibility FXG can be rendered at runtime via the drawing API or depending on how graphics are using in the app (skins) they can be compiled directly to SWFBytes. Typically SWFBytes are 3x faster in rendering than the drawing API, so there is a big performance boost for skinning in Flex with the compiler additions around FXG. Within FXG there is a concept of binding where a graphic can be changed in value at runtime. The generational stages of the compiler support this feature so that you can rotate graphics uniquely or change color / filter values with precision. I haven't said much about Flex Graphics but I really believe it is a groundbreaking change for Flex.
In summary, I feel that the generative aspects of the Flex compiler add the most value to the overall product. Development using either MXML or ActionScript interchangeably really opens many options for developers. You get the lever of code generation built into the framework itself adding some very compelling features (binding, event generation, etc). At the end of the day MXML is a high level language that removes the tedium from a developers workflow. Instead of working to instantiate components, I can focus on interaction and refine my applications productively. Long story short this is why I started using Flex in the first place and why I am still passionate about it as a development framework.
Cheers,
Ted :)
11 Responses to “Flex - The Generative ActionScript Framework”
Post a CommentWhere to find me:
Ted on Twitter - @AdobeTed
Ted on Adobe Groups
Ted on LinkedIn
Ted on Facebook
Ted at Adobe
Latest
- Development Unit by Unit
- Memory Performance in the Land of References
- Free Flex development Tools for out of work devs
- Design++
- Design an Application like a Movie
- My intellectual property and Why Adobe a great pla...
- Problem Solving
- Development Islands
- Development TODO Lists
- Where community and Catalyst meet
Lists
Links
Jobs
Flex JobsArchives
- May 2003
- June 2003
- July 2003
- August 2003
- September 2003
- October 2003
- November 2003
- December 2003
- January 2004
- February 2004
- March 2004
- April 2004
- May 2004
- June 2004
- July 2004
- August 2004
- September 2004
- October 2004
- November 2004
- December 2004
- January 2005
- February 2005
- March 2005
- April 2005
- May 2005
- June 2005
- July 2005
- August 2005
- September 2005
- October 2005
- November 2005
- December 2005
- January 2006
- February 2006
- March 2006
- April 2006
- May 2006
- June 2006
- July 2006
- August 2006
- September 2006
- October 2006
- November 2006
- December 2006
- January 2007
- February 2007
- March 2007
- April 2007
- May 2007
- June 2007
- July 2007
- August 2007
- September 2007
- October 2007
- November 2007
- December 2007
- January 2008
- February 2008
- March 2008
- April 2008
- May 2008
- June 2008
- July 2008
- August 2008
- September 2008
- October 2008
- November 2008
- December 2008
- January 2009
- February 2009
- March 2009
- April 2009
- May 2009
- June 2009
- July 2009
- August 2009
- September 2009
- October 2009
- November 2009
Thanks Ted.
This style of posts greatly helps my understanding of using flex, at times I feel I am wear padded gloves because I am not totally in control of the script and framework.
Its great to get information about the workings of flex under the hood!
Thanks again.
Wow, that -keep compiler option is fantastic, what a great bit of insight. Thanks for the tip!
In my opinion, the fact that mxmlc can generate ActionScript from MXML has nothing to do with the framework. In fact, you can write pure ActionScript projects in MXML without even using the Flex framework (the UIComponents, etc). You can even write a Flex framework project without using MXML.
While I appreciate what you're trying to explain in this post, I think that binding "Flex Framework" to "Generative" just adds more confusion to what Flex really is.
Thanks for the nice article. I think this should be expanded into a book called "Flex for Actionscript Developers."
As a seasoned AS guy, I've found mxml a little frustrating because I don't know what exactly is going on under the hood.
My options seem to be "think of it as magic" or "closely examine the generated code." I would love something in-between.
Flex books seem to come in two flavors. They are either for absolute beginners (people who have never even used Actionscript) or they are for advanced Flex developers who already know (or don't care about) the generated code.
I would love to see a book that assumes the reader is a seasoned Actionscript Developer who is new to mxml. Such a book would give a high-level overview of what mxml is doing.
In general, I get the point of what's going on, but at least once a week there's an mxml structure that puzzles me. Some choices in mxml seem random and contradictory. My guess is that they're not, but since I don't know what is happening under the hood, I can only guess.
The "magic" behind mxmlc is somethimes a lot of code that the mxmlc creates and in many cases an overhead that’s not always worth it. Data binding is a good example; it's easy and enjoyable but can create overhead and memory leaks, which will cause your application to suffer in terms of performance during initialization. My hope is that one day Adobe will make the mxmlc an open source code so the community can add new features or enhance the existing ones.
Nice article, Ted, about the new features. I was particularly intrigued by the inline state syntax, but felt there was something funny going on. I'd love to hear your reaction to my blog post about it: http://bit.ly/O5OE3
Elad,
MXMLC is open source and part of the Flex SDK. I know several teams that have changed behavior in MXMLC for productivity as you suggest. I know Farata has done work to autogenerate backends from annotations and Cynergy did work to generate complete CRUD from hybernate map files.
I also would love to see the generation paradigm apply to any framework implementation. It would be a boon for the flash ecosystem. In many cases folks want a leaner meaner SDK. The Flex of today is pretty enterprise heavy but Flex mobile should lighten this up and provide more options.
Ted :)
Jonathan,
The states syntax in FX2&FX3 was very hard to read and extend. As all state changes occurred in blocks, describing the delta changes on many components got very complex and hard to maintain. Being able to denote states where components are instanciated makes it much easier to edit given the location of the state values is on the instance itself. It also allows for more incremental change.
I stopped using States at FX2.2 because the syntax was so hard to maintain. The new syntax makes it much easier overall and I feel it adds much value to Flex4. I know we can debate this round and round but go build and app using states in Flex 3 and Flex 4 and you will see this super clear.
My take is that it is a great change.
Ted :)
Hi Ted, thanks for the reply :). What I meant by 'open source' is to allow developers to provide contributions that are more than patch fixes. I know developers are contributing but unfortunately contributions are very limited from the community.
In regard to SmartPhones, I can see how Adobe will have to start focusing on performance entrancement and hopefully create a whole branch, since SmartPhone will not tolerate large number of classes or memory leaks. I am curious to see how would Adobe handles memory misuse of an applications. Flash applications can easily drain SmartPhones batteries, which will make the OEMs pretty mad, since people will show up at the stores complaining that the device is malfunction. It almost seems to me that there is a need to monitor the memory and CPU usage before releasing an application to SmartPhones but it's a whole different discussion...
I'd love to discuss this more if we have a chance to meet sometime, maybe at MAX.
One comment, though -- you mentioned the "delta changes on many components" -- this seems to me you're suggesting the behavior of a component could depend on how that component has been changed over the history of states that have been visited. This is a big no-no in terms of state machine design, as each state is supposed to be a complete context. The explosion of states is one problem with FSM's being used practically in large systems.
I am eager to get into FB4 and adapt my hierarchical state machine (HSM) work to it, so hopefully we can have a good discussion at the next opportunity.
Thanks for hearing me out!
How is Adobe plans to handle FXG code on the iPhone. Since the player is not installed on the iPhone and you can't modify FXG during runtime since there no drawing API?!
It seems to me that there is a need to add an option to compiled all FXG as SWFBytes and not just skins. I wonder how projects like elips are going to handle FXG code when there is no access to drawing API during runtime.