Accessibility

Table of Contents

  1. Introduction
  2. Architecting Flex Applications That Perform Well
  3. A Note About Flash Players
  4. Using Layouts, Hierarchy, and Containment Properly
  5. Examples of Common Container Redundancies to Avoid
  6. Using Deferred Instantiation to Improve Perceived Performance
  7. Handling Large Data Sets
  8. Playing Complex Effects Smoothly
  9. Achieving Great Performance with Runtime Styles
  10. Using Dynamically Repeating Controls for Better Performance
  11. Improving a Repeater Object's Performance
  12. Improving Performance of Charting Components
  13. Performance Tuning and Profiling Your Own Flex Application
  14. Using Runtime Shared Libraries (RSLs)
  15. Feedback and Support

Flex Application Performance: Tips and Techniques for Improving Client Application Performance

Examples of Common Container Redundancies to Avoid

The following list provides examples of common container redundancies to avoid:

  • The VBox container inside an <mx:Panel> tag—A Panel container is a VBox container with support for a title bar, rounded borders, and other Panel styles. If you want Panel children to lay out as they would in a VBox container, populate the <mx:Panel> tag directly with controls; do not wrap a VBox container around the controls. The VBox container would be a redundant container wrapper, and removing this eliminates one more level of unnecessary container nesting.

    For example, instead of writing this: 

    <mx:Panel title="Grocery List" width="150" height="150">
	<mx:VBox>  
		<mx:Label text="Fruits" />
		<mx:Label text="Veggies" />
		<mx:Label text="Cookies" />
		<mx:Label text="Crackers" />
	</mx:VBox>
</mx:Panel>

    Use this code instead:

    <mx:Panel title="Grocery List" width="150" height="150">
	 <mx:Label text="Fruits" />
	 <mx:Label text="Veggies" />
	 <mx:Label text="Cookies" />
	 <mx:Label text="Crackers" />
</mx:Panel>

    Both achieve an identical layout.

  • VBox container inside an <mx:Application> tag—An Application object is inherently a VBox container layout. It is unnecessary to wrap your <mx:Application> tag with a VBox container; removing this wrapper will eliminate one more level of container nesting.

    For example, instead of writing this:

    <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">
 <mx:VBox horizontalAlign="center" backgroundColor="#EFEFEF">
    <mx:Label label="Shopping Cart" />
	.
	.
	.
 </mx:VBox>
</mx:Application>

    Use this code instead:

    <mx:Application xmlns:mx=http://www.macromedia.com/2003/mxml
 horizontalAlign="center" backgroundColor="#EFEFEF">
	<mx:Label label="Shopping Cart" />
		.
		.
		.
</mx:Application>

  • Containers as top-level tags for MXML components—The beauty of MXML components is that they provide a way to modularize repeated code. However, these components are vulnerable to the same performance pitfalls as the larger application. You do not need to use a container tag as the top-level tag of your MXML component definition. It is perfectly valid for an MXML component to be a simple control, like: 

    <mx:Image xmlns:mx=http://www.macromedia.com/2003/mxml source="@embed('foo.jpg')" width="200" height="200" />

    By stepping through MXML component definitions and purging unneeded container wrappers, you can reduce container nesting (and many unnecessary objects), and, subsequently, ease the load of your application.

  • Container wrappers for an MXML component instance— Normally, there is no need to wrap a container around an MXML component tag. You can set different styles, labels, and ids within the instance of the MXML component—you don't need to set them within a container that wraps the MXML component. For example, instead of wrapping an unnecessary VBox container around your MXML component to set some styles like this:

    <mx:VBox backgroundColor=" #FFCCCC" borderStyle=" solid"> 
	<myComponent xmlns=" *" />
</mx:VBox>

    You can set those styles within the MXML component tag itself, like this:

    <myComponent xmlns=" *" backgroundColor=" #FFCCCC" borderStyle=" solid" />

    Developers often couple this bad practice with using unnecessary containers as top-level tags for MXML components, which can create at least two superfluous containers for each MXML component used! This creates many unused objects that, when eliminated, yield a dramatic improvement in the responsiveness of your application.

  • Re-evaluate your container choices—Inspect every container tag and decide if it is necessary and if it is useful for the overall structure of the application. Could the same layout be mimicked with another layout container or by using layout styles? Revising your layout ensures that your application is as lean as possible, reduces overall SWF file output size, and makes performance much more robust.
Page 5 of 12
Previous Page
Next Page