User Guide

116 Chapter 3: Using Best Practices
If you use multiple components that do not share the same framework, they might add
substantial file size to the SWF file. For example, the XMLConnector component adds 17K to
the SWF file, and TextInput components add 24K to your document. If you add the ComboBox
component, it adds 28K, because it is not part of either framework. Because the XMLConnector
component uses data binding, the classes add 6K to the SWF file. A document that uses all these
components has 77K before you add anything else to the file. Therefore, it is a good idea to
carefully consider your SWF file size when you add a new component to the document.
Components must exist in the parent SWF file’s library. For example, a screen-based application
must have a copy of the components it uses in its library, even if those components are required
by child SWF files that are loaded at runtime. This is necessary to ensure that the components
function properly, and slightly increases the download time of the parent SWF file. However, the
parent library isn’t inherited or shared in the SWF files that you load into the parent. Each child
SWF file must download to the application with its own copy of the same components.
Using runtime shared libraries
You can improve download time by using runtime shared libraries. These libraries are usually
necessary for larger applications or when numerous applications on a site use the same
components or symbols. By externalizing the common assets of your SWF files, you do not
download classes repeatedly. The first SWF file that uses a shared library has a longer download
time, because both the SWF file and the library load. The library caches on the user’s computer,
and then all the subsequent SWF files use the library. This process can dramatically improve
download time for larger applications.
Optimizing styles and performance
One of the most processor-intensive calls in a component framework is the
setStyle call. The
setStyle call executes efficiently, but the call is intensive because of the way it is implemented.
The
setStyle call is not always necessary in all applications, but if you use it, you should
consider its performance impact.
To enhance performance, you can change styles before they are loaded, calculated, and applied to
the objects in your SWF file. If you can change styles before the styles are loaded and calculated,
you do not have to call
setStyle.
The recommended practice to improve performance when using styles is to set properties on each
object as objects are instantiated. When you dynamically attach instances to the Stage, set
properties in
initObj in the call that you make to createClassObject(), as the following
ActionScript shows:
createClassObject(ComponentClass, "myInstance", 0, {styleName:"myStyle",
color:0x99CCFF});
For instances that you place directly on the Stage, you can use onClipEvent() for each instance,
or you can use subclasses (recommended). For information on subclasses, see “Creating
subclasses” on page 258.