Die Autorisierung innerhalb der RTM-API ist anfänglich etwas verwirrend. Ähnlich wie es bei Flickr gehandhabt wird, ist auch RTM abhängig von einem Token. Eventuell werde ich im nächsten Artikel etwas genauer auf das Login bzw. die Autorisierung eingehen. Weitere Informationen dazu gibt es allerdings auch auf der offiziellen API Dokumentation.

Link zu Milky.
Link zur Remember the Milk API.

Ich schätze die gesamte Lage etwas verhaltener ein. Zum einen erkenne  ich noch nicht wie sich Flash CS5 dazu eignet wirkliche Anwendungen mit mobilem Interface zu dispatchen. Hier fehlt es schlichtweg an passenden (nativen) Komponenten. Zum anderen bin ich mir unsicher ob Performance und Qualität solcher Anwendungen für den erwarteten Erfolg ausreichen. Bisher hörte ich nur, dass aus CS5 veröffentlichte iPhone Apps verhältnismäßig größer sind als die native Konkurrenz.

Persönlich bin ich vielmehr gespannt auf das mobile Flex-Framework mit dem Codenamen “Slider”. Dieses soll das dispatchen einer Anwendung auf die gängigen mobilen Plattformen erlauben. Es bietet neben einer leichtgewichtigen Struktur auch UI-Komponenten die für die mobile Plattform entwickelt werden. Das ganze soll, so wird gemunkelt, im Laufe des Jahres benutzbar sein.

Ich möchte an dieser Stelle auch noch auf einen Artikel von Florian Plag aufmerksam machen. Dieser listet die teilweise bereits erhältlichen Flash und nicht-Flash Alternativen zur iPhone-Entwicklung auf. Ich würde allerdings jedem ans Herz legen sich eventuell ein gutes Objective-C Buch zu schnappen, bevor man sich auf Scriptsprachen wie z.B. Lua fixiert. Was ich bisher gesehen habe, kann Objektive-C in vielen Bereichen eine durchaus elegante Sprache sein.

Link zu Flex-”Slider”.

Eine gute Methode um dieses Verhalten auszuhebeln, ist es, die Javascript Schnittstelle des Browsers anzusprechen und dementsprechend ein neues Fenster zu generieren. In diesem Zusammenhang kann ich auf eine tolle und kompakte Klasse verweisen, die genau das tut:

URLNavigator.as:

package com.zorked {
	import flash.external.ExternalInterface;
	import flash.net.*;

	public class URLNavigator {

		/**
		 * Utility function to wrap up changing pages. Avoids over-aggressive popup blockers.
		 * @param url		The URL to change to. Either a String or a URLRequest
		 * @param window	The target browser window/tab, generally _self, _top, or _blank
		 * @usage URLNavigator.ChangePage("http://www.google.com", "_blank");
		 */
		public static function ChangePage(url:*, window:String = "_self"):void {
			var req:URLRequest = url is String ? new URLRequest(url) : url;
			if (!ExternalInterface.available) {
				navigateToURL(req, window);
			} else {
				var strUserAgent:String = String(ExternalInterface.call("function() {return navigator.userAgent;}")).toLowerCase();
				if (strUserAgent.indexOf("firefox") != -1 || (strUserAgent.indexOf("msie") != -1 && uint(strUserAgent.substr(strUserAgent.indexOf("msie") + 5, 3)) >= 7)) {
					ExternalInterface.call("window.open", req.url, window);
				} else {
					navigateToURL(req, window);
				}
			}
		}

	}
}

Was wird hier gemacht? Nun im Prinzip macht die Klasse einen Check ob es sich um gewisse Browser-Versionen handelt und führt dementsprechend einen normalen navigateToURL-Request aus, oder er ruft die Javascript Methode window.open() auf. Man ist im Grunde auf der sicheren Seite und gegen die Popup-Blocker Schikane einiger Browser gut gerüstet.

Link zum Artikel

In der überarbeiteten Version unserer Anwendung geht es nun darum, dass es die Möglichkeit gibt den Kreis nicht nur in x- und y-Richtung zu bewegen, sondern auch dessen Alpha-Wert anzupassen.

(Rechtsklick-View Source um Quellcode einzusehen)

In diesem Beispiel brauchen wir also neben dem MoveCommand noch einen zweiten Befehlstypen, welcher in der Lage ist den Alpha-Wert eines entsprechenden Sprites zu verändern und wieder rückgängig zu machen. Er muss also das ICommand-Interface implementieren.

AlphaCommand.as:

