April 11, 2010

10 Things A Good Flex Developer Should Know

Posted by Jeremy Mitchell
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.See Finding the Most Popular Flex Framework

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.


zach said...

Good Job. I really like your take on almost every point. For me, adopting Flex was like a natural move and i am so happy.
Thanks for sharing your thoughts. Keep up the good work

levancho said...

some of the points are kind of obviouse, but overall it's good post, I would add e4x to the list though and remove mate

Jeremy Mitchell said...

@levancho - yes, i agree, most of the points are rather obvious to many of us. but for others, they're not so obvious. i guess the real mystery is what makes a "great" Flex developer.

Mohammed Fasil said...

Nice post.
I think the post title should be 10 things to become a good flex developer.

It would be great if you could post 10 best practices to be followed by a flex developer.

Thomas Burleson said...

Thank you for the nice.

RE> Every action is the result of an asynchronous event.
Actually that is not true: Flex has 4 categories of events: Framework, User, Business, and DataService events. Most of the Flex events are synchronous. RPCs are asynchronous.

Thomas Burleson said...

Assuming that a developer understands general event-driven concepts,
I personally consider 'Data Binding' (4) and 'Component LifeCycles' (10) as the MOST important concepts to understand in Flex!

Without a firm grasp of #5 and #10, non-trivial Flex solutions will fail.

Erich Cervantez said...

Interesting post...I will say some of it is obvious but then again many novice Flex programmers need to learn the obvious first.

I really enjoyed watching Colin Moock's Lost ActionScript Weekend - The Display List. I hadn't seen that before...thanks for posting the link.

Borek Bernard said...

Point 11: Get yourself familiar with automated testing using tools like FlexUnit and FlexMonkey.

Otherwise a great list.

Unknown said...

Great job really helpful...

Unknown said...

Great Job....Really helpful

Ganesh said...

Nice One..

Rajan Mariappan said...

Thanks for sharing your thoughts.

Chirayu said...

Really good post. I am a student and just starting out with Flex Development. Your post shows me the way. I am going to OOPS first. Do you think any more books would be advisable for each of Your points (I would really appreciate info regarding this)?

Anonymous said...

Completely agree with all points. I think expertise in *more* than one Flex framework would drive one to a deeper level of understanding.

adobe flex developer said...

I agree with you that there are several number which should to know by flex developer

Amit said...

Nice one... I even actually got stuck in the pool of the handling events in the mxml.

piscinas prefabricadas precios said...

Excellent job, nice post.