REPPA.NET | dev blog

iOS: Skinning der UISegmentedControl-Komponente

Posted on November 27, 2011 by Daniel Schmidt

Dieser Blogeintrag befasst sich mit dem Skinning der UISegmentedControl-Komponente, was sich mit iOS 5 nun einfacher gestaltet. So sieht die Komponente in ihren normalen Zustand aus:

default look
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.

skinned UISegmentedControl
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.

skinned UISegmentedControl
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:

skinned UISegmentedControl

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

Posted in Objective-C, iPhone | Tagged backgroundImage, dividerImage, iOS 5, titleTextAttributes, UISegmentedControl | Leave a comment

ItemRenderer: ab-/anmelden von EventListenern

Posted on October 31, 2011 by Daniel Schmidt

Viele Beispiele im Netz zeigen, wie schnell und einfach sich ItemRenderer für Flex-Komponenten erstellen lassen. Leider sind diese Beispiele für größere Anwendungen kaum zu gebrauchen, da entweder die Performance durch die vielen Bindings verloren geht, oder verwendete EventListener nicht mehr abgemeldet werden.

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.

Posted in Actionscript, Flex | Tagged EventListener, GarbageCollection, ItemRenderer, performance | Leave a comment

PureMVC: EventMapMediator – automatisiertes Entfernen aller Eventlistener

Posted on September 25, 2011 by Daniel Schmidt

Jeder Mediator im PureMVC Framework, der sich bei seiner Viewkomponente für Events anmeldet muss diese spätestens beim entfernen des Mediators auch wieder abmelden.
In der Regel sieht der Code im Mediator, für das An- und Abmelden, folgendermaßen aus:

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.

Posted in Actionscript, Flex, MVC | Tagged Event, Mediator, PureMVC | Leave a comment

Flex: Tree-Komponente mit unterschiedlichen ItemRenderern

Posted on August 29, 2011 by Daniel Schmidt

Da die Tree-Komponente nur eine Instanz eines ItemRenderers intern zur Darstellung der Daten verwendet, muss dieser Renderer das Aussehen aller Baumelemente beinhalten. Dies kann dazu führen, dass der ItemRenderer sehr viel Code enthält, wenn für Verzweigungen und Blätter des Trees verschiedene Funktionalitäten und Aussehen gewünscht sind. Um dies zu vermeiden, habe ich die Tree-Komponente so erweitert, dass für jedes Baumelement ein anderer ItemRenderer verwendet werden kann.

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):

Tree-Komponente

Das Beispiel aus den Screenshoots kann hier heruntergeladen werden.

Posted in Actionscript, Flex | Tagged ItemRenderer, Tree | Leave a comment

iOS-Entwicklung: BAD_ACCESS-Fehler mit NSZombieEnabled Debuggen

Posted on July 31, 2011 by Daniel Schmidt

Jeder der schon einmal einen BAD_ACCESS-Fehler in einer Anwendung beheben musste, weiß wie umständlich dies sein kann. Da diese Art von Fehler an irgendeiner Stelle im Programm auftritt, und keinen Rückschluss auf den Code gibt der diesen Fehler verursacht hat.
Glücklicherweise gibt es aber die Umgebungsvariable NSZombieEnabled, die dafür sorgt das Objekte deren releaseCount gleich 0 ist nicht gelöscht werden. Wird im Laufe des Programms eine Nachricht an ein solches Objekt gesendet, bleibt der Debugger sofort stehen. Dadurch kann genau analysiert werden, an welcher Stelle im Code der fehlerhafte Zugriff erfolgte.

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!

Posted in Objective-C, iPhone | Tagged BAD_ACCESS, NSZombieEnabled, releaseCount, Xcode | Leave a comment

Flaschenhals: Binding

Posted on June 29, 2011 by Daniel Schmidt

Ein sehr mächtiges Feature in Flex ist das [Bindable]-Metadata-Tag. Man sollte sich aber dennoch bewusst sein, dass auch das Binding einige Nachteile mit sich bringen kann. Wenn eine Klasse oder Properties einer Klasse mithilfe des [Bindable]-Tags für den Compiler markiert werden, generiert dieser aus der Property einen Getter und Setter. Im Setter wird dann ein PropertyChangeEvent versendet. Damit ein anderes Objekt über die Änderung informiert werden kann, wird diese vom Compiler als Empfänger für das PropertyChangeEvent angemeldet.

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.

Posted in Flex | Tagged bindable, binding, performance | Leave a comment

Vector als “dataProvider” für Flex-View-Komponenten

Posted on May 27, 2011 by Daniel Schmidt

Seit der Einführung des FlashPlayers 10, steht dem Entwickler die Klasse Vector zur Verfügung. Diese bringt gegenüber dem Array einige Vorteile mit sich, doch spätestens bei der Zuweisung eines Vectors als “dataProvider” für View-Komponenten steht der Entwickler vor einem Problem. Für die Array-Klasse existieren die Klassen ArrayList und ArrayCollection, die das Interface implementieren welches ein “dataProvider” benötigt. Wohingegen für die Klasse Vector keine Alternativen geboten werden.
Da ich mir selber mehr als einmal diese Möglichkeit gewünscht hätte, habe ich analog zum Array die Klassen VectorList und VectorCollection erstellt. Mit Hilfe dieser Wrapperklassen kann nun auch ein Vector als “dataProvider” verwendet werden.

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

Posted in AIR, Actionscript, Flex | Tagged dataProvider, Vector, VectorCollection, VectorList | Leave a comment

Übergabe und Verarbeitung von eigenen Flex-Compiler-Argumenten (Compile-Time)

Posted on May 10, 2011 by Andy

Dieser Eintrag ergänzt die Übergabe und Verarbeitung von eigenen Flex-Compiler-Argumenten um ein ANT-Buildscript für Flex4, bei dem die Compile-Time als Compilerargument übergeben wird.

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.

Posted in Flex | Tagged ANT, Buildscript, Compiletime | Leave a comment

ItemRenderer, BindingUtils und Garbage Collection

Posted on April 28, 2011 by Daniel Schmidt

Mit Hilfe der BindingUtils-Klasse kann man sich bei Objekten registrieren um über Änderungen einer bestimmten Property informiert zu werden. Dieser Mechanismus wird häufig in ItemRenderern verwendet. Leider enthält die API-Referenz zur BindingUtils-Klasse keinerlei Hinweise wie ein solches Binding wieder aufgelöst werden kann. Ein nicht gelöschtes Binding wird im Speicher gehalten und ausgeführt auch wenn der ItemRenderer nicht mehr über Änderungen informiert werden will.

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.

Posted in Actionscript, Flex | Tagged binding, BindingUtils, ChangeWatcher | Leave a comment

Klickbarer Flex-DataGrid Header

Posted on November 25, 2010 by Daniel Schmidt

Flex Datagrid-Header bieten von Haus aus keine Möglichkeit auf Click-Events der Maus zu reagieren.

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" />