package com.boxedfolder.examples.undo
{
	import flash.display.Sprite;

	public class AlphaCommand implements ICommand
	{
		private var _sprite:Sprite;

		private var _alpha:Number;

		private var _targetAlpha:Number;

		public function AlphaCommand(sprite:Sprite, targetAlpha:Number)
		{
			_targetAlpha = targetAlpha;
			_alpha = sprite.alpha;
			_sprite = sprite;
		}

		public function execute():void
		{
			_sprite.alpha = _targetAlpha;
		}

		public function undo():void
		{
			_sprite.alpha = _alpha;
		}
	}
}

Um eine Struktur zu erhalten, die es uns ermöglicht viele kleinere Commands sequentiell abzuarbeiten, bedienen wir uns des Composite-Patterns. Wir erstellen uns dazu einen MacroCommand, welcher potentiell beliebig viele Unterbefehle einschließen kann.

MacroCommand.as:

package com.boxedfolder.examples.undo
{
	public class MacroCommand implements ICommand
	{
		private var commandStack:Array = [];

		public function execute():void
		{
			var command:ICommand;

			for(var i:int = 0; i < commandStack.length; ++i)
			{
				command = commandStack[i] as ICommand;
				command.execute();
			}
		}

		public function undo():void
		{
			var command:ICommand;

			while(commandStack.length > 0)
			{
				command = commandStack.pop() as ICommand;
				command.undo();
			}
		}

		public function addSubCommand(command:ICommand):void
		{
			commandStack.push(command);
		}
	}
}

Da die Klasse MacroCommand das Interface ICommand implementiert ist eine Instanz in der Lage wie ein regulärer Befehl aufgerufen zu werden. Anstatt allerdings selber Funktionalität zu implementieren, wird durch die Unterbefehle iteriert und deren execute()- bzw. undo()-Methode ausgeführt. Zusätzliche Subcommands lassen sich via der Methode addSubCommand() hinzufügen.

Um jetzt diese Befehlskette in unsere Anwendung zu integrieren, müssen wir den MacroCommand instantiieren, Subcommands hinzufügen und dessen execute()-Methode aufrufen.

UndoExample.as:

package
{
	import com.boxedfolder.examples.undo.AlphaCommand;
	import com.boxedfolder.examples.undo.ICommand;
	import com.boxedfolder.examples.undo.MacroCommand;
	import com.boxedfolder.examples.undo.MoveCommand;

	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import flash.text.TextField;
	import flash.text.TextFieldType;

	[SWF(height="550", width="550", backgroundColor="#ffffff", frameRate="50")]

	public class UndoExample extends Sprite
	{
		//... verkürzt

		private var commandStack:Array = [];

		public function UndoExample()
		{
			setupVisuals();
		}

		private function setupVisuals():void
		{
		     //....verkürzt
		}

		private function buttonHandler(e:MouseEvent):void
		{
			if(e.target == goButton)
				changeObject();

			if(e.target == undoButton)
				undo();
		}

		private function changeObject():void
		{

			var command:MacroCommand;
			var yv:Number = Number(yTextField.text);
			var xv:Number = Number(xTextField.text);
			var av:Number = Number(aTextField.text);

			if(!isNaN(yv) && !isNaN(xv) && !isNaN(av))
			{
				command = new MacroCommand();
				command.addSubCommand(new MoveCommand(circle, xv, yv));
				command.addSubCommand(new AlphaCommand(circle, av));

				commandStack.push(command);
				command.execute();
			}
		}

		private function undo():void
		{
			var command:ICommand;

			if(commandStack.length > 0)
			{
				command = commandStack.pop() as ICommand;
				command.undo();
			}
		}
	}
}

Der Vorteil dieser Struktur liegt in der Flexibilität. Wir verwenden einfach mehreren MacroCommands um so Funktionalität zu bündeln und den kompletten Befehlsverbund leicht Rückgängig zu machen.

Ich kann jedem empfehlen, dort mal einen Blick reinzuwerfen. Alternativ ist natürlich immer ein MVC-Framework eine gute Wahl. Für Flash/Flex gibt es eine recht große Auswahl. Ich benutze aktuell PureMVC für diverse Projekte, weitere sind z.B. Mate, Swiz, Cairngorm oder Parsley. Die einzelnen Frameworks unterscheiden sich häufig in Art und Anzahl der benutzten Patterns.

Zum Thema Flex-Frameworks hat auch David Tucker kürzlich einen interessanten Blogeintrag geschrieben. Dieser behandelt einige Probleme diverser Frameworks und zeigt Alternativen auf.

Link zum Artikel von David Tucker.
Link zum  Artikel Truckin´ Through ActionScript 3.0 MVC: Part 2
Link zum  Artikel Truckin´ Through ActionScript 3.0 MVC: Part 2
Link zum  Artikel Truckin´ Through ActionScript 3.0 MVC: Part 3
Link zum  Artikel Truckin´ Through ActionScript 3.0 MVC: Part 4

