• Show a placeholder-icon that reflects the current rating and serves as an interactive element to open the ratings
• ratings pop up for adjustment
• both the placeholder-icon and the ratings-icons will be gradually filled with color when adjustments are being made
• the icons are defined in FXG
• the icons are not defined in the skin but can be passed as a style for generic use (one skin for different icons and ratings)
• there is colorization of the icons based on styles
• smooth transitions when opening the ratings

Here’s a pseudo city-rating demo that shows variations of the component using different icons and color settings for different ratings.

You’ll find the source at the end of this post. It is fully documented but here’s an overview of the key-concept nonetheless.

Skin-Parts

There are skin-parts for the open-button (which is actually a group that works as a button), the drop-down which is a group that holds the entire pop-up, the active-group and the passive-group that hold the icons for adjustments of the rating and the label-element to show the rating as text.

Building the View

The icons are not part of the skin. They will be set at run time and are pushed down to the skin when the component loads the different skin-parts.

In partAdded() of the component, the active-group and the passive-group are filled with the icons. Five icons in a colorized version are pushed down to the active part.  Five default icons are pushed down to the passive-group.

Masking and Fill Effect

To create an effect that gives the impression of gradually filling the icons when the rating is adjusted, masks are used.  When skin-parts are loaded, the component applies a mask to the active-group.  When the mouse is dragged to adjust the rating, the width of the mask is updated and the (colorized) icons of the active-group are revealed.

The mask is not part of the skin. It is created at run-time by the component and applied to the relevant skin-part.

FXG Icons passed via Styles

The Icons are defined in FXG. Basically each Icon is a MXML-Component. The Icons are passed as a ClassReference to the component via styles. The ClassReference is then used to create an instance of this class at run-time. The instances of the icon are then added to their respective groups.
An Icon is basically a mxml-component that extends from Group. You can create your own and reference it via the rating Icon style.

Colorization based on Styles

The Icons are colorized at run-time. Based on some colors that are passed as styles the icons get colorized using a ColorTransform.

Effects on PopUp

There is a resize and a fade effect when the pop up is openend. These are defined on the skin - you can remove them by simply commenting out the transition part in the skin.

Separation of Concerns

Spark promotes a clean separation of concerns. The Component should keep track of the data/state and work as a controller, the skin is there for the view.  I decided to create and update the mask in the component, because the masking effect is an inherent part of this implementation and setting up the masking infrastructure in the component helps to keep the skin cleaner. Another approach would be to define the mask in the skin, then pull the value for the rating from the component and adjust the mask accordingly.
Still, every aspect of the look (gap, background-colors, borders, effects etc.) is controlled by the skin.

Usage

Setting the basic styles for the AHPopUpRatingComponent:

ah|AHPopUpRatingComponent {
	skinClass: ClassReference('AHPopUpRatingComponentSkin');
	passiveIconColor: "0x808080";
	activeIconColor: "0xc0c0c0";
	baseColor: "0xb0b0b0";
}

Using a variation of style values: For this example use styleName=’medicareRating’ on the component to set the css-class. It uses the Icon under myLibrary.HealthCross and has a light blue color for the active icons.

ah|AHPopUpRatingComponent.medicareRating {
	ratingIcon: ClassReference('myLibrary.HealthCross');
	activeIconColor: "0xCAEAFF";
}

The icons are mxml-components, that extend from Group. Use the fully qualified class-path in the ClassReference of the ratingIcon-style to reference the icon. Here’s an example:

<s:Group horizontalCenter="0" verticalCenter="0" width="25" height="25"  xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark">
	<s:Path  x="5" winding="nonZero" ai:knockout="0" data="M 9.404 0.01 C 9.051 8.355 -1.506 9.232 3.065 16.324 C 1.835 17.4 0.006 19.866 0.006 25.01 L 1.886 25.01 C 1.886 20.554 3.357 18.569 4.244 17.776 C 18.309 18.361 13.558 4.163 9.404 0.01 Z" >
		<s:fill>
			<s:LinearGradient x="6.82861" y="0.00683594" scaleX="25" rotation="90">
				<s:GradientEntry color="0xfbfbfb" ratio="0"/>
				<s:GradientEntry color="0xdcdcdc" ratio="0.5"/>
				<s:GradientEntry color="0xcccccc" ratio="0.5"/>
				<s:GradientEntry color="0x909090" ratio="1"/>
			</s:LinearGradient>
		</s:fill>
		<s:stroke>
			<s:SolidColorStroke color="0xd8d8d8" caps="none" weight="1" joints="miter" miterLimit="4"/>
		</s:stroke>
	</s:Path>
