I decided to create a platform for city ratings and –rankings. I polished the whole thing a bit in the hope to attract some visitors. I wonder if I can get some peaks in traffic to see how this service will perform in GAE under load outside of a stress test.

To see what I’m talking abput, a first version is up and running at CityClash.org. To read about my experience with Google App Engine read on after the screenshot.

Building CityClash.org involved a couple of interesting aspects towards Google App Engine, the datastore and Spring MVC.

• The usual CRUD ops
• Transactions
• Joins & aggregation
• Long running processes
• REST-style with JSON response
• External API calls
• Developing for scalability

I used the SpringSource Tool suite with the GAE-Plugin for development. Setting up Spring with GAE was straightforward and worked as expected. Add the required jars and configure the spring project as you would normally do. Note, I’m referring to the MVC part of Spring and can’t speak for the other parts right now.

Spring 3 MVC

The REST-features and Ajax-simplifications in Spring MVC worked in GAE  just fine. This stuff is really well done in Spring and a joy to work with.

Task queues in GAE

Task queues in Google App Engine are a great way to speed up the user experience, by simply doing expensive work later and not during a user’s request. If some calculations need not to be done immediately task queues are worth considering.

When a city rating in CityClash comes in, I defer calculations of some statistical figures to a task queue. The user does not need to know about these figures immediately, it’s good enough when they get updated a couple of minutes later and the user gets a rather quick response.

Task queues are easy to set up. In a couple of lines you get a Queue from the Factory, create, configure the task and add it to the queue. The Queue will later invoke a HTTP-Request based on the Task. The actual work is then done in the handler that serves the request.

URL Fetch calling external apis

For Internationalization purposes I need to translate the city names to the local language. In CityClash.org I currently support German and English. Via Geocoding I get the English name but I need the German name as well. For Berne, Switzerland I need Bern, Schweiz too.

In Google Maps I could invoke another request asking for the German name, but I was a bit worried to get over the quota or get blocked for invoking too many requests at a rate too high. For this reason and for the fun of it, I decided to use the Google Translate API to get the localized name.

If CityClash gets a rating from a city that had not been rated before, the Google Translate API gets invoked and fetches the German name once. This is simple and straightforward. Use java.net.URL to open a connection and parse the stream. To not block the user’s request I put this step in a task queue as well.

Memcache

CC uses the cache as much as possible. I’m using the low level API. There’s not much to say about this. Put and get Serializable objects, use expiration and be sure to have a fallback if values in the cache get lost: it’s a cache not a permanent store.

Datastore

If you come from an SQL-background, then the datastore is probably the most difficult aspect to get used to. It took me a while to think out of the box and accept the limitations and embrace the blessings.

Here are a few key things to note from my newbie point of view and as of now:

• Loose the SQL-mindset. Forget about complex joins, nested queries and aggregation.
• What you get is sort of a distributed Hashtable, optimized for reads. The datastore is organized in a fashion, that lets it efficiently scan and read data. Stuff like filters (<,<=,= etc.), order by, ancestors or keys can be applied to the queries. But there are limitations of how you can combine the filters, orders etc. too.
• As to expect, reads are fast, especially when using keys.
• Don’t spoil this by trying to work around the limitations regarding joins and aggregation. Doings loads of calculations in memory to mimic such behavior won’t scale well and will cost you cycles.
• Instead store the data in a fashion that embraces the usage pattern.
  
• Try to do calculations once, when writing. Prepare the data for simple, efficient reads.
• If writing takes too long try to delegate some stuff to task queues and do the hard work later.
  
• Accept and embrace denormalization.
• Use task queues and cron jobs where possible to do long running processes in the background. In CC lots of aggregation is done in the background.
• Writes are expensive, since they may need reorganization. Be aware of contention.
• If writes have the potential to cause contention, consider sharding or use smaller entity groups.
  
• Transactions are there but only spanning over the same entity group . I tried to stay away of transactions alltogether – and denormalize.
• I stayed away from JDO and JPA because I could. Where’s the point of having another abstraction layer over a HashMap? I used the low level API in conjunction with objectify, which itself makes for a very good documentation on the datastore.
• There’s no full text search. The most you will get is a filter-order combination to mimick a sclaed-down LIKE on crutches.
  

Again, these are not necessarily best practices; they just reflect my take on the datastore of the appengine right now.

Mail