UPDATE:
Link zum  Artikel Truckin´ Through ActionScript 3.0 MVC: Part 5

Nachfolgend habe ich rudimentär zwei Buttons und zwei Eingabefelder zusammen mit einem Kreis auf einer Bühne platziert. Man kann mit Hilfe der Eingabefelder offensichtlich die x- und y-Positionen des Kreises verändern. Der Clou daran ist, dass man auch einen Undo-Befehl ausführen kann, welcher jeweils die letzte Aktion rückgängig macht.

Als erstes bin ich hergegangen und habe ein Command-Interface mit dem Namen ICommand definiert. Dieses Interface beschreibt die beiden Methoden die ich benötige. Zum einen natürlich die execute()-Methode, welche die eigentliche Funktionalität beinhaltet und zum anderen die undo()-Methode:

package com.boxedfolder.examples.undo
{
	public interface ICommand
	{
		function execute():void;
		function undo():void;
	}
}

Die Klasse MoveCommand, welche konkret für die Bewegung meines Objekts zuständig ist sieht nun folgendermaßen aus:

package com.boxedfolder.examples.undo
{
	import flash.display.Sprite;

	public class MoveCommand implements ICommand
	{
		private var _addedY:int;

		private var _addedX:int;

		private var _sprite:Sprite

		public function MoveCommand(sprite:Sprite, addedX:int, addedY:int)
		{
			_addedX = addedX;
			_addedY = addedY;
			_sprite = sprite;
		}

		public function execute():void
		{
			_sprite.x += _addedX;
			_sprite.y += _addedY;
		}
		public function undo():void
		{
			_sprite.x -= _addedX;
			_sprite.y -= _addedY;
		}
	}
}

Mit unserer konkreten MoveCommand-Klasse, haben wir nun das Werkzeug, mit Hilfe der Methode execute() eine Bewegung in x- und y-Richtung an einem Sprite durchzuführen. Des weiteren speichert eine Move-Command Instanz, die hinzugefügten Werte und merkt sich also indirekt die alte Position des Sprites. Die Methode undo() nimmt die gespeicherten Werte und zieht sie vom referenzierten Sprite wieder ab. Sie macht also den gesamten Vorgang rückgängig.

Die Dokumenten-Klasse UndoExample sieht wie folgt aus:

package
{
	import com.boxedfolder.examples.undo.ICommand;
	import com.boxedfolder.examples.undo.MoveCommand;

	import flash.display.Sprite;
	import flash.events.MouseEvent;
	import flash.text.TextField;
	import flash.text.TextFieldType;

	[SWF(height="550", width="550", backgroundColor="#ffffff", frameRate="50")]

	public class UndoExample extends Sprite
	{
		//... verkürzt

		private var commandStack:Array = [];

		public function UndoExample()
		{
			setupVisuals();
		}

		private function setupVisuals():void
		{
		     //....verkürzt
		}

		private function buttonHandler(e:MouseEvent):void
		{
			if(e.target == goButton)
				changeObject();

			if(e.target == undoButton)
				undo();
		}

		private function changeObject():void
		{
			var command:ICommand;
			var yv:Number = Number(yTextField.text);
			var xv:Number = Number(xTextField.text);

			if(!isNaN(yv) && !isNaN(xv))
			{
				command = new MoveCommand(circle, xv, yv);
				commandStack.push(command);
				command.execute();
			}
		}

		private function undo():void
		{
			var command:ICommand;

			if(commandStack.length > 0)
			{
				command = commandStack.pop() as ICommand;
				command.undo();
			}
		}
	}
}

Wir legen jeden Command, welchen wir instantiieren und ausführen, am Ende eines Arrays ab. Dies bietet uns sozusagen ein Command-Stapel. Wenn der Benutzer den Undo-Button betätigt, wird die Methode undo() des Commands aufgerufen, welcher sich am ende des Arrays befindet. Gleichzeitig wird besagter Command aus dem Array entfernt.

In diesem simplen Beispiel sieht man wie man mit einfachen Mitteln eine Struktur aufbaut, in der ein Benutzer beliebig viele Schritte einzeln zurückgehen kann. In einem weiteren Artikel möchte ich das Beispiel noch etwas komplexer machen und die Struktur unter Anderem mit Hilfe des Composite Patterns verfeinern. Der komplette Source Code des oberen Beispiels lässt sich mit Rechtsklick und der Option “View Source” einsehen.

Im Detail zeigt der Artikel mehrere kommerzielle und nicht kommerzielle Lösungen zum darstellen von Multimedia Content auf der Flash Plattform, listet Vor- und Nachteile auf und gibt Auskunft über den eventuellen Preis. Ich muss allerdings gestehen dass ich keins davon bisher getestet habe. Wenn Interesse da ist, einfach mal selber testen und schauen ob es den Anforderungen entspricht.