</s:Group>

Get the source (sdk: 7282) here.

What I want is:

• work with FXG Graphic Elements for simpler manipulation and scaling
• easily export the FXG-Definitions for the icons from a tool and/or be able to change them in FB directly
• colorize the icons based on a color style-property and do this per state
• change the icons based on a style-property and do this per state
• change icons at runtime
• scaling effect on icon
• have ONE generic skin, so no duplicates for different icons are necessary

Most of the trouble with generic skins comes from the fact that there is no way to access the FXG Library-Definitions at run-time  (as far as I know) - like getting an instance of a symbol in the library, the way we had in flash. Here’s a hack but I’d rather not use it.

After some headaches I finally managed to get a solution I can live with:

Click here for a test.

You’ll find the source at the end of this post.

The solution regarding the work flow mainly comes down to

• Create Icons in Illustrator and convert them to symbols. One symbol per icon, name them. Save from Illustrator as ai.
• Load the Illustrator-File in Flash Catalyst and go to the Code-View
• You’ll see that FC creates mxml-files with the graphical content per icon
• Copy these files over to Flex-Builder or set the source path so that the catalyst export is in your flex project

In the code there are some key concepts:

• In the skin there is a group where the icons will get attached at run time
• The skin listens for state changes and creates an instance of an icon component based on the iconName that is passed via styles.
• There is some caching involved, so that there will be no instantiation when an icon/state has allready been created
• The Icons get colorized based on a style property and - if defined  - per state.
• The colorization occurs recursively, diving through the nested elements and setting the color of any nested FilledElement
• There is some code involved that manages the scaling of the new instances for the transitions
• Icons, colors and baseColors can be set via styles (and using pseudo selectors for over and down states)

Here’s the source (sdk 4.0.0.7282)

Note: As a variation to instantiate the icons you could put all the FXG-Definition in the Skin inside the library and create them at runtime using the hack mentioned at the beginning of this post.

Out of the box there are basically three ways to get graphics into a Spark skin.

Use Image:

Use an Image component in the skin of the button and embed the icon into a style that is used by the button (Using a property and fetching the graphic from there is another variation).

.btnClass {
symbol: Embed(source='../assets/crossSymbols.swf', symbol='addCross');
}
...
<mx:Image id="symbol"  source="{hostComponent.getStyle('symbol')}" />
...
or
...
<s:BitmapImage  source="{hostComponent.getStyle('symbol')}" />

pros:

• Can use bitmaps or vectors
• When using vectors, scaling effects of the graphic works well
• possible loading of graphics at run time
• reusable skin for different graphics

cons:

• Overhead by using Halo Component in the skin
• No FXG defined graphics, if you want them.

Use Spark BitmapImage

Works the same way as above, but uses an BitmapImage in the skin:

pros:

• Can use bitmaps or vectors
• reusable skin for different graphics

cons:

• Vectors are internally drawn to a bitmap an treated accordingly
• Scaling effects work not so well since bitmaps are used
• No FXG defined graphics, if you want them.

Use FXG GraphicElements

The Graphics are defined by FXG Graphic Elements directly.

pros:

• Uses FXG (with possible bi-directional tooling support)

cons:

• Skins are not reusable for different graphics, graphic is ‘hardcoded’ into the skin

Personally, I’d love to use FXG. With Flash Catalyst, the FXG-Support in Illustrator et al. and the obvious commitment of Adobe to push FXG as the XML-based graphics interchange format for the Flash Platform, I guess it will be easier and more transparent to work with FXG when it comes to vector graphics. Exporting all the stuff to swfs or swcs is ok, but i’d rather not.

Now, creating a spark skin for every OK-, Submit- and Cancel IconButton etc. just won’t cut it. Sure you can copy the skin over but when you have lots of transitions and stuff and your client asks for a change you gonna have to repeatedly change the skins. Not very funny.

All that’s needed is a way to access the Library-definitions of FXG at runtime. Up until now, I haven’t found any, except for the hack I posted here.

