In this brief article I’d like to talk about one of the most important aspects of RIA in general and written in Flex in particular – the initial download process. 

Your application is considered fast for one of two reasons:

1. Well, it is fast
2. It’s perceived to be fast

Today I’ll cover one of the approaches that we at Farata Systems successfully use in literally every enterprise project - designing any Flex application as a portal. There is one exception: Hello World type applications that don’t have any custom styling. Such simple applications can live in a single swf.

Any serious application is technically a portal that consists of a small and light shell application that appears very fast on the user’s machines and downloads (in a smart way) the RSLs that will be needed for the modules lazy loaded modules.

Needless to say that you must always deploy Flex Framework libraries as signed RSLs, which will allow shaving off a substantial amount of downloadable bytes required by your RIA. Unless you have a virgin computer that never seen Flex app, these RSLs will be stored on the user’s disk in Flash Player’s cache (don’t confuse it with the Web browser’s cache).

Now consider an application that has one light-weight main SWF and 10 modules, seven of which include charts. In other words, they rely on datavisualization.swc. During the application startup the SystemManager reads the list of RSL’s from the SWF and loads them with the help of the class of RSLListLoader.

Without going through the advantages of using the RSLs in general, I’d like to mention the fact that Adobe’s class RSLListLoader simply performs loading of all RSLs listed in the generated SystemManager for each module. This means that if the datavisualization.swc was linked in three modules, SystemManager will download it three times (this is the case when this swc was not signed and cached).

We’ve modified the RSLListLoader a little bit so it’ll avoid downloading duplicate RSLs.

One more suggestion for working with modularized applications that use BlazeDS/LCDS – do not create separate services-config.xml files for each of the module. To avoid conflicts, let them reuse one and only services-config.xml listed with the main SWF of your application. This will also allow you to properly allocate work between developers in your team – each of them can have a small test harness application and test his/her modules without the need for waiting when the other modules are ready.

In the following 7-minute screencast I’ll show you the application that has been built in such a way.

People who will attend our Enterprise Flex symposium in New York City on August 7 and Advanced Flex training in London on September will get a chance to get familiar with these techniques in greater details.

Hope to see you there.