With Flex 4 having been in beta for ages and hopefully soon to be released, it really was time I started to get my head around the spark components and how to approach to skinning them. Rather starting off with the usual button, I thought I’d kick off with getting a ResizeableTitleWindow going. Of course a few others have already created variants. I think everyone using Flex at some point needs a resizeable version of TitleWindow. To that end, looking at the TitleWindow specification page of the Flex 4 wiki, clearly Adobe planned on implementing resize behaviour on the TitleWindow. It doesn’t seem to be implemented yet. So in the meantime my version is as close as I think I can get to that specification.
The end result (view source enabled):
My 1st spark skin
In the running example above, window ‘A’ is a normal instance of spark.components.TitleWindow. This leads me to my first spark skin. If you are viewing on a windows or linux platform it won’t look any different from normal. In that case it is simply using spark.skins.spark.TitleWindowSkin. However if you are viewing on a Mac you’ll notice that the close button is located at the left of the title bar rather than the right. This is where a Mac user will expect it to be – but the default in Flex is currently to the right, no matter what platform. This was achieved through the most basic technique of skinning a spark component : clone an existing skin, adapt it and apply it. To that end, spark.skins.spark.TitleWindowSkin was cloned to creacog.spark.skins.TitleWindowMacSkin, and a couple of lines changed swap around the closeButton and title. We switch skins if we are on the mac platform by loading the compiled Mac style sheet in the preinitialize handler of main.mxml.
This technique of cloning is one thing that initially feels slightly wrong with spark. It leads to a lot of duplicate code which is something developers normally do their best to avoid. The reasoning seems mainly to facilitate Flash Catalyst workflow, where skins are predominantly the domain of interaction designers for whom duplication is the norm and code re-use doesn’t really figure. However until and unless Flash Catalyst matures into a product that can support round-trip editing, there’s a good chance that developers will be making a lot of use of diff tools and duplicate code across skins is something we’ll probably just get used to. The subject has been discussed in detail in a number of other blogs and their comments:
- Flex 4 skinning ignores developer needs
- Using Flex 4 Skin Inheritance To Make PictureButton Component
Implementing and skinning ResizeableTitleWindow
We now need to know a little more about the mechanics of spark skinning. I must admit having previously read some blogs and watched some video posts of how simple spark skinning is – and I got it until sitting in-front of an empty editor scratching my head – where to begin? The key thing that crystallised it for me was to read the skinning contract.
So, first was to create the component class. This extends spark.components.TitleWindow. It adds a new optional skin part of resizeHandle of type UIComponent. Essentially we need something the user can click on no matter what it’s appearance. creacog.spark.events.TitleWindowBoundsEvent was created extending spark.events.TitleWindowBoundsEvent with the new event constants for resizing. Using the creacog package is the main deviation from the specification – for obvious reasons.
Catalyst was used to create the ResizeHandleSkin. A simple custom component with two states: up and over. It has a semi-transparent white background that transitions it’s alpha on mouse over. Importing ResizeHandle.fxpl into the flex project resulted in slightly odd packaging. Simply moving ResizeHandle.mxml to the creacog.spark.skins package brought it into structure consistent with the rest of the project.
spark.skins.spark.TitleWindowSkin was again cloned, this time to creacog.spark.skins.ResizeableTitleWindowSkin. To that 3 new lines is all that was required to add an instance of the resizeHandle skin part – positioned front-most and at the bottom right corner. It could be any size and positioned anywhere, but the logic behind resize adjusts the width and height of the component, leaving it’s x and y untouched.
creacog.spark.skins.ResizeableTitleWindowMacSkin is a further clone, this time with the closeButton skin part positioned to the left for mac users.
Finally we use styles (being careful of the new namespace syntax) to the notify the flex framework to use creacog.spark.skins.ResizeableTitleWindowSkin (and substitute creacog.spark.skins.ResizeableTitleWindowMacSkin on the Mac) whenever a ResizeableTitleWindow instance is drawn. If we omitted this step, the ResizeableTitleWindow instance would be created, but it would fall back to using the TitleWindowSkin which does not include the resizeHandle skin part and therefore the resizing functionality would be ignored.
This new approach to skinning components feels far superior to what we have been used to in Flex 3. I’m slightly scared that the workflow from designer via catalyst could result in inflexible skins (at least in the short term), as post-production work is required of the developer if the skin is intended to take on runtime styling for example. Lack of any sign of round-trip capability means skin production is currently one way from catalyst. i.e. tweaks or changes within catalyst will create a new output and it will be for the developer to merge the changes with additions s/he may have implemented on previous skins.
Looking forward to getting going on some real flex 4 projects.