After banging my head against a wall again and again, I’ve finally found another way I can live with.

Here’s an example of a Spark Icon Button done in Flex 4. There are smooth transitions on the background gradient between the up and over states. From the over state to the down state the shadows are removed smoothly. Each button has a different base color.

Click here for a demo.

Apart from the new skinning architecture there are a couple of aspects that make defining the look and feel of Spark Components easy:

• Transitions and effects that look up the values in the states
• Pseudo-Selectors for component-states, as well as id- and descendant selectors
• Enhanced states with group states.
• Colorization and exclusion

Transitions & effects

In this example the skin defines some transitions. There are AnimateColor effects that work on the gradient entries. There’s no special configuration involved, since the default-property that AnimateColor works on is… color . On the GradientEntry object there is a property for color. Flex automatically looks up the color values from the referenced states on the gradient entries.

In the states declarations there is an additional stateGroups ‘overStates‘ defined, that is referenced by the gradient entries.  So there’s no need to explicitly define the colors for every state.

<s:states>
  <s:State name="up" />
  <s:State name="over" stateGroups="overStates"/>
  <s:State name="down" stateGroups="overStates" />
  <s:State name="disabled" />
</s:states>
.
.
.
<s:Transition  fromState="up" toState="over" autoReverse="true" >
  <s:AnimateColor  targets="{[ge1, ge2, ge3, ge4]}"  duration="250" />
</s:Transition>
<s:Transition  fromState="over" toState="up" autoReverse="true" >
  <s:AnimateColor targets="{[ge1, ge2, ge3, ge4]}" duration="750" />
</s:Transition>
.
.
.
<s:fill>
  <s:LinearGradient x="32.019" y="0.5" scaleX="25.5708" rotation="90">
	<s:GradientEntry id="ge1" color="#c0c0c0" color.overStates="#ffffff" ratio="0"/>
	<s:GradientEntry id="ge2" color="#939393" color.overStates="#e3e3e3" ratio="0.5"/>
	<s:GradientEntry id="ge3" color="#7e7e7e" color.overStates="#cecece" ratio="0.5"/>
	<s:GradientEntry id="ge4" color="#6a6a6a" color.overStates="#bbbbbb" ratio="1"/>
  </s:LinearGradient>
</s:fill>

There are also Animate effects that work on the strength of the DropShadowFilters. The SimpleMotionPath entries tell the Animate effect to work on the strength property. Note that there are no values defined on the effects & properties of the transitions. Flex automatically looks up the start and target values from the referenced states.

<s:Transition  fromState="over" toState="down" autoReverse="true" >
   <s:Animate duration="150" targets="{[dsfBg, dsfSymbol]}" >
	<s:SimpleMotionPath  property="strength" />
  </s:Animate>
</s:Transition>
<s:Transition  fromState="down" toState="*" autoReverse="true" >
  <s:Animate duration="150" targets="{[dsfBg, dsfSymbol]}" >
	<s:SimpleMotionPath property="strength"  />
  </s:Animate>
</s:Transition>
.
.
.
<s:filters>
  <s:DropShadowFilter id="dsfBg" alpha="0.5" blurX="0" blurY="0" distance="1" strength="1" strength.down="0"  />
</s:filters>
.
.
.
<s:filters>
  <s:DropShadowFilter id="dsfSymbol" blurX="0" blurY="0" distance="1"  strength="1" strength.down="0"/>
</s:filters>

Now, the buttons have a subtle effect when the mouse is rolled over and pressed: The gradient colors get lighter and the Shadows disappear giving the impression that the button is pressed.

Styles. Pseudo-, Type-, Id- & Class-Selectors

We defined the gradients in grayscale. What when we want colored buttons? No need to change the gradients. Flex automatically colors the components based on the baseColor style. We can set the baseColor for each state using pseudo selectors.  Here’s an example of how to style the button that shows all of the selector types (id-, type- and class-selectors):

@namespace mx "library://ns.adobe.com/flex/halo";
@namespace s "library://ns.adobe.com/flex/spark";
 
/*   
 *	Using ID selectors with compund selectors (type and class selectors) 
 *	to define the appearance of the buttons 
 */
 
/* Define normal state styles on spark button type inside a desc container */
#desc s|Button {
	skinClass: ClassReference('AHSimpleIconButtonSkin');
	baseColor: "0x505050" ; /* Do not use black black; /*"0x56d9e5";*/
	color: #FFFFFF;
}
 
