Seit iOS 5 werden die Methoden setBackgroundImage: forState: barMetrics: und setDividerImage: forLeftSegmentState: rightSegmentState: barMetrics: bereitgestellt, mit denen das Aussehen der Komponente im Handumdrehen verändert werden kann.

Der verwendete Code für die obrige Darstellung sieht folgendermaßen aus:

    // navigation is an UISegmentedControl
    // BACKGROUND
    // unselected
    UIImage *unselected = [[UIImage imageNamed:@"unselected.png"]
                           resizableImageWithCapInsets:UIEdgeInsetsMake(0, 15, 0, 15)];
    [[self navigation] setBackgroundImage:unselected
                                           forState:UIControlStateNormal
                                         barMetrics:UIBarMetricsDefault];

    // selected
    UIImage *selected = [[UIImage imageNamed:@"selected.png"]
                         resizableImageWithCapInsets:UIEdgeInsetsMake(0, 15, 0, 15)];
    [[self navigation] setBackgroundImage:selected
                                           forState:UIControlStateSelected
                                         barMetrics:UIBarMetricsDefault];

    // DIVIDER
    // unselected/unselected
    UIImage *unselectedUnselected = [UIImage imageNamed:@"unselected_unselected.png"];
    [[self navigation] setDividerImage:unselectedUnselected
                             forLeftSegmentState:UIControlStateNormal
                               rightSegmentState:UIControlStateNormal
                                      barMetrics:UIBarMetricsDefault];

    // selected/unselected
    UIImage *selectedUnselected = [UIImage imageNamed:@"selected_unselected.png"];
    [[self navigation] setDividerImage:selectedUnselected
                             forLeftSegmentState:UIControlStateSelected
                               rightSegmentState:UIControlStateNormal
                                      barMetrics:UIBarMetricsDefault];

    // unselected/selected
    UIImage *unselectedSelected = [UIImage imageNamed:@"unselected_selected.png"];
    [[self navigation] setDividerImage:unselectedSelected
                             forLeftSegmentState:UIControlStateNormal
                               rightSegmentState:UIControlStateSelected
                                      barMetrics:UIBarMetricsDefault];

Die Eigenschaften des Labels können mit der Methode setTitleTextAttributes: forState: verändert werden.

   // navigation is an UISegmentedControl
   // STATE NORMAL
    [navigation setTitleTextAttributes:
     [NSDictionary dictionaryWithObjectsAndKeys:
      [UIColor colorWithRed:1.0 green:1.0 blue:1.0 alpha:1.0],
      UITextAttributeTextColor,
      [UIColor colorWithRed:0.0 green:0.0 blue:0.0 alpha:0.8],
      UITextAttributeTextShadowColor,
      [NSValue valueWithUIOffset:UIOffsetMake(0, -1)],
      UITextAttributeTextShadowOffset,
      nil] forState:UIControlStateNormal];

    // STATE SELECTED
    [navigation setTitleTextAttributes:
     [NSDictionary dictionaryWithObjectsAndKeys:
      [UIColor colorWithRed:1.0 green:0.0 blue:0.0 alpha:1.0],
      UITextAttributeTextColor,
      [UIColor colorWithRed:0.0 green:0.0 blue:0.0 alpha:0.8],
      UITextAttributeTextShadowColor,
      [NSValue valueWithUIOffset:UIOffsetMake(0, -1)],
      UITextAttributeTextShadowOffset,
      nil] forState:UIControlStateSelected];

Das hier verwendete Beispiel verändert die Farbe der Labels für den normalen und selektierten Zustand.

Die verwendeten Grafiken für die Segmente selber sind nicht auf die Buttonform beschränkt. Hier ein Beispiel, in dem die Segmente eher an Tabs erinnern:

Das komplette Beispiel mit allen Grafiken und dem Code könnte ihr hier als Xcode-Projekt herunterladen.

Aber wann ist nun der richtige Zeitpunkt um EventListener in ItemRenderern wieder abzumelden? Da die meisten Flex-Komponenten die Renderer intern wiederverwenden (es wird lediglich die data-Eigenschaft des Renderers geändert), besteht die Möglichkeit bei Änderungen dieser Eigenschaft die Listener abzumelden.