Sending mail is a no brainer and works straight out of the box. The only restriction is that the sender address of a message must be the email address of an administrator for the application.

Development Server

I have yet to discover any inconsistencies between the development server and the appengine in terms of behaviour. The test skeleton is pretty good too.

Flex

I didn’t bother to use the Spring Blaze integration. For the couple of requests and the few data I simply used the HTTPService. The new REST-full features paired with the JSON response made it easy to integrate Flex and Spring. Same applies to the Ajax-Calls through JQuery.

JSTL

My experience was, that there are some minor issues with JSTL inside GAE. For example, I could not get hold of an object-reference via the var attribute inside the forEach-Tag. Possibly my fault and I didn’t bother too much since the index-based approach using the varStatus-Attribute works fine. Further the formatNumber-Tag didn’t work since its implementation apparently needs a reference to the session. I did not want to turn on sessions (backed by memcache and the datastore) just for this, so I formatted the numbers in advance to be consumed by the page building.

Conclusion

So far I’m pretty impressed by GAE. It has restrictions and it took me some time to get used to the datastore first. But once you get the hang of it, things work out pretty straightforward.

And you get the advantages

• Scalability (can’t really judge on this right now),
• Pay for what you use
• Easy App versioning
• No Server-Management and maintenance.

While I can’t really judge on the first as of now, the last point especially, for me, is a real blessing.

After all, it depends whether your app can live within the constraints of GAE (mainly the datastore). I’d say Google App Engine is not the right tool for complex business applications as of now, but is a great environment for simple to moderately complex web-apps. For independent developers or startups the PaaS-approach might very well be the right thing.

Others don’t agree and I might change my opinion in 3 month or so after having seen CC run inside GAE for a while, but for now my first experience with google app engine was pretty pleasant.

The ruler can be scaled down or up by holding CTRL/SHIFT while clicking and can be moved by holding the ALT-Key and keeping the mouse button pressed. When scaling an animation is applied for smoother transitions. For the labels an array of Strings can be set, each one defining a division on the ruler. The number of subdivisions can be set as well

Simple ruler component. View source is enabled.

Custom GraphicElement to draw tick lines

Instead of using and FXG-Path element a custom GraphicElement has been created to draw the tick lines. This makes for a cleaner and more generic approach when drawing the ruler and reduces overhead when animation is applied while scaling.

Dynamic skin parts for the Labels

For the labels dynamic skin parts are used. Here’s a little recap on how to work with dynamic skin parts.

• Declare a dynamic skin part in the Declarations segment of the skin. Wrap it up in a Component and give the component an id.
• Declare the skin part in the component, referencing it via id in the skin. The type is of mx.core.IFactory.
• To create a dynamic skin part at runtime call createDynamicPartInstance([id of skin part]) from the component. This will return an instance of the desired skin part.
• In the component add this instance to the skin or a group within the skin.
• Optionally add it to an array for dynamically created instances for easier housekeeping.
• Any Listener is best added in partAdded() similar to adding behavior to static skin parts. When adding event listeners do not forget to remove them in partRemoved().
• A dynamic skin part can be removed at runtime by calling removeDynamicPartInstance([id of skin part], instance). You also need to manually remove the instance form the group you’ve added them.

If you need more information on dynamic skin parts, check out this great article by Florian Fesseler.

Now, it’s time for the GraphicElement.

Example using custom Graphic Elements. View source is enabled.

The GraphicElement and its subclasses are responsible to draw a significant amount of the Spark components graphics. FXG elements like Rect, Path, Line etc. all derive from GraphicElement.

A GraphicElement is actually neither a DisplayObject nor does it offer any form of interaction. Its super class is the EventDispatcher and it uses an internal DisplayObject to draw itself into. It does implement interfaces like IVisualElement and IGraphicElement and can therefore be laid out and displayed by Spark.

The internal display object used for drawing purposes is set and managed by Flex and multiple graphic elements can draw onto the same display object. Sharing display objects reduces overhead and in most cases leads to better performance.

This naturally has some implications which need to be considered when creating a custom GraphicElement