/* Define over states styles on spark button type inside a desc container */
#desc s|Button:over {
	baseColor: "0x97CD20";
}
 
/* Define down states styles on spark button type inside a desc container */
#desc s|Button:down {
	baseColor: "0xa0d828";
}
 
/* compound. override the over state of the button in element desc for class styleClass blueButton */
#desc .blueButton:over {
	baseColor: "0x56d9e5";
}
 
/* compound. override the down state of the button in element desc for class styleClass blueButton */
#desc .blueButton:down {
	baseColor: "0x56d9e5";
}
 
/* compound. override the over state of the button in element desc for class styleClass redButton */
#desc .redButton:over {
	baseColor: "0xd52A03";
}
 
/* compound. override the down state of the button in element desc for class styleClass redButton */
#desc .redButton:down {
	baseColor: "0xE53A13";
}
.
.
.
<s:HGroup id="desc" horizontalCenter="0" verticalCenter="0" verticalAlign="middle" gap="5">
	<s:Button  label="Green" 	useHandCursor="true" buttonMode="true" />
	<s:Button  label="Blue" 	useHandCursor="true" buttonMode="true" styleName="blueButton"/>
	<s:Button  label="Red" 		useHandCursor="true" buttonMode="true" styleName="redButton"/>
</s:HGroup>

Colorization & Exclusion

By setting the baseColors for different states, Flex will colorize the component accordingly.  A dark grey in the up-state, a color in the over state and a lighter color in the down state.

The bad thing is that everything gets colorized. The good thing is that you can overwrite a function on SparkSkin to exclude elements from being colorized. We only want the background gradient to get colorized, so lets exclude the other elements from colorization:

<fx:Script>
<![CDATA[         
	/* Define the skin elements that should not be colorized. 
	exclude symbol and text group */
	static private const exclusions:Array = ["symbol", "textGroup"];
 
	/** 
	 * @copy spark.skins.SparkSkin#colorizeExclusions
	 */		
	override public function get colorizeExclusions():Array {return exclusions;}
]]>        
</fx:Script>
.
.
.
<!-- The group with the symbol with a shadow applied to. In a group for colorization exclusion -->
<s:Group id="symbol" verticalCenter="0" left="7" top="9" right="7" bottom="7">
	<s:filters>
		<s:DropShadowFilter id="dsfSymbol" blurX="0" blurY="0" distance="1"  strength="1" strength.down="0"/>
	</s:filters>
	<s:Path winding="nonZero" data="M12.6924 0L5.76855 6.92383 2.30762 3.46191 0 5.76855 3.46191 9.23145 5.76855 11.5391 8.07617 9.23145 15 2.30762 12.6924 0Z" >
		<s:fill>
			<s:SolidColor color="#ffffff"/>
		</s:fill>
	</s:Path>
</s:Group>

There is a group with an id ’symbol’ that is referenced in the exclusion array. Do the same for the label element.

Here’s a test and here’s the source (sdk 4.0.0.7282)

The solution is to use virtualization on the layout of the dataGroup. By setting useVirtualLayout=true, ItemRenderers are recycled, the performance will be fine even for 100′000 and more records (depending on complexity).

There are a couple of things to considerate:

• Since ItemRenderers are recycled you must take care of updating the components in your renderer to the correct state, so that they reflect the underlying data (i.e If the data states, that a player is a midfielder and you have a checkbox for this in your renderer, then make sure to set the state of this checkbox based on the underlying data, that is passed down). Also, the data object being pushed down from the Host-Component to the ItemRenderer could be null, so we have to check for this as well, preventing NPEs.
• Measurement will be approximate, either based on the first element, or a typical element you can reference or by setting rowHeight when using variableRowHeight=false.
• One drawback of virtualization is that when using the itemRendererFunction property, the renderers arent recycled. The function is expected to create an Instance (wrapped in a ClassFactory) of an appropriate renderer for the data-item being passed. I haven’t looked into this, but there could be a way of creating your own ItemRenderer pool and returning an suitable renderer from that pool.
• Checking the Profile, you’ll see that with virtualization the Renderers get reused, when virtualization is off, you’ll get as many Renderers as you have records.
• Another disadvantage is that virtualized layouts do not respect layout element’s includeInLayout property.
• In the Design Specification it is stated that “Virtual layouts with small numbers of items whose sizes vary dramatically will respond poorly to interactive thumb scrolling. Responsiveness will improve as the variation in size decreases and/or the length of the list increases”. In the test I did, I could not find any problems with poor responsiveness in scrolling, yet.

