About containers

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 children.

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.

About layout

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 the parent.

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.

About skinning

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 run faster.

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.

    For navigator 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.