Archive for Flex 4
CSS Changes in Flex 4
Posted by: | CommentsI recently purchased the book Adobe Flash Builder 4 and Flex 4 by David Gassner and will be publishing a complete review when I’m done with the book. I’m going through it looking for the coverage I feel would be most helpful for those experienced with Flex 3. Even more specifically, those like myself, who have been so busy with contracting work (because Flash is dead of course, and the only way to make a living as a contractor anymore is with HTML5 and CSS3) that they were only able to sample Gumbo during its development.
One such topic, which I happen to be going through now, are the additions to Flex 4’s CSS implementation over Flex 3. This information is available in a number of other places, so this post is more to help me internalize it than to be groundbreaking to everyone else.
1. CSS Namespaces
In order to support type selectors with the same name, CSS namespaces have been introduced. In Flash Builder selecting New->CSS File will show you what the syntax for declaring a CSS namespace is.
@namespace s "library://ns.adobe.com/flex/spark"; @namespace mx "library://ns.adobe.com/flex/mx";
If you’re not going to be using both Spark and Aeon/Halo in your application, you can declare the “default” namespace by omitting the prefix. Namespaces are used as follows:
s|Label { }
mx|Label { }
The lack of any white space between the namespace and the bar, and between the bar and the type selector is significant. Don’t include any white space there. Namespaces will need to be declared even for your custom components (I have a feeling this is going to get messy, but it’s for a good cause.)
2. Descendant Selectors
If you run into a situation where you want to use type selectors, but only when it is used in a particular container, you can use the descendant selectors. You can use them with your custom containers as well. The following declaration will affect all RichText editors contained within a Group:
s|Group s|RichText { color: #0000AA; }
This is another feature that could get out of hand, so use it wisely. Also don’t confuse this with declaring multiple type selectors on the same line, separating them with commas. Like this:
s|Group, s|RichText { color: #0000AA; }
3. ID Selectors
The ID selectors are similar to style name selectors. Recall with a style name selector, the CSS declaration has a name beginning with a ‘.’ and in the MXML declaration of the component you can use styleName="smallText", or something like that.
To use the ID selector, the styleName in the CSS is set to the id of the component you’re styling, prefixed with the # symbol. Like this:
<!-- The MXML Component --> <s:Label id="labelA" />
/* The CSS declaration */
#labelA { color: 0xFF00FF; }
Be sure you set the id explicitly in the MXML– this will not work if you have declared the component in ActionScript.
And that concludes my synopsis of the most important additions to CSS in Flex 4.
Extending the SkinnableComponent (well, sort of)
Posted by: | CommentsI won’t exactly be extending a SkinnableComponent in this post, I’ll be extending the Button (which extends SkinnableComponent) and creating a few new skins for it. Extending the SkinnableComponent is almost identical to extending the SkinnableContainer (see my previous post). You won’t need the contentGroup, of course.
I wanted to illustrate the power of Flex’s new skinnable architecture when combined with states.
Specifically I will show:
1. How easy it is to create multiple skins for the same class.
2. How easy it is to change skins at runtime via states.
For my collapsible panel, I need a button. All in all the button has 8 possible states: for each of the two expanded or collapsed states of the container, there are the 4 possible button states (up, down, over, disabled). Rather than suffer the madness of creating a skin with 8 possible states and the button class to manage them, I’m going to create two skins (one for expanded, one for collapsed), each which use the 4 standard button states.
I’ll include the full code for the CollapseButtonSkin, (which extends Skin). The code for ExpandButtonSkin is almost identical, except for the image names. The most important thing to note, is how I change the source of the Image using the new state syntax. I’ll be using that same syntax later in my panel.
<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/halo"
minWidth="12" minHeight="12" alpha.disabled="0.5">
<!-- host component -->
<fx:Metadata>
[HostComponent("com.googolflex.gflib.controls.ExpandCollapseButton")]
</fx:Metadata>
<!-- states -->
<s:states>
<s:State name="up" />
<s:State name="over" />
<s:State name="down" />
<s:State name="disabled" />
</s:states>
<mx:Image
source.down="@Embed('../assets/collapse_panel/collapse_down.png')"
source.over="@Embed('../assets/collapse_panel/collapse_over.png')"
source.up="@Embed('../assets/collapse_panel/collapse.png')"
source.disabled="@Embed('../assets/collapse_panel/collapse_over.png')" />
</s:Skin>
I didn’t do anything special in the ExpandCollapseButton class, I just extended Button (which contains the code to change between the up, down, over, and disabled states).
When I add my button to the QuickCollapsePanelSkin class, I specify a skinClass for each of my two panel states. When the state of the component changes, the button skins (which in turn have their own states) will be updated automatically. Here is the code:
<controls:ExpandCollapseButton
width="12" height="12"
top="{(SimpleQuickCollapsePanel(hostComponent).headerHeight - 12) / 2}"
left="4"
skinClass.collapsed="com.googolflex.gflib.skins.ExpandButtonSkin"
skinClass.expanded="com.googolflex.gflib.skins.CollapseButtonSkin"
click="SimpleQuickCollapsePanel(hostComponent).toggleExpanded()" />
You can download the full source for this example here: simple_collapsible_panel.zip
Extending the SkinnableContainer (attempt 1)
Posted by: | CommentsI’ve just created my first Flex 4 component, and loved doing it. It’s not entirely finished, but I wanted to share what I learned for those who may follow after me.
In the component proper, some things to remember:
1. Extend SkinnableContainer.
2. Declare the skin states using metadata brackets. In my case:
[SkinState("collapsed")][SkinState("expanded")]
3. Override getCurrentSkinState() to return one of the strings declared in #2, based on component state.
override protected function getCurrentSkinState() : String { if (expanded) return "expanded"; else return "collapsed";}
4. Call invalidateSkinState(), if necessary. Possibly done in setters or in commitProperties()
In the skin class, some things to remember:
1. Extend the SkinnableContainerSkin.
2. Declare the host component, the component you are skinning. Done as follows, using metadata tags:
<fx:Metadata>
[HostComponent("com.googolflex.gflib.containers.SimpleQuickCollapsePanel")]
</fx:Metadata>
If you need to access any properties of the extended class, ie SkinnableContainer you can do so by using the hostComponent variable. When I wanted to access members specific to my HostComponent, I had to cast hostComponent to a SimpleQuickCollapsePanel.
3. Declare the states of your skin. This may be done as follows:
<default:states> <mx:State name="collapsed"> <mx:State name="expanded"> </default:states>
4. Draw your layers or add your images to the skin as necessary. Reference your states, or hostComponent as necessary.
5. In the case of the SkinnableContainer you’ll want to make sure you add the container for its children. You can supply whatever layout you need, and can even change it based on state. It needs to be called contentGroup, however.
Here’s an example of how I did it:
<s:Group id="contentGroup"
left="3" right="3"
top="{SimpleQuickCollapsePanel(hostComponent).headerHeight+3}"
bottom="3"
visible="{SimpleQuickCollapsePanel(hostComponent).expanded}">
<s:layout>
<s:VerticalLayout />
</s:layout>
</s:Group>
I’ll be including the full source for my QuickCollapsePanel in my next post, where I describe extending the SkinnableComponent.
Update: In the most recent SDK release, the spark.skins.default package has been changed to the spark.skins.spark package. This affects the SkinnableContainerSkin class.
Stay tuned for the next update, when Adobe changes it to the spark.skins.spark.skins package…
Flex 4 and States (they finally got it right)
Posted by: | CommentsI’ve finally started a serious investigation into Flex 4. Unfortunately it takes me a while to get around to these things, especially in the middle of a project with 2 developer casualties thus far. The project is winding down a bit, the interaction designers are finally off the project, and I’ve had a bit more time to turn my attention to other things. It couldn’t have happened at a better time, either, since I’ll be giving a Flex 4 presentation at the local user group meeting this coming Tuesday (specifically on the MVC changes involving Flex components).
Anyway, I just have to say I am very impressed with the new “states” implementation. Though in many ways it’s still the same old states we had with Flex 2 and 3, the approach is much cleaner and much more in line with how such a feature should be used.
What has had the greatest effect is the separation of component behavior from component appearance. With this new separation comes a much clearer understanding that states are intended to manage component state. I think this must be what the architects originally introduced states for, but because the way it was implemented this purpose was a lost somewhat.
There’s a fine line between using states as a means to add and remove children from the Application or component based on changing application state, and using them to track component state. There are occasions when application state and component state are the same thing; there are many cases when they are not. The new approach makes it much easier to handle both cases, and to know when to use states and when not to…
Define your states in the component skin, and add a corresponding SkinState metadata tag to your component class. That’s where the states belong… there should be no need to have states or use the currentState property in your component class, though it inherits it from UIComponent.
Based on your data model, or user gestures, you should rely on one of the skins states (or a separate skin altogether) to change the view to match the state. There’s a method called getCurrentSkinState() where this can be handled, and it will be called after invalidateSkinState() is called (perhaps inside commitProperties().
In conclusion, though the nasty, nasty states syntax will become history, states should still be used judiciously.