My findings are, that in practice the performance is very good on huge data sets when virtualization is used.  The drawbacks can be handled or are neglectable in many situation where thousands of rows must be used.

Here’s a simple test to check out virtualization and measurement when using increasing amounts of data.

VerticalLayout.variableRowHeight and HorizontalLayout.variableColumnWidth properties are set to true by default. This might affect performance in a bad way, since Flex has to determine the size of each child. Setting theses properties to false in conjunction with rowHeight / columnWidth or a typical element or the dimension of the first element can affect performance in a positive way.

DefaultItemRenderer that converts its data item to a single String for display in a Spark SimpleTextcontrol and the DefaultComplexItemRenderer that displays a component in a Group container. Each component is wrapped in its own Group container.

spark.components.supportClasses.ItemRenderer

• labelText String representation of the data-item.
• data The original data
• owner The Host-Component of the ItemRenderer. Can be used to fetch data.

A host-component that implements the IItemRendererOwner interface has methods where data is pushed down to the ItemRenderer

• itemToLabel() converts the data item to a String representation.
• updateRenderer()

One can overwrite these methods to manipulate data and the representation of the data.

Update: To be more precise (thanks to Steven Shongrunden@Adobe)

virtualization will be used even when an item renderer function is defined, but in that case item renderer recycling will not happen. Instead renderers will be created and destroyed roughly as they come in and out of view. (Compare this to the non-virtual case where every renderer is instantiated at startup). ItemRenderer recycling can be more performant than creation and destruction (depending on the renderers) so if you want to get the best performance it’s typically better to define an itemRenderer rather than an itemRendererFunction

The skin uses two additional properties (symbolColorChecked,  symbolColorUnchecked) for the color of the marks:

   s|CheckBox {
       skinClass: ClassReference("AHCheckboxSkin");
       symbolColorChecked: "0x70d000";
       symbolColorUnchecked: "0xe83800";
       fontSize: "11";
       color: "0x606060";
}

The skin goes like this:

