Category Archives: Adobe Flex

Adobe Flex : Remember that the MXML inherits from the base logic class.

What this means is that as you add children components to the MXML and you want the ActionScript Logic to manipulate them you have to make sure the ActionScript has them declared. To declare them you have to define properties in the ActionScript class whose name matches the component id you use in the MXML. For example, look at the Button id in the MXML above and notice that I have a public property in the ActionScript with the same name. The property must be public in the ActionScript class and you should mark them as [Bindable] so that if you have other components binding to them the change watcher system still operates as expected.

This works because the MXML file is an extension of the base logic class and the components with the matching id is equivalent to overriding the properties in the ActionScript. You may wonder why the properties have to be public and not protected if this is an override. The issue is that the MXML components are not part of the MXML class, they are children of the MXML class. Since they are children they do not have access to the ActionScript class’ protected methods and the compiler will see their id as a duplicate name for the MXML class, which is invalid. If the method is public, the compiler interprets this MXML component id as an override and it works. So, long story short… always make the properties [Bindable] public.

Tagged , ,

Adobe Flex : Never try to manipulate the children components from the ActionScript constructor

This is a common mistake made by developers using this pattern. For example, you try to set the button label in the constructor. If you tried this you would get a null value error for the button since it has not been created yet. MXML creates the children components in the initialize() phase so the best way to work around this is to override initialize(), call super.initialize() first and then you can start accessing children components.

Tagged , ,

Adobe Flex : Coding Conventions

The Adobe Flex Team has taken the initiative to create a Coding Convention for Flex solutions.
Its not yet complete, and some places they still have some TBD’s… however, the stuff thats already available should be read and understood by every Flex developer.

We are not following all of them rigidly on my team, however.. we will use the Coding Convention from Adobe to assess the places where we defer and check their validity in contrast to the Adobe Coding Convention.

Check it out…

Tagged , ,

Adobe Flex : Never try to removeChildren() that are defined in MXML

This is a mistake that sometimes works when you try it but in most cases this just causes a lot of heartache. Usually the heartache occurs after you have been doing this for a while and you then have to go back and fix a lot of code that was dependent on the first removeChild(). Unfortunately I have seen this first hand and its not a pretty sight. If you are doing a lot of children manipulation then you will want to move away from MXML declaration and handle the children creation/removal all in ActionScript.

Tagged , ,

Adobe Flex : Event/Action binding in MXML and AS

Try to avoid mixing and matching MXML and ActionScript event/action binding. This is also more of a recommendation then a requirement. If you start binding the creationComplete or click events in MXML try to bind them all in MXML. If you bind your events in ActionScript try to bind all of them in ActionScript. Once you start mixing and matching it can be hard to track down code flow later on. You may find yourself wondering why an event keeps triggering because you left it in MXML and forgot about it. In my above example I bind the click event. You can easily do this in the initilize() method using addEventListener(). Use what works best for you.

Tagged , ,

Adobe Flex : The Code-Behind Pattern

The Flex code-behind pattern is a design pattern that is not known or used by a lot of developers. The initial concept of the pattern was based on the ASP.NET development pattern where the layout is handled in a main file and a secondary “backing” file handles all the logic. The goal of the pattern is to create a clear separation of logic and layout.

When you first learn Flex there is often confusion between what MXML is and how it relates to ActionScript. We tend to think of it as different entities, but the reality is MXML is just an abstracted form of ActionScript. MXML is a declarative XML syntax that is converted by the compiler into an ActionScript class. This is an important concept to understand because this is the root of why the compiler throws an error when trying to have a MXML file and an ActionScript File with the same name in the same package. The MXML file is really just an ActionScript class and therefore we have a conflicting namespace error.

To help visualize this, imagine the root node of the MXML file is the same as an extends statement.

When we use something like this in MyApp.mxml:

<mx:Application xmlns:mx="">

We are really saying:

public class MyApp extends Application

So why do we need an MXML syntax if it just becomes ActionScript. As you are probably well aware, doing complex layout in ActionScript takes a ton of code, especially when you get into the world of nested layout. It can be done in code but why would you want to? XML is all about parent/child hierarchies and by using this as a layout language you can quickly define complex organizational structures that would have taken hundreds of lines of code if you did it all in ActionScript. Now that we have a better understanding of the MXML/ActionScript relationship we can start talking about how the pattern is implemented.

When looking at Adobe’s MXML examples we often see them using the tag to define any ActionScript that is required to make the MXML example work. This approach is fine for simple examples but once we begin development of a larger application using Flex, having all the MXML logic in a single tag becomes unwieldy. Even if the code is written by the most organized developer, once you hit 300+ lines of ActionScript with 100 lines of MXML it becomes hard to see the forest from the trees.