Link zum Artikel.

In meinem letzten Projekt hab ich mich für das von Adobe initiierte Framework - Cairngorm – entschieden. Im Laufe der Entwicklung hab ich mich natürlich mit den Ups und Downs rumärgern müssen die Cairngorm so mit sich bringt. Um sich einige Probleme in Sachen Flexibilität des Frameworks näher zu bringen, muss man sich die Struktur einmal kurz verdeutlichen.

Es läuft in der Regel folgendermaßen ab: Der View dispatched Events, die vom Controller aufgefangen werden und dementsprechende Commands instanziert. Diese Commands sind entkoppelt vom View und verändern nur die Daten in unserem Model. Das Model wiederum updated via Data Binding unsere View-Komponenten. Soweit so gut.

Wenn es darum geht komplexere Probleme zu lösen, die rein vom Gefühl nicht durch einfaches Data Binding gelöst werden können, steht man in Cairngorm vor einigen Entscheidungen zu denen man auch im Netz etliche Diskussionen findet.

Um mal ein Beispiel des Problems zu nennen:
In meiner Applikation will ein User ein Popup aufrufen, welches mit Daten von einem Server gefüttert wurde. Er klickt dafür z.B. auf einen Button, dieser schickt ein Event los, daraufhin wird ein passender Command ausgeführt. Die Frage ist nun, wo implementiere ich die konkrete Methode um das Popup im View zu instanziieren? Ich müsste nach klassischer Cairngorm Best-Practise mein Model aktualisieren, welches wiederum per Data Binding das Popup startet. Gut, dies kann ich einfach mit einem Flag im Model lösen, auf den das View bei Änderung entsprechend reagiert. Im Endeffekt wird aber nicht nur mein Model bei großen Anwendungen durch etliche Flags unnötig aufgeblasen, sondern die Anwendung legt durch viele Listener, Methoden und Referenzen drastisch an Komplexität zu.

In “alten” (2006) Dokumentationen werden für diese Probleme oftmals die sogenannten ViewHelper- und ViewLocator-Klassen referenziert, die für solche Aufgaben zur Verfügung gestellt wurden. Losgelöst vom Command & Model hält ein ViewHelper die View-Komponenten auf dem laufenden.

Aktuelle Cairngorm Dokumentationen schlagen eine Einbindung des sogenannten Presentation Models vor, was dieses speziell im Cairngorm Fall bedeutet kann man unter Anderem hier nachlesen. Für mein bereits fortgeschrittenes Projekt dürfte die Umstellung auf ein Presentation Model aber Aufwand und viel Refactoring darstellen. Etwas was ich aktuell nicht leisten will. Auch bin ich mir unsicher ob die einfacher Umschichtung der Zuständigkeiten alle meine Probleme löst.

Was bedeutet das also für mein konkretes Popup Problem? Auf ViewHelper setzen, was vom Cairngorm Team nicht mehr empfohlen wird? Die klassische Model/Flag/Listener Alternative, was mein Model noch mehr aufbläht? Oder die Methode die wohl am ungünstigen ist: Einfach alles im Command direkt implementieren?

Aufgrund mangelnder klarer Dokumentationen und der daraus resultierenden uneindeutigen und wechselhaften Best-Practise-Methodik, werde ich mir in Zukunft vielleicht noch einmal die Konkurrenz in Form von z.B. PureMVC und Mate anschauen müssen.

Bitte nutzt die Kommentarfunktion und schreib mir eure Erfahrungen.

Link zu Cairngorm.
Link zu Mate.
Link zu PureMVC.

Link zu Flash Builder.
Link zu Flash Catalyst.

Die Grafik zeigt uns die neue Ausrichtung die sich Adobe bei seinen neuen alten Programmpaketen überlegt hat.

• Flash Catalyst: Zum erstellen grafischer Assets für den Flash Builder aber auch zur Veröffentlichung eigener swf-Dateien.
• Flash CS4: Zur Erstellung und Animation von swf-Dateien. Im Zusammenspiel mit Actionscript 3.
• Flash Builder: Erstellung von Actionscript 3 und Flex Projekten.

Ziel bei allen drei Systemen ist es die Flash Plattform mit Inhalt zu füllen. Der Fokus ist bei den Programmen jetzt klar in Richtung Design – Entwicklung zu erkennen.
Eigentlich ist das nichts neues (abgesehen von Catalyst), aus Marketing Gründen allerdings scheint diese eindeutige Namensgebung für Adobe sinnvoll zu sein.

Quelle: Everything Flex