Over a million developers have joined DZone.

10 Things A Good Flex Developer Should Know

DZone 's Guide to

10 Things A Good Flex Developer Should Know

· Web Dev Zone ·
Free Resource
More Flex posts by Jeremy Mitchell can be found on blog.flexdevelopers.com

It takes more to be a good Flex programmer than simply knowing how to use some built-in Flex containers and controls. It takes significantly more.

Here's my take on the subject...along with some resources or some keywords that you can easily Google.

Please comment on this blog if you feel like I've overlooked anything (which is inevitable) or if you know of some valuable resources that I should add.

1. Object-oriented programming (OOP)

The language on which Flex is based, ActionScript 3, is a fully object-oriented language. Although not an easy concept to grasp, object-oriented programming is a prerequisite to learning Flex. If your prior experience includes OOP (Java, C#, Ruby, etc), then you're set. If not, you'll need to pick up an OOP book and start learning ASAP.

Note: Some of you may be asking - "What about design patterns?". Let's take one step at a time, shall we? Concern yourself with understanding classes and objects, interfaces, inheritance, composition, polymorphism, encapsulation, etc. Only then should you even consider looking at design patterns. In fact, if I write a post entitled "10 Things A GREAT Flex Developer Should Know", design patterns will be on that list.

2. ActionScript / MXML

ActionScript is the programming language used along with MXML to create Flex applications. MXML is tag-based declarative language written in XML. Each MXML tag is mapped directly to a corresponding ActionScript class. MXML is primarily used by Flex developers to lay out the UI, whereas, ActionScript is used for business logic. Exceptions apply, of course.

The Flex Framework includes hundreds of ActionScript classes and interfaces used to develop Flex applications. Your skill level as a Flex developer is tied directly to your proficiency with ActionScript and MXML.

Note: Get comfortable with the Flex Language Reference. As a Flex developer, you will use it on a daily basis.

3. Debugging

A large portion of any developer's time is spent debugging. Obviously, debugging is required to track down the root cause of bugs. However, debugging is also a great way to learn a new code base.

Fortunately, there are many tools available to assist you with your debugging efforts. Invest some time in learning these tools. Your investment will pay dividends immediately.

4. Event-driven programming

Flex applications are event-driven. Every action is the result of an asynchronous event.

As a Flex developer, you must know how to respond to events and how to create and dispatch events. To accomplish this, a solid understanding of Flex's event architecture is required including familiarity with the following concepts:

  • Built-in events (Flash Player or Flex Framework events)
  • Custom events (Events created by the developer that extend the Event class or one of its subclasses)
  • Event dispatchers, event broadcasters (See EventDispatcher class and its dispatchEvent method)
  • Event listeners, event handlers (See EventDispatcher class and its addEventListener & removeEventListener methods)
  • Event Flow (capture, target & bubbling phases; target vs. currentTarget)
  • Event objects, event types (See Event class and subclasses)
  • Event default behavior (See Event class and subclasses and its preventDefault method)

5. Data binding

On the surface, data binding is a no brainer. Bind the value of one property to the value of another property using curly bracket notation. When the value of the source property changes, so does the value of the destination property.

However, there is overhead associated with data binding and indiscriminate use can have performance implications. A solid understanding of data binding will help you determine when it is appropriate and when it is not.

6. Item renderers

One characteristic of a well-designed Flex application is the presentation of data in a visually-compelling manner. Flex provides a number of list-based controls (DataGrid, List, TileList, HorizontalList, etc) responsible for the presentation of data. However, only with the help of an item renderer can a list-based control customize the display of the data.

You will spend a lot of time working with item renderers. Get very comfortable with how they work.

7. Accessing remote data

Do you know of many applications that don't interact with data? Me neither. Learn how to retrieve data via HTTPService, WebService and RemoteObject. A Flex architecture framework may also help you with this (see #9).

8. Styling / Skinning

Let's not forget that Flex is a UI technology and as such certain design expectations exist. As a Flex developer, you should be able to customize the look and feel of your Flex applications using CSS styling and/or graphical or programmatic skins.

With Flex 4, there are no more excuses. Spend a little time getting to know the right side of your brain for once. It's a nice change of pace, and it will help differentiate yourself from other Flex developers.

9. At least one Flex architecture framework

Most Flex architecture frameworks enforce a separation of concerns by implementing an MVC (model-view-controller) application design. In addition, many of these same frameworks dictate how your code should be organized and packaged within your Flex project.

Although many would argue that frameworks are unnecessary, I believe that Flex developers benefit in many ways from the experience of using one. Simply witnessing the techniques (good or bad) employed by a framework to solve complex architectural issues contributes to your growth as a Flex developer / architect.

Also, it's hard to deny the fact that framework experience will substantially increase your marketability as a Flex developer. Jesse Warden recently told me "There are a few shops that don't use frameworks, but those are rare. It's in 'fashion' whether we like it or not." I agree with Jesse.

10. Component lifecycle & the display list

I wasn't convinced of the need to learn the Flex component lifecycle or the display list until I wrote my first "custom" component (actually, it was a semi-custom component that extended Canvas). Until that time, I used built-in Flex components and blissfully lived in MXML land where the display list was handled for me. Never once did I encounter an addChild, createChildren or commitProperties method, and I used the creationComplete event for everything.

My first custom component utilized a handful of asynchronous events, and I could not reliably predict the order in which each event would be handled. Only after I learned of the Flex component lifecycle methods and dirty flags could I regain control.

These lifecycle methods are already there. Learn how they work and use them to your benefit. Your life will be easier and you'll lose less hair.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}