On Creating Flex Applications

I get a number of questions from people with large Flex applications that have run into a problem. For example, someone might have a TabNavigator and sometimes one of the tabs doesn’t show up or a tab remains even if the child component has been removed.

Isolating the problem can be difficult because the Flex application is large and requires data from a server or some other resource that makes it nearly impossible to send to us in Flex Product Support.

If you are involved in a large-scale development project (or think you will be), then STOP. Don’t go any further. I’ve got some advice.


There are a number of books and papers about software development and they have fancy names like the waterfall method, or simply unit testing. These are good, sound, tested techniques that might at first appear to be so much academic fluff, but there is a reason people went to the trouble of creating these design and development patterns.

I’m not going to write another book on the subject, but rather distill them into something I hope makes sense and is easy enough for you to implement. This is how I work on a problem.

The Steps (or the Zen of Development)

The first step is research. That is, figuring out how something is going to work before incorporating it into the application. For example, suppose I think I’ll want to use a Move effect. I’ll write a separate application to explore how the Move effect works. I’ll try out its options and may be I’ll discover that it doesn’t work as I thought it did. Or may be I’ll discover that what I really want is a Move + Zoom effect and then I’ll figure out how to use Sequence or Parallel effects. The point is, I look at the application and think about the parts that I’m unsure of. I may not know if a DataGrid with 30 columns will perform well or even been easy for the end-user to use. It is this exploration of the possibilities that can give you a better feel for how Flex works and really build up your skill set.

The second step is organization. I try to think of the parts of an application as coming from 3rd party vendors. If I need a DataGrid with special features I think about it as if I could buy it from someone. This is also known as the black box approach. In other words, I don’t want any other part of the application to be able to muck with the insides of my special DataGrid. Nor do I want my special DataGrid to know anything about the rest of the application. Thinking about it this way isolates each major part and leads to the next step.

Hint: This is where custom events come into play. A custom event helps you identify what action is happening that relates to the new component classes. A custom event can be as simple as a new event type (eg, "inventoryUpdate") or it can contain additional information (eg, the part number and name of the item being updated). Each component or group of components should have their own custom event(s).

The third step is interfaces. This is how parts mesh or fit together. It involves how one black box component interacts with another one. Obviously there are parts of a component that have to be publically exposed. Think about the Flex componets. The DataGrid does not know a thing about your application. All you can do is interact with its public functions, properties, events, and styles. If you discover that the DataGrid does not do something you want, you can create your own class, extending DataGrid and add those features. But you should create your class with the same intention – expose just those public functions and properties that get the job done.

Hint: Using actual ActionScript interfaces can really help keep parts of the application isolated. An interface provides the contract between a component and its users, but it also allows the component developer to change how the component works (or to fix bugs) without adversely affecting the rest of the application.

The last step is testing. That is, testing each of these units. Write stand-alone applications to try your components out separately and in logical combinations as they might be used in your larger application. You may discover flaws, shortcomings, or eliminate unnecessary features at this stage. If you’ve done the research step, then you’ll already have most of the testing code in place.

Hint: If in the testing phase you run into a problem you cannot solve, you have a self-contained example that you can send to someone for help.


The benefit to this approach is that you have a much more reliable application. Plus you may have created reusable components for a future application.

Further, should you need the services of the Flex Support Team, you’ll have ready-made test cases that you can send to us so we can quickly help resolve the problem.