One way to solve this is to use the source attribute in the tag and set it to an external AS file. This helps because you now have separated all your ActionScript out of the MXML but now you have externalized AS files that aren’t really classes, that sit in the file structure and you can’t extend from them.

The Code-Behind pattern is a solution to this issue. The first step is to create an ActionScript class that extends the base type that you want your MXML file to be. For example, a Canvas:

package com.hello.demo
import mx.containers.Canvas;

public class MyComponentLogic extends Canvas


I have now created a Class in the com.hello.demo package that extends from Canvas. This is my backing logic class that my MXML extends from. Note that I have used the postfix “Logic” to create a unique name. If you recall, our MXML and AS have to be different names. I prefer the “Logic” postfix but you can use “Base” or “Backing” or any other postfix/prefix you like. Now, you can create the MXML file. In this example let’s assume the MXML component is in the same package as the ActionScript:


This code would be in an MXML file called MyComponent.mxml. The MXML now extends from the ActionScript and we can begin to start laying out content and adding logic as needed.

Some alternatives to the technique I describe here, is to use the Supervising Controller pattern or the ViewHelper. However, a sidenote to the Supervising Controller is that you should probably choose to call the classes for …Presenter instead if …Controller as the use of Controller seems to put some people of if they are not familiar with this pattern and leading them to think they are FlowControllers or ApplicationControllers. Read more about the Supervising Controller pattern at Martin Fowler’s excellent website…

Tagged , ,

ItDepends : A tool for visually exploring the dependencies between classes and packages in an Adobe Flex application

Currently I am converting an existing application with about 3.500+ classes to use RSL’s. It’s proven to be rather difficult because we are using a lot of different libraries and modules with quite a number of dependencies between libraries. Despite no libraries having direct circular dependency, there are some indirect dependency-circles in the system.

When moving to a RSL-based architecture it becomes extremely important to understand the class-definitions included in each library and modules.. and more importantly to know exactly when they are both loaded, needed and used.

ItDepends is a tool for visually exploring the dependencies between classes and packages in an Adobe Flex application.
It’s a great aid when undertaking my task, but even during the normal development of modular applications it can be valuable to use it when considering how to break up the application to increase performance as well as general system quality.

Check it out…

Tagged , , ,

FlexCover : A code coverage tool for Flex, AIR and AS3

Flexcover is a code coverage tool for Flex, AIR and AS3. It incorporates a modified version of the AS3 compiler which inserts extra function calls in the code within the SWF or SWC output file. At runtime, these function calls send information on the application’s code coverage to a separate tool; The modified compiler also emits a separate “coverage metadata” file that describes all the possible packages, classes, functions, code blocks and lines in the code, as well as the names of the associated source code files.

Check it out…

Tagged , ,

Adobe Flex 4

Flex 4, codenamed Gumbo, is now beginning development.
Some themes are being considered, such as…

* Design in Mind: provide a framework meant for continuous collaboration between designer and developer. Probably involves an additional component model that integrates with the existing Halo components.
* Accelerated Development: take application development from concept to reality quickly. Features could include application templates, architectural framework integration, binding improvements.
* Horizontal Platform Improvements: features that benefit all application and user types. Features could include compiler performance, language enhancements, BiDi components, enhanced text.
* Broadening Horizons: expand the range of applications and use-cases that can leverage Flex. Features could include finding a way to make the framework lighter, supporting more deployment runtimes, runtime MXML.

When the first Beta 1 of the Adobe Flex 4 is going to be rolled out later this year, I plan to do some some workshops on my team where we take all the new features and address them methodically one by one. It has proven to be a very effective method to acquire knowledge about a framework to use a top-down approach resembling brute-force attacking from A to Z.

If you are interested in learning more about the Adobe Flex 4 project, check it out here…


Thunderbolt : A logger extension for ActionScript 2 and 3

ThunderBolt is a logger extension for ActionScript 2 and 3 as well as Flex 2 and 3 applications based on the Firebug add-on for Firefox.

It looks very promising, and knowing Jens Krause’s ordinary high level of ingenuity and as well as quality, I am willing to give it a shot.


* Detailed information (class, file, line number, time, frame)
* Log levels (info, warning, error, fatal)
* Interactive tree view for complex object structures
* Profiling (time spend during code execution)
* Collapsible grouped output
* Filter log by classes and packages
* Interactive console (inspect and modify object on runtime)
* Tree view for complex object structures such as class identifier and its properties
* Custom LogTarget based on Flex Logging API including filters
* memory snapshot
* stop logging flag
* SWC components for logging using Flex 2/3 or Flash CS3

Tagged , , ,

Get every new post delivered to your Inbox.

Join 523 other followers