Farata Systems      

Holidays are officially over, and it is good time to start blogging again. I will try to put few little known tricks that might be considered a bit “unorthodox”. DISCLAIMER: they are not standard techniques used at Farata Systems. I would not recommend them to a client without a full disclosure of the risks and chances of being “unsupported” in the future. The idea is to make it in discussion on the best practices or at least acceptable practices.

Flex 2.0.1. has introduced modules. The idea is to partition your application into set of independent pieces that can be streamed on demand or in background. While the goal is noble, implementation can and should be imroved for developers to benefit. Module is pretty much independent swf that is very much “black box” to the rest of the application. In order to communicate between module and application you can define interface and place it in the library shared by application and module. Module has to implement the interface and application will call methods on it. That model presents challenges when you apply it as the only solution to the large application partitioning/optimization.

Here is a brief history note – we were advocating and implementing modules (in a very crude way) since the beginning of the last year. It helped with large applications quite a bit – but it’s applicability was around 20% of the cases. I will start with going through deployment cases and my take on the applicable cases.
OK, bag of tricks # 1 – make your application load fast and stay small.

Here are your choices :

1. Do nothing, use defaults – your application will be produced as a single swf file -sizing 200KB to possibly few MB – but it minimum size for the total download to “clean” machine. Any change to the application invalidates browser cash and causes reload. Good for applications that are used seldom or by wide audience.
2. You use Flex framework libraries as RSLs – you are getting minimum size of framework download of 1.3MB but your application is really small now and changes are loaded instantaneously. Excellent for intranet and often used/often changing applications for heavy duty users

3. The same as #2, but you want to bite a bullet and optimize framework load and make it usable on your domain. You read James Ward’s blog on patch to preloader (http://www.jamesward.org/wordpress/2006/11/27/howto-reduce-the-size-of-your-flex-app/) and build your own version of it. Make sure you strip debugging stuff for another 30% of the size benefit/startup messages removal.

Hopefully, Adobe will come with deployment libraries hosted on their site, plugged in the player update mechanics for security and allowing fallback to the client’s sites -  with  Adobe or VeriSign  type of certificates  as it is one of the best ways  to trim your applications – with no work for you.
4. Modules as implemented by default shine if you have a rich (heavy) piece of functionality that is independent from the rest – the very same way you could of break you application into the larger number of small ones. Certain classes of applications and widgets would benefit from it. You,as a developer, will suffer – working with black box is not easy. Interfaces sound like good idea but interferes with development process by requiring you to update 3 things at once. And if you have “shared” interface for few modules – you need to update everyone.
5. You want a library / module hybrid. You want to be able to load it on demand, you also want an option to code against it like in a regular library for type checking and better integration. That one is very easy to implement – just requires 2 compilations (by compc for SWC used by compiler and MXML for module) and trick on deployment similar to James’s- but greatly enhances flexibility/options on modules development and deployment. I will this put template in the flex2ant plugin that automates the process.

6. Finally, you might want to use “resources” based approach for the application. Essentially, resources are a way for developers to separate algorithms (code) from UI/data implementation the same way designers separate design from CSS. Let me give you business example of that and then we will go back to implementation details. Let us say you have DataGrid that will be used to browse something – it can be employees, customers or products. Functions are very much the same – you can scroll print, sort, filter, drill down – but list of columns and data providers are different. However, if you plug in new array of columns and change dataProvider, the datagrid can show different data set.

These specifics can be separated in different modules (one for employees with related itemrenderers and functions, one for customers and one for products). The datagrid stays in the application, load these modules on demand when user switches the view and import the values in. It just needs the module name and the name of datagrid class in the module. Unlike approach with pure modules you implement functionality once in the application and change UI/data with modules. Canonical modules force you to implement the same functionality in each module or get really creative in making that functionality shareable.
Some other examples that can use resources are data aware controls like treeview, combobox, checkbox, radiobuttongroup, anything. As you start using it it becomes way for you to easily manage development process and separate the work for people with different skill levels.
I will be posting some samples on library/module hybrid and resources shortly – meanwhile let me know if I missed other major deployment scenarios.

Sincerely,

Anatole Tartakovsky

Bonus section: a while back I had a post (http://flexblog.faratasystems.com/?p=88) on how to use Ted Patricks preloader (he had few “splash screens” models) in real applications – like give the user simple login screen to keep him busy while the app is being loaded and initialized – and carry the entered information back to the app/ hold displaying application till logging is complete.