10 Things A Good Flex Developer Should Know
10 Things A Good Flex Developer Should Know
Join the DZone community and get the full member experience.Join For Free
Bugsnag monitors application stability, so you can make data-driven decisions on whether you should be building new features, or fixing bugs. Learn more.
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.
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.
- Head First Java (Java? Yes, I know. But trust me.)
- Object-oriented programming with ActionScript 3.0
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.
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 programmingFlex 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.
- Flex Tips - Using Bindable Metadata Events
- Michael Labriola's presentation entitled Diving in the Data Binding Waters
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).
- Retrieving and handling data with HTTPService
- Retrieving and handling data with WebService
- Retrieving and handling data with RemoteObject
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 Jeremy Mitchell , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.