private var _dataChanged:Boolean;

    /**
     * @inheritDoc
     */
    override public function set data(value:Object):void {
        if (data != value) {
            if (data) {
                removeDataListener();
            }
            super.data = value;
            _dataChanged = true;
            invalidateProperties();
        }
    }

    /**
     * @inheritDoc
     */
    override protected function commitProperties():void {
        super.commitProperties();

        if (_dataChanged) {
            _dataChanged = false;
            if (data) {
                addDataListener();
                // do other stuff here
            }
        }
    }

    protected function removeDataListener():void {
        // remove data listener
    }

    protected function addDataListener():void {
        // add data listener
    }

Leider ist dies nur die halbe Miete. Was passiert wenn die Flex-Komponente, die die Renderer verwendet, oder der Renderer selbst aus der DisplayList entfernt wird? Es existieren immer noch die Listener innerhalb des Renderers, der dadurch vor der GarbageCollection (GC) geschützt wird. Dies betrifft nur Listener die nicht als weak-Listener angemeldet wurden.

Aus diesem Grund melden wir uns für das Event “REMOVED_FROM_STAGE” an und sorgen dafür, dass alle Listener abgemeldet werden. Lediglich der Listener für das Event “REMOVED_FROM_STAGE” bleibt bestehen, da es vorkommen kann, dass eine Flex-Komponente ihre Renderer aus der DisplayList nimmt und später wiederverwendet. Der Renderer wird trotz des “REMOVED_FROM_STAGE”-Listeners von der GC entfernt, da dieser als weak-Listener angemeldet wurde.

package {

import flash.events.Event;
import mx.core.EventPriority;
import spark.components.supportClasses.ItemRenderer;

public class BaseItemRenderer extends ItemRenderer {

    private var _dataChanged:Boolean;

    /**
     * Constructor.
     */
    public function BaseItemRenderer() {
        addEventListener(Event.REMOVED_FROM_STAGE, onRemovedFromStage, false, EventPriority.DEFAULT, true);
    }

    /**
     * @inheritDoc
     */
    override public function set data(value:Object):void {
        if (data != value) {
            if (data) {
                removeDataListener();
            }
            super.data = value;
            _dataChanged = true;
            invalidateProperties();
        }
    }

    /**
     * @inheritDoc
     */
    override protected function commitProperties():void {
        super.commitProperties();

        if (_dataChanged) {
            _dataChanged = false;
            if (data) {
                addDataListener();
                // do other stuff here
            }
        }
    }

    // Should be used to free all unused data.
    protected function dispose():void {
        data = null;
        // do other stuff here
    }

    protected function removeDataListener():void {
        // remove data listener
    }

    protected function addDataListener():void {
        // add data listener
    }

    private function onRemovedFromStage(event:Event):void {
        dispose();
    }
}
}

Die endgültige Version des hier vorgestellten ItemRenderers könnt ihr hier herunterladen.

public class LoginMediator extends Mediator
{
	override public function onRegister():void {
		view.addEventListener(Event.A, eventAHandler);
		view.addEventListener(Event.B, eventBHandler);
		...
		view.addEventListener(Event.Z, eventZHandler);
	}

	override public function onRemove():void {
		view.removeEventListener(Event.A, eventAHandler);
		view.removeEventListener(Event.B, eventBHandler);
		...
		view.removeEventListener(Event.Z, eventZHandler);
	}

	private function get view():DisplayObject{
		return DisplayObject(viewComponent);
	}
}

Dabei muss der Entwickler selbst darauf achten, dass er auch wirklich alle Eventlistener wieder abmeldet.
Das Framework Robotlegs bietet für diesen Fall einen automtisierten Ansatz, dort werden selbstständig alle registrierten Eventlistener abgemeldet sobald ein Mediator entfernt wird. Diese Funktionalität habe ich für das PureMVC Framework adaptiert und eine neue Mediatorklasse erstellt.
Alle Eventlistener die über die Methode “addViewListener” registriert werden, werden automatisch beim entfernen des Mediators Abgemeldet.
Sodass das vorherige Beispiel nun so aussieht:

public class LoginMediator extends EventMapMediator
{
	override public function onRegister():void {
		addViewListener(Event.A, eventAHandler);
		addViewListener(Event.B, eventBHandler);
		...
		addViewListener(Event.Z, eventZHandler);
	}

	private function get view():DisplayObject{
		return DisplayObject(viewComponent);
	}
}

Die EventMap selber ist nicht vom Mediator abhängig und kann somit auch in Viewkomponenten verwendet werden. Dort muss sich aber selber darum gekümmert werden, die Eventlistener auch wieder zu entfernen, um Memoryleaks zu vermeiden.