.
.
.
 
	<fx:Script>
	<![CDATA[
		import mx.utils.ColorUtil;
		import mx.events.FlexEvent;
 
		[Bindable]	
		private var highlightColor:uint; 
 
		protected function sparkskin1_creationCompleteHandler(event:FlexEvent):void
		{
			hostComponent.buttonMode = true;
			hostComponent.useHandCursor = true;
			var col:uint = uint (hostComponent.getStyle('color'));
			highlightColor = ColorUtil.adjustBrightness(col, 80);
		}
	]]>
	</fx:Script>
 
 
	<fx:Declarations>
		<s:Linear id="easer" easeInFraction="0"  easeOutFraction="1" />
	</fx:Declarations>
 
	<s:states>
		<s:State name="up"  stateGroups="unchecked" />
		<s:State name="over" stateGroups="overStates, unchecked" />
		<s:State name="down" stateGroups="downStates, unchecked" />
		<s:State name="disabled" stateGroups="disabledStates, unchecked" />
		<s:State name="upAndSelected" stateGroups="selectedStates, checked" />
		<s:State name="overAndSelected" stateGroups="overStates, selectedStates, checked" />
		<s:State name="downAndSelected" stateGroups="downStates, selectedStates, checked" />
		<s:State name="disabledAndSelected" stateGroups="disabledStates, selectedStates, checked" />
	</s:states>
 
	<!-- Transitions for the mark -->
	<s:transitions>
		<s:Transition  fromState="over" toState="overAndSelected" >
			<s:Parallel target="{checkedMark}" >
				<s:Scale duration="250"  easer="{easer}" />
			</s:Parallel>
		</s:Transition>
		<s:Transition fromState="overAndSelected" toState="over" >
			<s:Parallel target="{uncheckedMark}">
				<s:Scale duration="250" easer="{easer}" />
			</s:Parallel>
		</s:Transition>
	</s:transitions>
 
	<!-- Label -->
	<s:SimpleText id="labelElement"
				  textAlign="start"
				  color.over="{highlightColor}"
				  color.down="{highlightColor}"
				  color.overAndSelected="{highlightColor}"
				  color.downAndSelected="{highlightColor}"
				  verticalAlign="middle"
				  lineBreak="explicit"
				  left="16" right="0" top="3" bottom="3" verticalCenter="2" />
	<!-- Group with the marks --> 
	<s:Group id="marks" verticalCenter="0" width="11" height="11" left="0" >
 
		<!-- GraphicElement for the checked-mark -->
		<s:Path horizontalCenter="0" verticalCenter="0" width="11" height="11" winding="nonZero" data="M 100 0 C 75.148 24.853 46.191 87.574 46.191 87.574 C 46.191 87.574 14.204 40.716 0 40.716 L 25.11 41.012 L 43.787 62.213 L 79.29 0 L 100 0 Z" 
				id="checkedMark" scaleX.unchecked="0" scaleX="1" scaleY.unchecked="0" scaleY="1">
			<s:fill>
				<s:SolidColor color="{hostComponent.getStyle('symbolColorChecked')}"/>
			</s:fill>
		</s:Path>
 
		<!-- GraphicElement for the unchecked-mark -->
		<s:Path horizontalCenter="0" verticalCenter="0" width="9" height="9" winding="nonZero" data="M 100 90.29 L 60.694 42.28 C 72.2 26.205 84.896 9.838 95.214 0 L 74.28 0.1 L 51.336 30.851 L 26.922 1.031 L 0 1.031 C 13.126 7.917 29.115 24.561 43.297 41.625 L 7.425 89.702 L 28.995 89.617 C 28.995 89.617 39.309 73.04 52.832 53.468 C 68.081 72.987 79.403 90.131 79.403 90.131 L 100 90.29 Z" 
				id="uncheckedMark" scaleX.checked="0" scaleX="1" scaleY.checked="0" scaleY="1">
			<s:fill>
				<s:SolidColor id="checkMarkFill" color="{hostComponent.getStyle('symbolColorUnchecked')}"/>
			</s:fill>
		</s:Path>
 
		<!-- Fake HitArea. TODO: Sort out how to use hitArea property, which does not seem to work correctly yet, but haven't investigated -->
		<s:Group width="100%" height="100%" alpha="0" >
			<s:Rect width="100%" height="100%"  >
				<s:fill>
					<s:SolidColor color="0xff0000" />
				</s:fill>
			</s:Rect>
		</s:Group>
 
		<s:filters>
			<s:DropShadowFilter distance="1" strength="0.75" blurX="1" blurY="1" />
		</s:filters>
	</s:Group>
.
.
.

FXG GraphicElements are used to draw the marks. The color of the marks are fetched from the hostComponents styles. The customs styles are set in the style definition of the CheckBox. When creation is complete some flags are set, so that the hand-cursor is shown when rolling over the label-field. An highlight-color for the label is calculated from the color-style-property and used in the over- and down-states. Transitions are use to have a scale-effect when the CheckBox is un(selected).

Test & source (sdk 4.0.0.7282) .

In a project I’m working on, we wanted to have a smooth transition when a text-input gets or loses focus. The default Spark TextInput and the associated skin-class do not have a focused state. (In Flex the FocusManager manages the focus by drawing a border around a component, but we wanted the focus on the skin itself and a transition)

One way to achieve this is to enhance the TextInput Component:

1.) Extend spark.components.TextInput
2.) Declare the additional SkinStates

public class AHTextInput extends TextInput {
 
	//Declare the additional SkinStates
	[SkinState("focused")];
 
	private var bfocused:Boolean;
 
	public function AHTextInput()
	{
		super();
	}
...

3.) Add Event-Listeners for the Focus-Event

//Add Event-Listeners to the textview for FocusEvent
override protected function partAdded(partName:String, instance:Object):void {
	super.partAdded(partName, instance);
	if (instance == this.textView) {
		trace ("Adding TextView");
		this.textView.addEventListener(FocusEvent.FOCUS_IN, onFocusInHandler);
		this.textView.addEventListener(FocusEvent.FOCUS_OUT, onFocusOutHandler);
	}
}
 