• A GraphicElement gets a DisplayObject to draw into and the display object might be shared. Both is managed by Flex.
• If a GraphicElement needs to be redrawn all other graphic elements that share the same DisplayObject will need to redraw themselves.
• If creating a custom GraphicElement which shares a display object with other graphic elements, make sure to not clear the graphics, as this would wipe out drawings that have formerly been made by other elements.
• Properties that are applied to the DisplayObject will be reflected by all graphic elements that share the same display object. Thus, the use of individual filters, color transformations, rotation etc. require the GraphicElement to own its own display object. The standard implementation takes care of this.
• Since GraphicElement is not a display object, we need to get a reference to the graphics object for drawing. We can get this reference form the drawnDisplayObject member.
• When drawing, the offset of the graphic element relative to its display object has to be taken into account.

Creating a custom GraphicElement

In most cases, there is no need to create a custom graphic element, as the FXG Path element can be used to draw most of the required paths. The FXG Path element takes a string of drawing commands, parses it and translates it to drawing commands that are applied to the display object.
This is well suited for static paths, e.g. the ones that are exported by Illustrator or Catalyst.

On the other hand, if a parameterized path is required we would need to dynamically build a string of graphic commands and Flex would need to parse them again, leading to unnecessary overhead. In such a case it might be better to create a custom GraphicElement that has the required properties and a drawing routine which takes them into account.

UPDATE: For the FXG-Path building approach see the great lightweight charts by Christophe Coenraets.

Creating a custom graphic element is straightforward, a few things must be considered though (see source in the example).

• Override the updateDisplayList() function to call the custom drawing routine, or the draw() function when using a StrokedElement or a FilledElement.
• Get the graphics object from (drawnDisplayObject as Sprite).graphics.
• Respect the coordinates of the GraphicElement relative to the one of its DisplayObject. The drawX and drawY properties of a GraphicElement store the required offset.
• Inside the drawing function do not clear the graphics since the element might use a shared display object and this would clear out graphics that have been drawn by other graphic elements.
• The GraphicElement class implements the IInvalidating interface and can therefore take part in the invalidation process. If a property is set that affects the drawing, call the required invalidation functions and do the update later in the validation pass.

Managing shared display object

The management of display objects for any GraphicElement is done by Flex via the Group that owns the element. In most cases there is no need to care about this, but if required, Flex offers some ways to indicate if a shared DisplayObject is ok to use or if an own display object is needed.

• Use needsDisplayObject() to indicate if a GraphicElement needs his own display object. The default implementation checks if any properties are used that require an own display object (rotation, color transformation, belnd modes etc.).
• Likewise canShareWithNext() and canShareWithPrevious() can be used to indicate if a GraphicElement can be drawn onto the same display object as the previous/next one in the queue.
• It is tempting to use the property displaySharingMode. This does not work as expected, as Flex uses this property to manage the objects and values set manually will be overwritten.
• If Flex needs to create a display object for a graphic element it calls its createDisplayObject() function. The default implementation returns an object of type InvalidatingSprite that implements the ISharedDisplayObject interface.

Interactivity

The purpose of the GraphicElement is to draw and manage graphics in an optimized manner (by sharing display objects). It is not an interactive element, the element is embedded within a Spark container and interaction should be done at a higher level.

To enable interactivity on a graphic element directly, a couple of things need to be done, which in most cases is actually bad practice. However, since this post is about inspecting the GraphicElement, let’s still see what needs to be done do to get interaction on a graphic element.

As mentioned above, the GraphicElement uses a DisplayObject to draw its graphics. The DisplayObject used by a GraphicElement is an InvalidatingSprite (extends from Sprite) that has the mouseEnabled and mouseChildren properties set to false. To get interactivity in a way that makes sense, we’d need to enable interaction on the InvalidatingSprite and disable display object sharing, as we do not want interaction to be affected by other graphic elements that share the same display object.

To turn on interactivity and to make sure interaction is not shared with other elements, we will need to

• override the createDisplayObject() function and
• set the mouseEnbled and mouseChildren properties of the returned DisplayObject to true
• add any listeners to the DisplayObject
• override needsDisplayObject() and return true
• likewise override canShareWithNext() and canShareWithPrevious() and return false

You’ll find the source code for this in the example. View source is enabled.

This of course undermines the attempt of Flex for optimization when drawing graphic elements. If interaction is needed directly on a custom graphic object it might be better to use a SpriteVisualElement that is in fact an interactive object. See the example of a ruler implemented as a SpriteVisualElelement.

Conclusion

The GraphicElement is Spark’s key class to do optimized drawing. If a parameterized path needs to be drawn that updates often, it might be a better choice to create a custom GraphicElement instead on relying on the FXG-Path element. Interactivity can be enforced but it is better to handle it on higher levels. If you need a really light weight visual element, that offers interaction and can still take part in the Spark layout process consider using SpriteVisualElement.

