webroo.org » Flex

Bindable interfaces with custom events

Matt Sweetman — Sat, 06 Dec 2008 18:12:51 +0000

I’m surprised I haven’t stumbled across this before, but it caused a little head-scratching in a recent project. The problem involves having a class with a mixture of binding tags (i.e. with and without custom events), but assumes you are programming to the interface the class implements. In this case making it bindable proves a little unintuitive.

Imagine you have an class called Artist with two getter/setter properties: name and age. One of them uses a standard binding tag: [Bindable], the other uses a bindable tag with a custom event: [Bindable(event="artistAgeUpdate")]. Now you may be inclined to copy the tags into your interface and paste them above the getter/setter pair, like so:

package bindingTest
{
public interface IArtist
{
[Bindable]
function get name():String;
function set name(value:String):void;

[Bindable(event=“artistAgeUpdate”)]
function get age():int;
function set age(value:int):void;
}
}

But this will give you the following compiler error:

Error: [Bindable] not allowed on global or package-level functions

Also, putting a [Bindable] tag above the interface definition doesn’t work either, which is different to how classes work. The compiler won’t actually throw an error in this case, but the binding won’t work.

The propertyChange event

The solution is to specify an event for every bindable tag. This means you must use “propertyChange” for any normal [Bindable] tag used in your class. This is the event type the standard binding system dispatches. Take a look at PropertyChangeEvent in the Flex docs for more info.

package bindingTest
{
public interface IArtist
{
[Bindable(event=“propertyChange”)]
function get name():String;
function set name(value:String):void;

[Bindable(event=“artistAgeUpdate”)]
function get age():int;
function set age(value:int):void;
}
}

It seems classes and interfaces treat binding tags in slightly different ways. I guess the moral of the story is you should specify custom events for every bindable property. But that’s a lot of work. On the other hand it makes debugging those binding call-stacks a little easier as you can quickly identify the event type.

Quality Glow and Blur Flex effects

Matt Sweetman — Tue, 04 Nov 2008 15:03:46 +0000

The Glow and Blur effects are useful tweens that can be used to animate flash filters in Flex, the only problem is they don’t implement the quality property. It’s hard coded at a value of 1. In most cases this isn’t an issue, and where performance is concerned it’s best left unchanged. But having the extra control doesn’t hurt, especially considering a quality of even 2 or 4 can dramatically increase the smoothness a filter.

This shows the difference between a Glow effect with a quality of 4 and 1. As you can see the quality glow is far smoother. Adding the quality property onto Flex effects is quite simple, although it does require overriding two of the effect classes and duplicating a small amount of code.

Effect and EffectInstance

All Flex effects consist of subclasses of Effect and an EffectInstance. In the case of glow this is Glow and GlowInstance. Glow contains the properties and targets of the effect, and GlowInstance applies the actual filter. You need to subclass these and add the quality property to both:

package glowtest
{
import mx.effects.Glow;
import mx.effects.IEffectInstance;

public class QualityGlow extends Glow
{
// Add the quality property
[Inspectable(category=“General”, defaultValue=“1″)]
public var quality:Number;

public function QualityGlow(target:Object=null)
{
super(target);
// Our new class that applies the filter
instanceClass = QualityGlowInstance;
}

override protected function initInstance(instance:IEffectInstance):void
{
super.initInstance(instance);
QualityGlowInstance(instance).quality = quality;
}
}
}

Here I’ve added the ‘quality’ property and tagged it with Inspectable metadata, which ensures it’s available in MXML. Also, instanceClass is set to our new version of QualityGlowInstance, a new class which makes sure the underlying GlowFilter uses the property ‘quality’ in it’s constructor.

package glowtest
{
import flash.filters.GlowFilter;

import mx.effects.effectClasses.GlowInstance;

public class QualityGlowInstance extends GlowInstance
{
public var quality:Number;

public function QualityGlowInstance(target:Object)
{
super(target);
}

override public function onTweenUpdate(value:Object):void
{
setQualityGlowFilter(value[0], value[1], value[2], value[3]);
}

override public function onTweenEnd(value:Object):void
{
setQualityGlowFilter(value[0], value[1], value[2], value[3]);
super.onTweenEnd(value);
}

// setGlowFilter() is private in the superclass
// so we duplicate it’s functionality here:
protected function setQualityGlowFilter(color:uint, alpha:Number, blurX:Number, blurY:Number):void
{
var filters:Array = target.filters;

// Remove any existing Glow filters
var n:int = filters.length;
for (var i:int = 0; i < n; i++)
{
if (filters[i] is GlowFilter)
filters.splice(i, 1);
}

// Add quality property to GlowFilter:
if (blurX || blurY || alpha)
filters.push(new GlowFilter(color, alpha, blurX, blurY, strength, quality, inner, knockout));

target.filters = filters;
}
}
}

