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.

class Singleton
{
   	private static $instance = null;

	public static function getInstance()
	{
		if (self::$instance === null)
		{
			self::$instance = new self;
        	}

    	        return self::$instance;
	}

	private function __construct()
	{}

	private function __clone()
	{}
}

Was passiert wenn dieses Singleton eine Subklasse besitzt und diese instantiiert wird, sehen wir hier:

class SingletonSubclass extends Singleton{}

$singleton = SingletonSubclass::getInstance();
print get_class($singleton);

/* Ausgabe ist "Singleton" */

Wie kann das sein? Wir instantiieren mit der Method getInstance() doch ein Objekt der Klasse SingletonSubclass und nicht der Superklasse Singleton?
Auf den ersten Blick mag das vielleicht so erscheinen, aber durch frühe Bindung machen wir genau das besagte: Wir instantiieren die Superklasse und nicht die Subklasse. Der Knackpunkt liegt hier in dem Schnipsel: self::$instance = new self. Denn dadurch dass das Schlüsselwort self, statisch an die Superklasse gebunden ist, führt das an dieser Stelle zu exakt dem ungewollten Verhalten.

In PHP 5.3 gibt es nun zusätzlich das Schlüsselwort static. Dieser tut im Endeffekt das was wir brauchen, es bindet eine statische Instanz erst spät. Um das ganze mal an einem konkreten Beispiel zu verdeutlichen, gehen wir nachfolgend mal davon aus, dass wir eine Anwendung haben die über ein Singleton verfügt, welches die Verbindung zu einer Datenbank herstellt.

Unsere Klasse mit dem Namen DatabaseConnector muss natürlich eine abstrakte Klasse sein, denn eine konkrete Verbindungsklasse sollte im optimalen Fall auf einen Datenbank-Typ maßgeschneidert sein, z.B. MySQLConnector oder PostgreSQLConnector. Ein Interface wäre zwecks der benötigten Singleton Funktionalität hier unangebracht.

DatabaseConnector.php könnte z.B. so aussehen:

abstract class DatabaseConnector
{
	protected static $instance = null;

        public static function getInstance()
	{
		if (static::$instance === null)
		{
			static::$instance = new static;
      	        }

    	        return static::$instance;
	}

	protected function __construct(){}

	protected function __clone(){}

	abstract public function connect();
}

Darauf folgt die Klasse MySQLConnector:

require_once('DatabaseConnector.php');

class MySQLConnector extends DatabaseConnector
{
	public function connect()
	{
		print "Verbunden mit MySQL Datenbank...";
	}
}

Um das ganze auszuführen, benutzen wir folgenden Code:

require_once('MySQLConnector.php');

$connector = MySQLConnector::getInstance();
$connector->connect();

/* Ausgabe ist "Verbunden mit MySQL Datenbank..." */

Wir sehen, dass wir durch das neue Schlüsselwort static, Möglichkeiten haben sauberer mit Vererbungen und statischem Zugriff umzugehen.

Ein weiter schöner Artikel ist über das Composite Pattern veröffentlicht worden. Dort lohnt sich vorallem das konkrete Beispiel. Beim Composite Pattern fallen mir sonst immer nur Tree-Strukturen ein.

PHP hates me  bringt die Dinge immer schön auf den Punkt, die praktischen Beispiele kommen gelegentlich mal zu kurz.

Link zum Artikel über das Composite-Pattern.
Link zum Artikel über das Facade-Pattern.

Gehen wir mal davon aus, wir möchten mehrere Anwendungen schreiben, welche alle nach dem gleichen Muster initialisiert und gerendert werden sollen. Wir schreiben uns also eine abstrakte Klasse namens ApplicationTemplate. In dessen Konsktruktor legen wir fest, dass beim Instanzieren der Klasse (bzw. der Subklassen, es handelt sich ja um eine abstrakte Klasse), mehrere Methoden aufgerufen werden. Im speziellen sind das die Methoden setup, buildApplication und renderTemplate. Dazwischen rufen wir zusätzlich noch eine optionale Methode namens hook auf, welche wir später für eventuelles eingreifen in die Initialisierung benutzen können.

Die Datei ApplicationTemplate.php würde nun also folgendermaßen aussehen (ohne PHP spezifische Deklaration):

abstract class ApplicationTemplate
{
    final public function __construct()
    {
    	$this->setup();
	$this->hook();
	$this->buildApplication();
	$this->renderTemplate();
    }

    abstract protected function setup();

    abstract protected function buildApplication();

    abstract protected function renderTemplate();

    protected function hook(){}
}

Die Krux bei dieser Implementation liegt in der Verteilung der Schlüsselwörter final, abstract und protected. Unsere ganze Klasse ist abstrakt, das heisst sie schließt mindestens eine abstrakte Methode ein. Dies ist deshalb der Fall, um einer direkte Implementierung unseres Templates vorzubeugen. Die drei abstrakten Methoden können also nicht anders und müssen von eventuellen Subklassen zwangsweise implementiert werden. Die weitere Methode, namens hook stellt hier eine Ausnahme dar. Der Hook ist optional und kann, falls benötigt, von Subklassen überschrieben werden.

Im Konstruktor unserer Klasse wird der eigentliche Ablauf des gewollten Algorithmus festgelegt. Mit dem Schlüsselwort final wird diese abgeschlossen und vor weiterem Überschreiben gesichert. Es ist also völlig egal was wir in unseren Subklassen anstellen, es ist immer sichergestellt dass der Konstruktor aus der Superklasse bestehen bleibt und gleichzeitig alle abstrakten Methoden konkret implementiert werden. Der Konstruktor dient uns in diesem Beispiel also als eigentliche Template Methode.

Unsere ConreteApplication.php könnte z.B. so aussehen:

require_once ('./ApplicationTemplate.php');

class ConcreteApplication extends ApplicationTemplate
{
    protected function setup()
    {
    	print 'Anwendung initialisiert...';
	print '';
    }

    protected function buildApplication()
    {
    	print 'Anwendung ausgefuehrt...';
	print '';
    }

    protected function renderTemplate()
    {
    	print 'Template ausgegeben...';
	print '';
    }

    protected function hook()
    {
	print 'Hook initialisiert...';
	print '';
    }
}

Bei einer Instanzierung der ConcreteApplication Klasse, z.B. in einer Index-Datei würde man folgende Ausgabe erhalten:

// z.B. in einer Index.php
$app = new ConcreteApplication();

// Resultierende Ausgabe wäre:
/*
      Anwendung initialisiert...
      Hook initialisiert...
      Anwendung erfolgreich ausgefuehrt...
      Template erfolgreich ausgegeben...
*/

Wie bereits aufgefallen sein sollte, lebt dieses Pattern von Inheritance. Das sollte aber kein Grund sein auf die hilfreiche Einsatzmöglichkeit zu verzichten.

Der obere Code ist natürlich nur ein kleines rudimentäres Beispiel um zu verstehen worum es überhaupt geht. Sicher gibt es eine Reihe mehr und sinnvollerer Einsatzmöglichkeiten des Musters.

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.