Someone asked me the other day, "What is one way I can decrease the initial load time of my application?". That is a great question. By decreasing the initial application load time, you create a more pleasant user experience for your applications. Every developer should have that in mind when creating applications for other human beings.
Example with a module: Click Load Panel Module, then click Add Text button in the module to add text to the Container. Use the DropDownList to change font types and colors of the dynamically created text.
Example without a module: Click Add Text button in the Panel to add text to the Container. Use the DropDownList to change font types and colors of the dynamically created text.
One of the biggest contributing factors to initial load time is embedded fonts. Embedded fonts greatly bloat the size of a SWF file, and by doing so increase initial load time.
One way to reduce the initial load time is by embedding your fonts in a separate SWF file via a Module. Above is an example of a SWF file with a main application file size of 40 kbytes with an associated module (separate SWF file) with a file size of 5+ Mbytes due to the embedded fonts. As you can see, the initial load of the application should have been relatively fast as compared to the main application containing the embedded fonts in its code which has a file size of 5+ Mbytes. This may not be apparent if you have a download speed close to the speed of light, but consider your users and their capabilities.
A few advantages of using modules have been noted as:
1. Faster initial application download.
2. Separation of large embedded objects from the main application.
3. Modules can be used by more than one application.
4. They can be loaded and unloaded which can reduce the amount of visual space needed for an application.
5. You do not not have to re-compile the main application (if created in a separate project).
6. You can add resources to a module without adding overhead to your main application (for example more embedded fonts, images or components).
7. If the module is not needed, it does not have to be loaded and cached (for example, a product manual).
8. You can provide loading progress through a module interface.
Some disadvantages of modules have been noted as:
1. Cross Domain issues and associated coding requirements.
2. Loading time for the module may still be a problem for some users.
3. Requires additional coding to reference a module (as opposed to coding in the main application).
4. Unexpected errors can occur causing a module to not load at all.
5. Relocating a module to another folder requires main application to be re-compiled for new url.
As well as many other advantages/disadvantages that you may encounter. A lot of the decision in deciding to use a module comes from its use in your application. Consider the following:
1. How often will the features be needed by an end-user?
2. How much load time does this really save?
3. Is there another method such as RSLs (Runtime Shared Libraries) that may be just as effective?
4. Will this in some way help to better organize my application and associated files?
5. How many modules will I need to create, and how will they be dependent on each other?
These are all good things to consider when you choose the modularization option. If after reading this, you are still interested in modules, then download the following Zip project files which contain the coding and explanations in the files to compare projects with and without a module for yourself.
This concludes this sample project.