//Clean up Event-Listeners and stuff...
override protected function partRemoved(partName:String, instance:Object):void {
	super.partRemoved(partName, instance);
	if (instance == this.textView) {
		this.textView.removeEventListener(FocusEvent.FOCUS_IN, onFocusInHandler);
		this.textView.removeEventListener(FocusEvent.FOCUS_OUT, onFocusOutHandler);
	}
}
...

4.) Keep track of the state and leverage focused=false|true

//Handler for FocusIn Event
private function onFocusInHandler(event:FocusEvent):void {
	bfocused = true;
	invalidateSkinState();
	trace("Getting focus");
}
 
//Handler for FocusOut
private function onFocusOutHandler(event:FocusEvent):void {
	bfocused = false;
	invalidateSkinState();
	trace("Loosing focus");
}
//Gets called after invalidateSkinState() by Flex
override protected function getCurrentSkinState():String {
	if (bfocused) {
		return "focused";
	} else {
		return super.getCurrentSkinState();
	}
}
...

5.) Create a new Skin-Class which uses the additional states

<s:states>
    <s:State name="normal"/>
    <s:State name="disabled"/>
    <s:State name="focused"/>
 </s:states>
 
<!-- background --> 
<s:Rect blendMode="normal" left="1" right="1" top="1" bottom="1" radiusX="3" radiusY="3" alpha="1">
	<s:fill>
        <s:SolidColor id="bgFill" color="0xa2d2ff" color.focused="0xe8f8ff"  />
	</s:fill>
      <s:stroke>            
        <s:SolidColorStroke id="stroke" color="0x92c2ef" color.focused="0xffffff"  weight="1" />
      </s:stroke>
</s:Rect>
...

6.) Declare the transition inside the Skin-Class on the Elements you want

<!-- Transition from normal state to focused state and back -->
<s:transitions>
  <s:Transition fromState="normal" toState="focused" >
    <s:AnimateColor duration="350" targets="{[bgFill,  stroke]}" />
  </s:Transition> 
  <s:Transition fromState="focused" toState="normal" >
    <s:AnimateColor duration="350" targets="{[bgFill,  stroke]}" />
  </s:Transition> 
</s:transitions>
...

Test and source (sdk 4.0.0.7282). Note: textView has been renamed to textDisplay in the SkinnableTextBase.

<!--Library with the definitions -->
<Library>
   <Definition name="circle">
	<s:Ellipse x="0" y="0" width="100" height="100" >
	   <s:fill>
		<s:SolidColor color="0x000000" />
	   </s:fill>
	</s:Ellipse>
   </Definition>
</Library>
 
<!-- use some instances of the definition  -->
<circle/>
<circle x="200" y="100"/>
<circle x="300" y="100" height="75" width="75" />

As of now there is no way to create these symols at runtime. For example, if you’d like to create a starfield, you would need to place all the objects inside the document - not exactly elegant.

Fortunately there’s a hack that works. The Flex compiler creates classes of the Library-Definitions in the background, which opens a path to create instances at runtime.

The Flex-Compiler creates classes with the name [DocumentName]_definition[1..n] from the definitions in the library. Using actionscript we can the do something like this:

//create an instance of the graphic element. 
//The definition is declared in a document with the name 'MyLibrary'
var obj:GraphicElement = new MyLibrary_definition1();
 
//set some properties of the graphic element
var wh:Number = Math.random() * 25 + 25;
obj.width = obj.height = wh;
obj.x = Math.random() * container.width;
obj.y = Math.random() * container.height;
obj.blendMode = "screen";
 
//the definition is a FilledElement. Change fill to blue
var scf:SolidColor = SolidColor(FilledElement(obj).fill);
scf.color = 0x0000ff;
 
//container is just a group that holds the created elements
container.addElement(obj);

Relying on the fact that the Flex-Compiler creates classes for the definitions in the background might not be the best way, but it works. Let’s hope we’ll get something like FXGLibrary.createElement(libraryName:String, defintionName:String) in the future…

test & source (sdk 4.0.0.7282)

The skin uses two library definitions. One symbol for the active and one for the passive rating. The symbols are then placed in a passive and an active Group. A mask is used to show/hide the active group based on the rating. ActiveGroup/passiveGroup and mask are the required Skin-Parts.

The Component itself manages the rating and pushes this down to the mask by setting its width. The rating is exposed as a bindable property.

The following example usees the component with two different skins.

source is here (SDK 4.0.0.4932)