Top 10 Mistakes when building Flex Applications

In this post, Adobe’s James Ward teams up with InfoQ.com to bring you another Flex Top 10 (our most recent Flex Top 10). Flex is an open source application development framework for building rich Internet applications that run in the web with Flash Player, or on the desktop with Adobe AIR. Overall, Flex is a powerful framework that is easy to use, but today let's focus on some of the common mistakes that are made when building Flex applications. 

For those new to Flex, check out InfoQ’s recent Adobe Flex Basics to get a quick introduction to the framework. Here is the list:

1. Using an RIA framework to build Web 1.0 applications (aka. New technology same old stuff).

One of the largest challenges when moving from Web 1.0 applications to the RIA's development paradigm is learning to think differently. Flex gives developers an advanced component library that allows for doing things that simply weren’t possible only a few years ago. Often, the power of Flex is missed, and the framework is used to implement more traditional Web 1.0 applications. 

Building Web 2.0 applications is more than partial page refresh and rounded corners. For example, Flex developers should be using vectors to provide users a visual understanding of data, and advanced controls for a rich application flow. Stephan Janssen discusses this struggle recently with InfoQ.com:

As a Java developer, learning Object Oriented ActionScript and the UI markup language is really a walk in the park. The challenge however for (Java) developers is that we're not designers, and with RIA technologies these two skills are very much needed.

2. Breaking standard browser experiences.

While Flex does provide an excellent platform for improving the user experience, it still important to maintain familiarity of things like the back button, book marking, and auto complete. 

Flex 3 includes new Deep Linking features for back button support and book marketing. You can learn more at labs.adobe.com. There are number of components out there for implementing auto-complete. From the Adobe Exchange, you can use the AutoComplete Input component. 


3. Slowing the application down with the use of too many containers.

Flash Player uses a hieratical display object graph, similar to the HTML Document Object Model (DOM). The deeper containers are nested the longer the rendering takes. Adobe’s Flex Developer Center has an article that covers best practices related to Flex performance, including the use of containers in detail:

The biggest Flex performance danger is yielding to the temptation to use containers randomly. Deeply nesting too many containers hinders the performance of your application. This is the number one performance danger that Flex developers succumb to—and luckily it is 100 percent avoidable.



4. Slowing the application down by using XML for data transfer over optimized protocols.

Flex offers developers a number of options for data transfer between the Flex client application and the server, including AMF3, XML, SOAP, and straight HTTP requests. Ward demonstrates the use of these technologies and performance benchmarks in his Census application. 

BlazeDS should be considered for Greenfield projects using Java on the backend. BlazeDS is Adobe’s recently open sourced Data Services product that uses the AMF3 protocol. AMF is a binary transfer protocol that is easy to integrate with Java, and offer significant performance benefits over XML. There are open source implementations of AMF for every major backend technology. 

If BlazeDS is not an option, Hessian could be an option. Hessian offers ActionScript/Flex support for their binary web services protocol. 


5. Trying to hire Flex developers.

Experienced Flex developers are very hard to find right now. Flex is at the point in the adoption curve which Java was at in the late nineties. The demand for Flex developers is exceeding the supply. This makes finding experienced Flex developers difficult. This, however, creates a huge opportunity for Java developers to expand their skill sets and work with a fun emerging technology. Many companies looking for Flex developers have great success training Java or other web application developers for only a few weeks on Flex. Flex’s language and APIs are easily learnable by developers who are familiar with Web and GUI programming. 


6. Over use of animations

Using Flash as the runtime enables developers to easily add animations and effects. However, developers should make sure that the animations have meaning and provide context. Otherwise, they will annoy users. The timing of animations is also important. Interaction designers can help make recommendations on when animations should and should not be used. Interaction designers can also recommend the best type of animations, the duration, and the best easing function. 

There is good a post on the use of animations at laair.org:

Most animations are simply TOO LONG. They are long, and slow, and boring, and excessive. Tone it down. If there is one thing I have found, its that I hate waiting for stupid animations to finish so I can do something else. 

Don’t get me wrong I am not bashing animations. I am simply bashing animations that are simply too long or too extravagant for their purpose. Every animation can be broken down to having a purpose. Figure out the purpose of your animation and apply accordingly.

7. Not setting up an enterprise ecosystem.

As with other software projects, it is important to setup an enterprise ecosystem for your Flex applications. 

Test Driven Development (TDD) is a staple of most any enterprise project in this day-and-age. For Flex, the FlexUnit framework is available for coding unit tests. On Adobe’s Developer Connection, Neil Webb discusses TDD for Flex developers and using FlexUnit. In addition,Flexcover is available for code coverage reporting. 

Continuous Integration (CI) is a proven practice for building cohesive applications when multiple developers are contributing. Similar to Java applications, both Ant and Maven plug-ins are available for CI builds of your Flex applications. 


8. Not using the entire framework.

There are a number of optional features available in Adobe Flex that you should consider using in your applications. For example, Runtime Shared Libraries (RSL) is available for reducing the size of your applications:

You can shrink the size of your application's resulting SWF file by externalizing shared assets into standalone files that you can separately download and cache on the client. Multiple Flex applications can load these shared assets at runtime, but each client need only to download them once. These shared files are called Runtime Shared Libraries.

Another under used feature of the framework is the built in accessibility features. You can read more about the accessibility features of Flex in Adobe’s livedocs. In addition to built in accessibility, the framework provides built in features for localization. For the latest Flex 3 framework features, checkout Adobe’s Getting Started introduction page. 


9. Slowing the DataGrid down with complex renderers.

The out-of-the-box itemRenderer for the DataGrid is very optimized. Mistake #3 discussed the performance impacts of deeply nested containers. One of the places in Flex where containers can easily get deeply nested is in the DataGrid’s item renderers. The number of item renderers which are rendered by the DataGrid is the number of visible rows times the number of visible columns. Custom DataGrid and List item renderers should be very optimized. When complex layout logic is needed in an item renderer, it is best to use UIComponent (or other more low-level classes) and position the contents for that cell manually. 


10. Not Preparing for Offline Applications.

The traditional model for RIAs is in the browser. However technologies like Adobe AIR andGoogle Gears is allowing those applications to run offline. By not preparing for a potential offline architecture when users demand it, changing your applications to support offline features may be very difficult. Typically, in web applications business logic lives on the server. In offline RIAs, business logic must transition to the client. This makes it nessecary to architect ahead of time where certain business logic will need to live in order for applications to work both offline and online.