For more information on traversing GraphicElements (or IVisualElements in general) read this excellent write-up by Bill White.

In a project I created a custom PopUp, nothing fancy, just a couple of text inputs. When I tried to enable Tab key navigation I set the required properties but Flex would simply ignore tab key navigation to the input fields in the pop up.

The Documentation about the IFocusManager states that a pop up will get its own FocusManager and its own tab loop.

After some tracing I found that my pop up and its child weren’t included in the FocusManager as focus objects. In fact, there was no FocusManager for my pop up at all.

The reason for this is that when the PopUpMangerImpl is about to create and configure the pop up, it checks if the pop up is a IFocusManagerContainer so that focus can be added.

Unfortunately my popup was a Group which does not implement the IFocusManagerContainer interface. Naturally no FocusManager would be created.

If you want to use a Spark Group as your pop up, the solution is to create a new class that extends from Group and implements the IFocusManagerContainer. Then use this class as the container for the pop up.

.
.
.
public class AHPopUpGroup extends Group implements IFocusManagerContainer
	{
 
		public function AHPopUpGroup()
		{
			super();
		}
 
		/**
		 *  @private
		 *  Storage for the defaultButton property.
		 */
		private var _defaultButton:IFlexDisplayObject;
 
		[Inspectable(category="General")]
 
		/**
		 *  The Button control designated as the default button for the container.
		 *  When controls in the container have focus, pressing the
		 *  Enter key is the same as clicking this Button control.
		 *
		 *  @default null
		 */
		public function get defaultButton():IFlexDisplayObject
		{
			return _defaultButton;
		}
 
		/**
		 *  @private
		 */
		public function set defaultButton(value:IFlexDisplayObject):void
		{
			_defaultButton = value;
			ContainerGlobals.focusedContainer = null;
		}
 
	}
.
.
.

And the mxml for the pop up becomes something like this

.
.
.
 
		<!---
		Uses a Group that implements the IFocusManagerContainer
		-->
 
			.
			.
			.
			TextInput, Buttons etc now get focus on tab key navigation
			.
			.
			.
 
.
.
.

A class that gets less attention, but might be useful in a couple of scenarios to create a control alternatively, is the SpriteVisualElement class.

This example shows an implementation of a simple ruler by extending the SpriteVisualElement.

The SpriteVisualElement

The SpriteVisualElement is a display object that can be used inside spark containers.

It inherits from Sprite and implements the IVisualElement interface and can therefore take part in the spark layout process. This means, properties like height, width, top, right, bottom, left etc. can be used to lay out a SpriteVisualElement like an UIComponent.

As it inherits from Sprite you’ll get a reference to the Graphics object to draw onto and all the common events of a flash interactive object (mouse, gestures, focus etc.) - in other words, a flash sprite that can be used within the spark architecture.

The SpriteVisualElement is light-weight and might be the better choice to implement some interactive object if you can live without all the bells and whistles of the UIComponent. Less features, less overhead.

Use inside the Flex layout pass

Implementing the ruler is like coding a sprite in Flash but there’s a little additional work required to hook it up with the Spark layout pass.

During the layout pass Flex calls

• setLayoutBoundsSize(width:Number, height:Number, postLayoutTransform:Boolean=true)

We can override this function to call our drawing function.

override public function setLayoutBoundsSize(width:Number, height:Number, postLayoutTransform:Boolean=true):void 
{
	super.setLayoutBoundsSize(width, height, postLayoutTransform);
 
	//call our drawing function
	draw(width, height);
}

The ruler has properties for the number of divisions and subdivisions. Both require an update to the graphics so we need to tell Flex about this. We can achieve this by calling

• invalidateParentSizeAndDisplayList()

This will mark the parent component as invalid and will finally trigger a call to setLayoutBoundsSize on our object where we can redraw the graphics based on the updated values of the properties.

public function set divisions(value:int):void
{
	_divisions = Math.max(1, value);
	invalidateParentSizeAndDisplayList();
}

Conclusion

Depending on the requirements, you might want to - and usually do - use the full stack (SkinnableComponent/SparkSkin with nested components and FXG). Still, under some circumstances and regarding resources and performance, implementing a simple component as a SpriteVisualElement may be an option to be considered. Also note, a SpriteVisualElement can live within a spark container, thus you can add it to any skin and mix it up with FXG elements or Spark components.

