Best Practices while developing in Flex/ActionScript 3.0
Use of Design Patterns
As in any other language, use of design patterns is also recommended in Flex. Some of the most widely used and successful pattern in Flex world are:
- Command Pattern: As a design pattern, Command Pattern is used where objects are used to represents actions. If you break up your application as features, then you should be having one command per feature. This pattern brings in many benefits like:
- re-usability of code as we have encapsulated functionality in classes that can be invoked from various areas of the application;
- commands can be used queued up using a Manager and can be run in sequence or asynchronously;
- provides the capability to perform undo(s) by maintaining the list of commands as the get executed
- Model-View-Controller (MVC): You can choose to have a MVC as a “hand-rolled” code, or use some of the existing libraries like PureMVC or Cairngorm.
- Singleton: Flex being a client, it is recommended that you manage state on the client itself instead of a server. Singletons provide you with a capability of managing states in the objects itself.
Caveat: You can not use Singletons together with Modules. Doing so would mean that multiple instances of the same module will be referencing to the same model and hence data causing issues on the views. This is one area where you would have to careful not to tip the balance.
- Garbage Collection: Little known facts:
- runs when the Flash player needs memory and is based on many factors like available RAM, available chinks;
- runs automatically and you can not force it to run
- does not do everything in single run. Player manages garbage collector execution in a thread and it may take a while before garbage collector starts to collect memory
- Use weak references for event listeners if you are very sure that there would be other references. But, if you not sure of that, then you should be using a strong reference. What you do not want is to loose your event listeners just because there are no other references to the object. If you use strong references, make sure you remove event listeners as well. A weak reference is one that is not counted by the Garbage Collector (i.e. it is not counted in reference counting, and it is not followed for mark sweeping). This means that if the only references remaining to an object are weak, it will be available for collection on the next GC sweep. References associated with event listeners are often forgotten by developers, which normally results in the listener never being removed from memory. This is why weakly referenced event listeners are so handy – if you forget to remove the listener, you will not impede the Garbage Collector’s ability to collect the object. But, they can be tricky as if there are no other references, and if you are awaiting response from an event, the event will get lost as the object would be collected by GC.
- Defer instantiation: You should be using deferred instantiation for creating controls. Containers like ViewStack, Tabnavigator has deferred instantiation activated by default and you should not change the policy. This will lead to having quicker application startup
- Reuse objects instead of creating new ones: killing existing objects and creating new ones will lead to an overhead on the player. Also, this will mean that you will have to write code to cleanup references of the object or else Garbage collection would not work
- Cleanup: To do the cleanup make sure you always, remove all event listeners and clean up all variable references by setting the object to null
- Make use of runtime shared libraries to decrease startup time
- Use strongly typed variables: ActionScript compiler would be able to do some good code optimizations if you are using strongly typed objects
- If you have to refer to an object property time and again, then set that to a variable. Like: Do not use arrayObject.length in a for loop. Make sure you have that stored in a variable before the loop begins
- Be conservative about using custom item renderer’s in DataGrid. Having a renderer for every column would kill the performance
- Avoid unnecessary component nesting. Try to use Constraint based layout for laying out your pages. Use of HBox and VBox with dense nesting is not recommended. These should be used only when you have to lay out things in a row/column
- Use AMF !
I would be blogging away with more detailed viewpoints on each of these in times to come.