I am very excited to return to the Platform Evangelism team at Adobe to pursue my passion of writing and exploring the world of software development.

I started writing software at age 9 on an Apple II+ at our neighbors house in Houston, Texas and if it hadn’t been for my grandfather buying me an Apple IIE, I might have moved into our neighbors house. I love software, I love writing it, learning new things about it, and I especially love sharing what I learn about it with others. It is an interesting time to return to evangelism as the Flash Platform is in the midst of a very large transition. We are in the middle of Flex 4 development, progress on Catalyst, Mobile runtimes, and Flash Collaboration Services are full steam ahead. In the overall market, RIA purpose driven apps are going mainstream vs traditional browser based apps. I don’t go to Twitter.com, I use Destroy Twitter; I don’t go to Facebook.com, rather I have an app for that on my phone; and services/apis are appearing for just about everything. Times have changed.

For the last 12 months I have worked on the community team at Adobe focused on growing our designer and developer ecosystem through our community leaders and Adobe User Groups. The community has grown dramatically over the past year and I want to thank each and every community leader who made that growth possible. Although our work is far from complete, I know that the passionate leadership within the community merged with new team leadership under Rachel Luxemburg (New Team Leader) & Ben Forta (Evangelism Honcho) can only result in a world class program for Adobe in the years ahead. Long story short community is in great hands. The year of management experience has been eye opening for me as I had to learn a very different toolset, and honestly, I could not have asked for a better team.

During my time on the community team I started writing software in my spare time. I would stay up late to writing code and learn new platforms. I certainly didn’t see it initially but after my wife Linda mentioned it, I really needed to make writing and exploring software my full time job. So today I am headed back to the Evangelism team to pursue that passion.

I was chatting with Ryan Stewart today on IM and this chat sums up my feeling well:

12:00:56 PM Ted Patrick: tis humbling to return to evangelism
12:01:00 PM Ryan Stewart: hahah
12:01:02 PM Ryan Stewart: why?
12:01:06 PM Ryan Stewart: you were the Flex evangelist king!
12:01:12 PM Ryan Stewart: now you’re back in black
12:01:24 PM Ted Patrick: oh just after all the projects
12:01:34 PM Ted Patrick: and management
12:01:45 PM Ted Patrick: It is nice to return to code

Well I am not sure about “Flex evangelist king”, yikes, but I am very happy to be back. It is an amazing team and there is no better job for someone that loves software development.

Cheers,

Ted

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:

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:

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:

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

When I write an application i tend to develop it in parts or units. At first I will focus on getting one part working and make sure to clearly understand its behavior, inputs, usability, and outputs. I will then move to assembling these units together into a larger application. In many ways it is very similar to Chafic’s concept of Application Components where a larger application is technically made of many subcomponents that contain larger sets of working parts.

I really like to both think and work on applications in parts as better interfaces (programming) result. I get one or two units of an application working and then merge them together into a larger build given unit stability and functionality are largely complete. Maybe it is my way of breaking problems down into smaller peices but it really helps me get to the end result quicker. Ideally I spend as little time as possible with a non-working app and rather focus on getting each unit working well before assembling these units together.

How do you build apps or parts of apps?

Cheers,

Ted

Over the past few years I have seem my share of memory related issues in working with Flash Player and AIR. In every case, the issue always boils down to reference handling in that somehow code was written (typically innocently) that holds a reference to an object indefinitely. In all systems with a garbage collector memory system, you need to be very careful how you work with object instances. Lets look at the details:

var arrayRef:Array = new Array();

Here “arrayRef” is a reference holding a newly created Array object instance. Within the Flash/AIR VM, “arrayRef” is actually a reference to raw block of memory within the player. Whenever you want to do something with the array instance, you use the “arrayRef” reference to read/write/execute properties and methods of the object stored in memory.

The real fun begins when references are passed around within the system like so:

//direct reference
var arrayRef2:Array = arrayRef

//property reference
var objRef:Object = {};
objRef.foo = arrayRef;

//event reference via method closure
mylistener.addEventListener( “woot” , customMethodOnReference );

//In AS3 all methods have “closure” and thus hold a reference to the object instance. If you pass methods, you pass an object instance! Method closures are a handy feature but they have reference implications attached. Be careful!

The lesson here is that you can pass references very very very easily, maybe too easily, and thus unless you are tracking down all instance usage, you will see app memory accumulate. This is especially true with application data objects where lots of data flows into the player via the network and data is consumed by an application. Each object created via network operation must be carefully watched and managed.

In terms of memory consumption no object is more problematic than XML/E4X. In Flash Player XML and E4X are an object with a collection of inner objects. They are trees of objects all with internal references. When they are used, you need to be careful how you access them and reference the objects they contain. If you set values based on data within XML/E4X, you will hold the whole XML object in memory unless you release the objects. There are a few reports of “Memory Leaks” within E4X when using certain XML features (I AM WRITING ANOTHER POST ON E4X and LEAKS…STAY TUNED) and some of these are bugs but a large majority seem to be misuse of reference of result XML objects. How you use the references within an XML object is really important and developers need to be careful what they hold onto. I tend to create new Model objects from E4X data queries and never reference internal E4X objects directly in code. This has helped my projects as a practice.

Flash Player and AIR release memory when all object reference to an objects are gone (not counting internal reference). The garbage collection occurs incrementally so as not to slow down the player as it processes ActionScript and renders graphics. The garbage collector within AS3 works via deferred reference counting backed by incremental conservative mark/sweep collector. For detail on the VM and Garbage Collector, this PDF is the best guide I know of. When objects are created you will see memory consumption rise within the Flash Player (via flash.system.System.totalMemory) as new memory is allocated from the system to the runtime. Player and AIR maintain a buffer of available memory for newly created objects and if there is nothing to collect (recover memory) the player will get more memory from the system. This will show up in the Profiler as rising memory but you will never see this value fall (via flash.system.System.totalMemory). Once memory is acquired by the player for use, it remains used and is recycled using the garbage collector. The key here is that you need to lower instantaneous memory consumption within your application and be very careful to allow the player to garbage collect over time. Adding too many objects at once will force player to generate new objects and acquire system memory if the buffer isn’t enough.

Long story short, you have full control of memory use within your applications through careful objects creation and reference management. The problem is it isn’t automatic and you need to be careful with references.

Regarding E4X memory issues, I am planning to post this week on the issue.

Manage your references!

Cheers,

Ted

https://freeriatools.adobe.com/learnflex/

If you are not working and our interested in learning Adobe Flex, Adobe is providing free versions of our professional tools to help you get started. It is great to see Adobe do this and help developers in need.

Learn Flex for free!

Cheers,

Ted