Click here for the demo. View source is enabled.

For a current project, I needed more like a balloon help in place of tooltips and therefore decided not to use Flex default tooltips.

Regarding usability of the tooltips (balloon help) I want to be able to

• Display an optional tooltip title
• Display formatted tooltip text
• Display icons
• Colorize the tooltip based on the semantic of the invoking control
• Consistent Placement
• Have all title, text, styles for the tooltips stored in a central location
• Have the tooltips work in a generic and Flex-compliant way

Flex gives you a few ways to customize tooltips from registering your custom ToolTip class to intercepting Tooltip events where you can hook up the custom tooltip. All of these approaches fall either short of the requirements I had or would add additional overhead so I simply created a custom ToolTipManager that would alter the behaviour of the default ToolTipManager.

Here’s a demo of the final result, the approch is described further down.

Since I like to have all resources centralized, the approach I followed was to interpret the value of the tooltip- or the errorString property on a control not as the tooltip text to display but as a partial key to lookup title, text, styles etc. in a resource bundle. Form this partial key concrete keys would be derived to lookup the values for a controls tooltip.

For example

<s:Button label=”OK” tooltip=”ToolTipBundle.okButton” />

would point to the ResourceBundle named  ‘ToolTipBundle’ and within this to all entries of a key starting with tooltip.okButton. Then the values for title, text etc. will be looked up by the custom ToolTipManager implementation and be applied to the tooltip.

The first token in the tooltip property specifies the name of the resource bundle, the second token the partial key for looking up the entries in the resource bundle. If no second token is specified the id (if any) of the component is being used.

Entries in the resource bundle then refer to the partial key submitted and define the concrete values to use for the tooltip.

tooltip.okButton.title=Title of Tooltip
tooltip.okButton.text=Text for this tooltip
tooltip.okButton.styleName=CSS class to use for this tooltip
tooltip.okButton.placement=bottomRight|bottomLeft|topRight|topLeft
tooltip.okButton.color=Color of text
tooltip.okButton.chromeColor=Color of tooltip

Color and chromeColor are there for convenience but can also be set via the CSS class specified by styleName. If any of the entries are not specified fallbacks to default values are used.

To make this work some methods of the default ToolTipManager need to be overwritten

override mx_internal function initializeTip():void

This is where the cstom implementation looks up the values and assigns them to the tooltip.

Additionally there’s the

override mx_internal function positionTip():void

method to position the tooltip in a custom way.

The custom ToolTipManager implementation is registered at loading using a custom preloader class.

The custom Tooltip itself  is a simple SkinnableComponent associated with a SparkSkin. There’s a required skin part for the text and a dynamic skin part for the label that only gets added if any value for a title  is provided.

For both title and text a RichText component is used within the skin so that formatting the text in a rich way is possible. The associated skin is then responsible to draw the tooltip based on the provided placement.
Having set this up, usage of the custom tooltips for any app is simple.

<s:Application               
    preloader="com.hulstkamp.flex.spark.preloaders.CustomMixinPreloader">
</s:Application>

This will register the custom ToolTipManager.

For additional documentation see the source in the demo (view source is enabled).

Since they’ve been built on beta sdks, these components might need some adjustments to work with the Flex 4 release sdk.

To save you the work of figuring out what to adjust here are the most requested components updated to Flex 4 release sdk. Click on the images, view source is enabled.

Flex 4 Spark Rating Component. View source enabled. Original post here.

Flex 4 Spark Icon Button based on a generic skin.View source enabled. Original post here.

Flex 4 Spark icon button. View source enabled.Original post here.

Flex 4 Spark custom checkbox. View source enabled. Original post here.

Flex 4 Spark custom knob button. View source enabled. Original post here.

In addition to this the flag useChromeColor can be set to tell the SparkSkin to use chromeColor for colorization. For custom skins this can be set by overriding initializationComplete() in the skin.

override protected function initializationComplete():void  {
 
	useChromeColor = true;
	super.initializationComplete();
}

Internally Flex checks this flag in updateDisplayList() of a SparkSkin and uses the value in chromeColor for colorization (respecting exclusions in get colorizeExclusions()).

If you are using Gumbo-Components from this blog that use baseColor be sure to make these adjustments.

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

Source updated to release sdk.

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)

Source updated to Flex 4 release sdk.

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.