Working with dynamic skin parts in Flex

Skin parts—both static and dynamic—are an essential part of the Spark architecture. They describe all the individual parts of a component and define a clear contract between the component and its skin. In his article Defining and using new skin parts in a Spark skin, Drew Falkman introduced skin parts, with a focus on how to use static parts. I recommend reading that article before this one, especially if you are new to the concept of skin parts. This article focuses on working with dynamic skin parts, and covers differences between static and dynamic parts, defining dynamic skin parts in the component and its skin, and how to add and remove them at runtime.

Differences between static and dynamic skin parts

When building a new Spark custom component, one of the first things to consider is what individual skin parts will constitute that component. This is when you need to decide which parts will be required and which will be optional, how many instances will be created, and whether they will be instantiated when the skin is initially created or later during the lifetime of the skin.

Table shows the main differences between static and dynamic skin parts.

Table 1. Static skin parts vs. dynamic skin parts

For example, a VScrollBar component contains four static skin parts: track , thumb , decrementButton , and incrementButton . They are static skin parts because there can be only one instance of each.

Use cases for dynamic parts

You should use a dynamic skin part when there are many instance of a skin part or when there is only one instance of the skin part but it will be instantiated some time after the skin has been created.

Dynamic parts are particularly useful when you don't know at compile time how many instances of a skin part the component needs. Typical use cases include components that create skin parts according to the value of a variable or when a skin part needs to render a variable number of data items in a data set retrieved from a database.

A simple rating component

To illustrate dynamic skin parts, I created a simple rating component that allows a developer to choose a precision range via the precisionRange variable (see Figure 1).

When precisionRange is set to 4 , possible intermediate values are 0.2, 0.4, 0.6, and 0.8. For a value of 3 , possible intermediate values are 0.25, 0.5, and 0.75.

You'll likely agree that this may not be the best way to design a rating component, but it makes a good example for illustrating the use of dynamic skin parts.

Defining skin parts

Working with dynamic skin parts is a little bit trickier than working with static ones, because you are in charge of instantiating them, not the framework.

First you declare skin parts on the component, and then you define the skin parts on its skin.

Declaring skin parts on the component

The rating component will use Spark buttons for the ratings parts. As with static parts, the [SkinPart] metadata tag is used to declare dynamic skin parts. However, the type of the variable should be IFactory and not Button. Also, you specify the class (in this case, spark.components.Button) used by the factory to create new instances in the metadata; for example:

Notice that you can also specify whether the skin part is required or not, but most of the time it will be required for dynamic skin parts.

Defining skin parts on the skin

Once the declaration is done, you need to define the parts on the skin. Again, the behavior differs a little bit from the static definition. With static skin parts, you put graphic elements and other controls in your skin file. Dynamic parts belong in the Declarations tag of the skin's MXML because you don't know how many instances there will be and where they should be added on the skin; for example:

There are two things to notice here:

• The rating button is surrounded by the Component tag.
• The value of the id attribute is the same as the skin part name in the component.

If your code doesn't meet these requirements, you will get a runtime error.

Creating and removing dynamic skin parts

After you declare and define the skin parts, you're ready to create instances of them and lay them out on the skin. Most of the time, dynamic skin parts are deferred, which means they are created at some point after the skin has been created. For example, the rating component creates the precision buttons the first time the user rolls the mouse over a regular button. In this case, the deferred behavior is the result of user interaction, but it could also come from a system event.

Creating an instance of a dynamic part

To create an instance of a dynamic skin part, you might be tempted to use the new keyword as if you were creating an instance of a class. Alternatively, you might think that you should use the newFactory() method of the IFactory object to create a new skin part, since the dynamic part is declared as an IFactory object in the component. However, dynamic skin parts should always be instantiated by the SkinnableComponent.createDynamicPartInstance() method because it uses a caching mechanism; for example:

The part to be instantiated is passed as a parameter to the createDynamicPartInstance() method. You will need to cast the value returned by this method in order to use it (for example to set its label) and to add it to the skin later.

Adding the parts to the skin

After instantiating the part, you need to add it to the display list. Because it was defined in the skin's Declaration tag, the framework doesn't know where to add it on the skin. In the example above, the newly created buttons were added to precisionRatingGroup , which is a skin part that defines where precision rating components will be added.

Adding behavior to the part

As it does for static parts, the Flex framework automatically calls partAdded() once the part has been created. If you want to add custom behavior to the newly created objects, you'll need to override the partAdded() method and add the new behavior inside this method; for example:

Removing parts

Removing parts is a pretty easy task once you know how to add them. As the developer, you are also responsible for removing the parts from the display list by calling removeDynamicPartInstance() .

Getting a reference to a dynamically instantiated part

Sometimes you will need to refer to a dynamic part you created. There are two ways to do it:

• Store the reference returned by the createDynamicPartInstance method; for example: myGroup = createDynamicPartInstance("myDynamicGroup") as Group;
• Call getDynamicPartAt(partName:String, index:int) . Index is used here to specify which instance you want.

Changing the skin at runtime

Although it is uncommon, you may want to change the skin of your component during the execution of your program. In this specific case, you will need to store the state of your dynamic parts somewhere in your code because the Flex framework doesn't do it for you.

I recommend doing that in the attachSkin() and detachSkin() methods because these methods are called when the skin is loaded and unloaded respectively.

This mechanism hasn't been built into the rating example, but you can add it as a learning exercise.

Where to go from here

Creating dynamic parts is almost as easy as creating static parts once you understand the logic behind it. I encourage you to explore the example source code and enhance the rating component to get a better understanding of how to use skin parts.

For more on skins, see:

• About Spark skins
• Skinning components