Die Klassen findet ihr hier als Zip-Datei zum Download.

package {
import mx.controls.Tree;
import mx.core.IFactory;

/**
 * Adds support for multiple itemRenderer.
 * The default implementation of the tree supports only one type of renderer for all items.
 */
public class ExtendedTree extends Tree {

    /**
     * This method is used to retrieve a factory which creates an itemRenderer for an object.
     * The signature of the function should look like: "myCustomFunction(data:Object):IFactory"
     */
    public var resolveItemRendererFunction:Function;

    /**
     * @inheritDoc
     */
    override public function getItemRendererFactory(data:Object):IFactory {
        if (resolveItemRendererFunction != null) {
            return resolveItemRendererFunction(data);
        } else {
            return super.getItemRendererFactory(data);
        }
    }
}
}

Hier sieht man den Unterschied zwischen der erweiterte Komponente (links), welche zwei verschiedene ItemRenderer verwendet, und der normalen Tree-Komponente (rechts):

Das Beispiel aus den Screenshoots kann hier heruntergeladen werden.

Erstellen der Variable (Xcode 4.1):
Mit gedrückter alt-Taste auf den Run-Button klicken.
Durch die gedrückte Taste öffnet sich ein Fenster in dem diverse Einstellungen vorgenommen werden können. Im Fenster auf den Reiter “Arguments” gehen und unter “Environment Variables” eine neue Variable mit dem Namen NSZombieEnabled erstellen und ihr den Wert YES zuweisen.

Nach dem Debuggen sollte diese Variable wieder entfernt oder zumindest auf FALSE gesetzt werden, da ansonsten Memoryleaks entstehen!

Da jede so markierte Property ein PropertyChangeEvent versendet, wird zusätzlich geprüft, welche Property geändert wurde. Wird ein Objekt nun an eine Property einer komplexen Klasse (viele [Bindable]-markierte Properties) gebunden, führt dies zu spürbaren Performanceeinbußen.

Dem kann jedoch Abhilfe geschaffen werden, indem im [Bindable]-Tag zusätzlich noch das Event definiert wird (z.B. [Bindable (event="xyChanged")]), welches bei einer Änderung der Property versendet wird. Leider generiert der Compiler nicht die entsprechende Benachrichtigung, so dass der Programmierer selber dafür sorgen muss, das Event zu versenden.

package
{
    import flash.events.EventDispatcher;
    import flash.events.Event;

    public class ExampleVO extends EventDispatcher
    {
        private var _description:String;

        [Bindable(event="descriptionChanged")]
        public function get description():String {
            return _description;
        }

        public function set description(value:String):void {
            if (_description !== value) {
                _description = value;
                if (hasEventListener("descriptionChanged")) {
                    dispatchEvent(new Event("descriptionChanged"));
                }
            }
        }
    }
}

Dies erfordert einige Zeilen mehr Code. In komplexen Anwendungen kann dadurch einiges an Performance gewonnen werden, da nun das ermitteln der geänderten Property entfällt.

<fx:Script>
	<![CDATA[
			import net.reppa.utils.collections.VectorCollection;
			import net.reppa.utils.collections.VectorList;

			private function initializeComboBox(vector:Vector.<int>):void{
				comboBox.dataProvider = new VectorCollection(vector);
				// or
				//comboBox.dataProvider = new VectorList(vector);
			}
	]]>
</fx:Script>

<s:ComboBox id="comboBox" />

Die Klassen findet ihr hier als Zip-Datei zum Download.

Im ANT-Buildscript wird zuerst die aktuelle Zeit an eine ANT-Property “compiletime” übergeben:

	<tstamp>
		<format property="compiletime" pattern="dd.MM.yyyy, HH:mm:ss" />
	</tstamp>

Diese Property wird dann im mxml-Task per “define” als Compilerargument hinzugefügt:

	  <mxmlc file="${SRC_DIR}/Main.mxml" output="${DEPLOY_DIR}/Main.swf">
	  	<define name="CONFIG::COMPILE_TIME" value="'${compiletime}'"/>
	  	<load-config filename="${FLEX_HOME}/frameworks/flex-config.xml"/>
		<source-path path-element="${FLEX_HOME}/frameworks"/>
	  	<compiler.debug>false</compiler.debug>
	  </mxmlc>

Der Quellcode zu diesem Beispiel kann hier heruntergeladen werden.

