A container defines
a rectangular region of the drawing surface of Adobe® Flash® Player. Within this region, you define
the components, including controls and containers, that you want
to appear. Components defined within a container are called children.
Adobe® Flex® provides
a wide variety of containers, ranging from simple boxes, panels,
and forms to accordions that provide built-in navigation among its
At the root of an application written in Flex is a single container,
called the application container, that represents the entire Flash
Player drawing surface. The application container holds all other
containers and controls. For more information, see Application containers.
A container uses a set of rules to control the layout of its
children, including sizing and positioning. Flex defines layout
rules to simplify the design and implementation of rich Internet
applications, while also providing enough flexibility to let you
create a diverse set of applications.
About layout containers and navigator containers
Flex defines two types of containers:
- Layout containers
- Control the sizing and positioning of the children defined within
them. Children can be controls or other containers. For more information on
Spark layout containers, see Spark containers. For more information on MX layout containers,
see MX layout containers.
- Navigator containers
- Control user movement, or navigation, among multiple child
containers. Navigators only take MX containers or the Spark NavigatorContent
container as children. The individual child containers, not the
navigator container itself, control the layout and positioning of
their children. For more information, see MX navigator containers.
About Spark and MX containers
Flex defines two sets of containers: MX and Spark. The
Spark containers are defined in the spark.components package. The
MX containers are defined in the mx.core and mx.containers packages.
While you can use MX containers to perform most of the same layout
that you can perform using the Spark containers, Adobe recommends
that you use the Spark containers when possible.
About container children
One of the main differences between Spark and MX containers
is that an MX container can only use components that implement the
IUIComponent interface as its children. The UIComponent class implements
the IUIComponent interface, so you can use all Flex components and
containers as children of an MX container.
The Spark Group and SkinnableContainer containers can hold children
that implement the IVisualElement interface. These components include
all subclasses of the UIComponent class, and any subclasses of the
GraphicElement class. Many of the classes in the spark.primitives
package, such as Rect and Ellipse, are subclasses of the GraphicElement
class. Therefore, you can use those classes as children of a Spark
container to add graphics to the container.
The Spark SkinnableDataContainer and Spark DataGroup containers
can hold children that implement the IUIComponent interface, and
hold data items such as a String, Number, or Object. You must define
an item renderer to control the display of the data item. For more
information, see The Spark DataGroup and Spark SkinnableDataContainer containers.
Containers implement a default layout algorithm so you
do not have to spend time defining it. Instead, you concentrate
on the information that you deliver, and the options that you provide
for your users, and not worry about implementing all the details
of user action and application response. In this way, Flex provides
the structure that lets you quickly and easily develop an application with
a rich set of features and interactions.
Layout rules also offer the advantage that your users soon grow
accustomed to them. That is, by standardizing the rules of user
interaction, your users do not have to think about how to navigate
the application, but can instead concentrate on the content that
the application offers.
One of the main differences between Spark and MX containers is
that the layout algorithm for MX containers is fixed, but for Spark
containers it is selectable. Therefore, MX defines a different container
for each type of layout. Spark defines a smaller set of containers,
but lets you switch the layout algorithm to make them more flexible.
The MX Canvas, MX Application, and MX Panel containers, and all
Spark containers, can use absolute layout. With absolute
layout, you explicitly specify the children’s x and y positions
in the container. Alternatively, you can use constraint-based layout to
anchor the sides, baseline, or center of the children relative to
Absolute layout provides a greater level of control over sizing
and positioning than does automatic layout. But absolute layout
provides this control at the cost of making you explicitly specify
the positions of all container children.
Spark and MX containers let you define custom layout rules. For
Spark, you can define a custom layout class and apply it to a Spark
container. For MX, create a subclass of one of the MX containers
and override its layout mechanism.
For more information on layout, see Laying out components.
Skinning is the process of changing the appearance of a
component by modifying or replacing its visual elements. These elements
can be made up of bitmap images, SWF files, or vector images. All
MX containers are skinnable.
Most, but not all, Spark containers are skinnable. The Spark
Group and DataGroup containers are not skinnable. These containers
provide a lightweight mechanism that you use to perform layout.
They do not support skinning to ensure that they add minimal overhead
to your application. If you need to modify the visual appearance,
use a skinnable Spark container instead.
For more information, see Spark SkinningImproving startup performance and Skinning MX components.
About the creation policy
Containers define a creation policy that specifies when
its children are created. By default, a container delays creating
its children until they are needed by the application. This process
is called deferred instantiation. Since all children are
not created at application start up, your application appears to
You can control the creation policy for a container. For example,
you can create all children at startup, or you can explicitly determine
when a child is created.
You can use the following creation policies:
ContainerCreationPolicy.AUTO The container
delays creating children until they are needed.
containers such as the MX ViewStack, MX TabNavigator, and MX Accordion
containers, the container creates its direct children immediately, but
waits to create the descendants of each child until the child needs
to be displayed. As a result, only the initially required child
or children of a container get processed past the preinitialization
stage. An auto creation policy produces the best startup time because
fewer components are created initially.
ContainerCreationPolicy.ALL All container
children are created and initialized before the container is initialized.
ContainerCreationPolicy.NONE Requires the
container to explicitly create every child instance.
For detailed information on creation policies, see Improving startup performance.