Apologies for the length of this class, but some code needed to be duplicated from the superclass. A common problem with the Flex framework is private methods, which means you cannot override them in a subclass. In this case setGlowFilter was the culprit, and in order change it’s functionality I had to duplicate the contents and change any references made elsewhere. This explains why the two onTween* methods are overridden.

Identical changes can be made to the Blur effect to get the quality property working, or simply download all the classes below.

Download source code here: qualityflexeffects.zip

Overlapping TabBar in Flex

Matt Sweetman — Wed, 27 Feb 2008 13:07:50 +0000

On a recent project I needed an overlapping tab bar, something that the default Flex TabBar doesn’t implement. While you can can easily change the spacing between tabs using a negative horizontalGap, you cannot retain a top-of-the-pile-like status for the selected tab. They are permanently stacked left-to-right on top of each other.

There’s a solution out there that relies on clever skinning techniques, but it’s a little time-consuming and inflexible. So after some poking around inside the Flex framework I discovered the underlying problem and came up with this solution:

Before I explain how I achieved this let’s take a look at the problem with the default TabBar:

The Problem

The example above shows the default TabBar functionality. Notice the right-hand side each tab is obscured by the next tab along, no matter which tab you select. The problem lies in the way TabBar arranges it’s children buttons. TabBar ultimately derives from Box, which uses the BoxLayout class to order sprites left-to-right based on their index in the display list. This means if you change the depth of a sprite in a Box it’s corresponding horizontal position will also change. So in our situation, changing the selected tab’s depth to the top causes the tab-sprite to be moved to the far-right of the box.

The Solution

Based on what’s overridable in TabBar the best solution is to manage the position of the tabs in the display list ourselves. To do this we need to subclass TabBar and store a fixed reference of the tabs in an array and dictionary. We then return these positions when the layout class arranges everything, which satisfies the layout routine’s desire to order everything left-to-right on depth. This then leaves us to manage the real sprite depths ourselves. Hopefully this code will explain it better:

public class OverlappingTabBar extends TabBar
{
// Used to store local reference to tabs
private var _tabs:Array;
private var _tabsDict:Dictionary;

public function OverlappingTabBar()
{
super();
_tabs = new Array();
_tabsDict = new Dictionary(true);
}

override protected function createNavItem(label:String, icon:Class = null):IFlexDisplayObject
{
var tabIndex:int = numChildren;
var navItem:IFlexDisplayObject = super.createNavItem(label, icon);
// Store tab refs in our array and dictionary
_tabs.push(navItem);
_tabsDict[navItem] = tabIndex;
return navItem;
}

override public function getChildAt(index:int):DisplayObject
{
return _tabs[index];
}

override public function getChildIndex(child:DisplayObject):int
{
return _tabsDict[child];
}

override public function removeChildAt(index:int):DisplayObject
{
// ensures tabs are cleaned up from our
// array and dictionary when removed
var c:DisplayObject = super.removeChild(getChildAt(index));
_tabsDict[getChildAt(index)] = null;
_tabs.splice(index, 1);
return c;
}
}

We’re simply storing the original position for each tab when it’s created in createNavItem(), then we return the stored position everytime getChildAt() and getChildIndex() is called (as it will be by the layout class). The overridden removeChildAt() ensures that our array and dictionary is kept up to date if tabs are removed from the bar, which occurs whenever the TabBar.dataProvider is changed.

Finally we need organise the tabs in the display list ourselves. The best location I found to do this was in hiliteSelectedNavItem(), as the method is passed the index of the selected tab.

override protected function hiliteSelectedNavItem(index:int):void
{
super.hiliteSelectedNavItem(index);
if (index != -1)
{
// z-order tabs
var l:int = _tabs.length - 1;
for (var i:int = 0; i <= l; i++) {
setChildIndex(_tabs[i], (l-i));
}
// put our selected tab at the top
setChildIndex(_tabs[index], l);
}
}

Of course it would look nicer with some decoratively sloped tab edges, but hopefully you get the idea. I admit that the code is a bit of a hack on top of the original component, and I can’t guarantee it won’t cause problems somewhere down the line, but iso far it’s proved robust. You should be able to swap out your original TabBar instances with OverlappingTabBar by simply renaming the MXML tag.

Download the source code here: OverlappingTabBar.as