override public function set data(value:Object):void
{
	if (value != data)
	{
		super.data = value;
		BindingUtils.bindSetter( onPropertyChanged, value, "property" );
	}
}

ItemRenderer werden innerhalb von Komponenten wiederverwendet, d.h. ein ItemRenderer bekommt während seiner Lebenszeit verschiedene Datenobjekte zur Darstellung übergeben. Da wir im oben gezeigtem Code das Binding für die vorherigen Daten nicht entfernen wenn ein neues Datenobjekt gesetzt wird, würde der ItemRenderer auch Änderungen vom alten Datenobjekt mitbekommen. Was dazu führen kann das falsche Informationen angezeigt werden, nämlich dann wenn Properties des alten Datenobjektes verändert werden. Oder das die mit dem Binding verknüpfte Methode “onPropertyChanged” mehrfach aufgerufen wird wenn sich die Property des alten und neue Datenobjektes ändert. Ein weiterer Nachteil ist, dass ein gebindetes Datenobjekt nicht von der Garbage Collection gelöscht werden kann solange das Binding existiert.

Um ein über die BindingUtils-Klasse erstelltes Binding zu entfernen muss die ChangeWatcher-Instanz, die die Klasse bei der Erstellung eines Bindings zurück gibt aufgehoben werden. Über diese Instanz kann das Binding gelöscht werden. Benötigt ein ItemRenderer mehr als ein Binding müssen die ChangeWatcher-Instanzen in einer Liste gespeichert werden um diese später wieder aufzuheben.
Das könnte in etwa so aussehen:

private var _changeWatcherList:Array = new Array();

override public function set data(value:Object):void
{
	if (value != data)
	{
		super.data = value;

		// remove old bindings
		for (var i:int = 0; i < _changeWatcherList.length; i++)
		{
			ChangeWatcher(_changeWatcherList[i]).unwatch();
		}
		_changeWatcherList = new Array();

		// create new bindings
		_changeWatcherList.push( BindingUtils.bindSetter( onProperty1Changed, value, "property1" ) );
		_changeWatcherList.push( BindingUtils.bindSetter( onProperty2Changed, value, "property2" ) );
		_changeWatcherList.push( BindingUtils.bindSetter( onProperty3Changed, value, "property3" ) );
	}
}

Man sieht an diesem Beispiel, das einige Zeilen mehr Code notwendig sind um die erstellten Bindings zu verwalten. Für diesen Zweck habe ich eine Klasse geschrieben die Bindings erstellt und in einer Liste speichert um diese später über die Methode “clear” zu löschen.

private var _bindingMap:IBindingMap = new ArrayBindingMap();

override public function set data(value:Object):void
{
	if (value != data)
	{
		super.data = value;
		// remove old bindings
		_bindingMap.clear();
		// create new bindings
		_bindingMap.bindSetter( onProperty1Changed, value, "property1" );
		_bindingMap.bindSetter( onProperty2Changed, value, "property2" );
		_bindingMap.bindSetter( onProperty3Changed, value, "property3" );
	}
}

Die BindingMap-Klasse findet ihr hier.

Um den Mausklick auf den ColumnHeader eines Datagrids festzustellen, muss dafür die Klasse mx.controls.dataGridClasses.DataGridHeader erweitert werden die vom Datagrid zur Darstellung des Headers verwendet wird. Innerhalb dieser Klasse wurden die Methoden mouseDownHandler und mouseUpHandler überschrieben. Dadurch ist es möglich, den Mausklick des Headers über das Datagrid dem User mitzuteilen.

Das modifizierte Datagrid kann wie folgt verwendet werden:

<mx:Script>
		<![CDATA[
		import mx.events.DataGridEvent;

		private function onHeaderClicked(event:DataGridEvent):void
		{
			this.output.text = "index=" + event.columnIndex + " \theaderText='" + event.itemRenderer.data.headerText + "'";
		}
		]]>
	</mx:Script>

	<local:ExtendedDataGrid
		headerClicked="this.onHeaderClicked(event);"
		selectionColor="0xFF0000"
		sortableColumns="false"
		draggableColumns="false">
		<local:columns>
			<mx:DataGridColumn headerText="Col A" />
			<mx:DataGridColumn headerText="Col B" />
			<mx:DataGridColumn headerText="Col C" />
		</local:columns>
	</local:ExtendedDataGrid>

	<mx:Label id="output" textAlign="center" width="100%" text="click on a column-header" />

Der Quellcode zu diesem Beispiel kann hier heruntergeladen werden.