Our team has been in the process of developing a set of Adobe Flex best practices for quite a while. There are several posts on the internet that address this issue. These posts range from best practices for setting up the project to naming and coding conventions. The following posts are the ones we identified as the most useful and better prepared:
Flex best practices – Part 1: Setting up your Flex project. Posted by Sean Moore in the Adobe Developer Connections site.
In addition to these conventions, we’ve also developed our own set of guidelines, mostly targeted to improve the performance of the Flex applications:
- Load the Flex Framework as a runtime-shared-libraries (RSLs). This will reduce the size of your applications and the time it requires to download.
- Always use strongly typed objects. E.g.: var myVariable:Number;
- Always use weak references with listeners when possible, except with anonymous functions : addEventListener(event, function, false, 0, true).
- For the cases when weak references may not be possible, remove the event listener once it’s not needed anymore using “removeListener”.
- Clear references to unused data. E.g.: myObject.myData=null;
- Cast objects using “as” instead of “(Type)” except when casting Top Level classes. E.g. myTextInput.text = myNumberData.value as String. If the casting is not allowed it will return null instead of a Run Time Error.
- Use deferred instantiation (creationPolicy=”auto”) for multiple views components such as viewstacks, accordeons, and tabnavigators. This is the default behavior of these components.
- Divide big applications into separate modules.
- Avoid using repeaters at all cost.
- Aovid using “setStyles” unless it’s performed during the object creation.
- Reduce the number of nested components. Use VBox or HBox instead of Grids. Canvas are always a good option, but you’ll need to align each component inside it.