Automatische Inkrementierung der Bundle Version in Xcode 4

Apple fordert in seinen Guidelines für die Entwicklung von Apps für IPhone, iPad wie auch Mac OSX eine stete Inkrementierung der Versionsnummer wenn eine App im AppStore aktualisiert werden soll. Aber auch für die Entwicklung kann eine fortlaufende Nummer hilfreich sein. Gerade wenn man die App an Beta Tester via adHoc Distribution herausgibt. So lässt sich immer nachvollziehen, welche Entwicklungsversion beim Tester installiert ist und der Fehler kann besser gefunden werden.

Jedoch ist es lästig immer erst die Versionsnummer zu verändern wenn ein neuer Build geschrieben wird. Daher im folgenden nun eine Automatisierung des Ganzen mit Hilfe von Xcode. Wichtig ist es übrigens nicht nur die „Bundle version“ in der project-info.plist anzugeben, sondern auch den Wert für „Bundle versions string, short“.

Für die Automatisierung wird eine xcconfig-Datei benötigt. Dazu einen Rechtsklick auf das Projekt ausführen und „New File…“ auswählen. Im nun angezeigten Popup unter „Other“ den Typ „Configurations Settings File“ auswählen. Nach dem Klick auf Next wird nach dem Dateinamen gefragt. Für diese Beispiel hier verwende ich „version“. Nachdem die Datei erzeugt ist, darauf achten dass sie auf der obersten Ebene im Projekt, als im Projectroot, liegt.

Anschließend folgt die Anpassung der Datei. Wenn man sie öffnet ist die noch leer, bis auf den vorkonfigurierten Kommentarheader. Hier fügt man nun folgende Zeile ein und speichert das ganze:
CURRENT_PROJECT_VERSION = 1

Weiter geht es mit den Einstellungen im Projekt. Dazu links das Projekt auswählen und der nun angezeigten View ebenfalls links unter „Projects“ das entsprechende Projekt auswählen. Im Tab „Info“ gibt es nun die „Configurations“ für das Projekt. Standardmäßig sind das „debug“ und „release“. Nun eine Konfiguration auswählen, aufklappen und für den Wert „Based on Configuration File“ die eben erstellte Datei auswählen für Project und Target. Standardmäßig steht hier „None“. Diesen Schritt für alle Konfigurationen wiederholen, für die man die automatische Inkrementierung haben möchte.

Nun müssen noch die Einstellungen für die Targets angepasst werden. Dazu eben das Projekttarget in der linken Spalte der Hauptview auswählen, welches direkt unter den Projects steht. Nun wird in der angezeigten View unter „Info“ die project-info.plist angezeigt in der sich auch die Einträge „Bundle version“ und „Bundle versions string, shot“ finden sollten. Diese Werte jeweils auswählen und mit folgenden String ersetzen:
1.0.${CURRENT_PROJECT_VERSION}
In diesem Beispiel bedeutet dies, dass die Hauptversion bei 1 liegt und die Unterversion bei 0. Aber der letzte Wert wird nun aus der Datei gezogen und stellt somit die build-Version dar.

Als letzter Schritt muss nun Xcode gesagt werden, dass es diesen Wert hochzählen soll wenn ein neuer build ansteht. Dazu bleibt man in der Target-Ansicht und wählt hier den Tab „Build Phases“ aus (2. Tab rechts neben Info). In der angezeigten View gibt es unten rechts den Button „Add Build Phase“. Diesen anklicken und im angezeigten DropDown „Add Run Script“ auswählen. Nun sollte oben der Bereich „Run Script“ erscheinen, insofern er noch nicht vorhanden war. Diesen aufklappen, wenn dem noch nicht so ist und nun folgende Anpassungen ausführen. Der Wert bei Shell sollte „/bin/sh“ sein und im folgenden Textfeld folgendes Script einfügen:
NEW_VERSION=`cat "$SRCROOT/version.xcconfig" | awk '/CURRENT_PROJECT_VERSION/ { print $3 + 1 }'`
sed -i '' "s/CURRENT_PROJECT_VERSION = .*/CURRENT_PROJECT_VERSION = $NEW_VERSION/" "$SRCROOT/version.xcconfig"
CURRENT_PROJECT_VERSION=$NEW_VERSION
touch "$SRCROOT/version.xcconfig"

Dieses Script zieht sich die aktuelle Versionsnummer aus der Datei und aktualisiert diese.

Das waren alle Anpassungen die nötig sind. Zum Testen des Ganzen, nun einfach einen Build des Projektes herausschreiben. Schaut man nun in die version.xcconfig Datei, ist der darin stehende Wert um 1 erhöht. Auch die Versionsnummer der App ist inkrementiert worden. Dazu links im Project-Browser unter Products > Im Finder anzeigen auswählen. Die angezeigte Datei hat nun ebenfalls die aktualisierte Versionsnummer.

Erkennen von transparenten und opaken Pixeln in ActionScript

Oft bekommt man als Entwickler ein .png, das als Button dienen soll. Hier ist wie immer der einfache Weg, Bild einbinden und den Container klickbar machen. Das ist ja soweit kein Hexenwerk. Jedoch kann das zu unschönen Effekten führen, da natürlich auch die transparenten Teile des Bildes Klickbar sind und somit Bereiche interaktiv, die rein optisch gesehen, nicht mehr zum im Bild enthaltenen Objekt gehören.

Klar kann man jedes mal eine Überprüfung des unter dem Mauszeiger liegenden Pixels machen und prüfen ob dieser nun transparent ist oder eben nicht. Aber es wäre doch schön, einfach eine Fläche zu haben, die man als ClickArea über das Bild legen kan, um darauf die MouseListener zu legen, ohne jedes Mal irgendwas abzuprüfen, was eventuell zu unschönen Seiteneffekten führt.

Die simple Variante hierfür ist eine BoundingBox zu generieren, welches das Rectangle repäsentiert, in dem die opaken Flächen liegen. Für hauptsächlich rechteckige Formen sollte das ausreichend sein. Aber was ist wenn, die Form komplexer ist oder einfach nicht Rechteckig? Das führt dann zu folgendem Ergebnis:

This movie requires Flash Player 9

Das ist bei dieser Form kein wirklich akzeptables Ergebnis. Man hätte sich hier auch einfach die Mühe sparen können. Also benötigt es einen anderen Ansatz, die eine Annäherung an die Form ermöglicht und so eine bessere BoundingBox zurückliefert.

Das Ansatz dazu klingt recht einfach. Man unterteilt das Bild in vier gleiche Rechtecke und schau nach, wie es mit den Transparenzen innerhalb der Fläche aussieht. Da gibt es drei Möglichkeiten: nur transparente, nur opake oder beides gemischte Pixel. Wenn es nur transparente Pixel sind, muss dieser Teil der Bildes nicht weiter untersucht werden. Genau das selbe gilt für die opaken Pixel. Jedoch sollte man sich hier den Bereich merken, da er ja zur BoundingBox des Bildes gehört, die ja Ziel der ganzen Aktion ist.

Bei den Rechtecken mit transparenten und opaken Pixeln muss man einfach wieder unterteilen und untersuchen. Dies sollte man aber nicht zu oft durchführen, da sich der Summe der Untersuchungen natürlich jedes mal vervierfacht. Im folgenden Beispiel habe ich 8 Iterationen verwendet, was zu einem recht guten Ergebnis führt:

This movie requires Flash Player 9

Die Überprüfung auf transparente und nicht transparente Pixel ist eigentlch recht einfach. Man nutzt das Rechteck aus der Unterteilung und führt die BitmapData.getPixels-Methode aus. Diese liefert einen ByteArray aller Farbwerte im Rechteck zurück und zwar 32-Bit. Über readUnsignedInt() bekommt man aus diesen wiederum die Farbwerte und kann diese über „>>> 24“ (Unsigned right shift) um eben 24 Bit nach rechts verschieben, womit der Alphakanal übrig bleibt. Hier bildet man die Quersumme der Alphawerte. Sollten diese 0x00 sein ist der Bildteil transparent, ist er 0xFF ist er eben opak. Hier lassen sich dann auch Toleranzen einfügen. Für die doch recht üppige Menge an Überprüfungen, ist es im übrigen besser eine Linked List zu nutzen, anstatt eines Arrays oder ArrayCollection.

Das ganze führt dann zu folgendem Ergebnis (grün sind die voll opaken Bereiche, die blauen die Randbereiche, die bei der letzten Iteration übrig bleiben):

This movie requires Flash Player 9

Schnelle Fourier-Transformation (1D + 2D) für ActionScript

Wie schon in einem älteren Beitrag (SoundMixer.computeSpectrum() vs. Sound.extract()) von mir beschrieben, gibt es (noch immer) ein Problem mit der computeSpectrum Methode des SoundMixers. Diese Methode zum Auslesen des Spektrums ist an sich eine schöne Funktion, gehört aber dem SoundMixer. Dieser ist eine globale Flash-Klasse, was einige Probleme mit sich bringt. Nutzt man diese Funktion innerhalb eines SWFs und hat andere SWF, welche Sound beinhaltet offen, kommt es unweigerlich zu Sicherheitsfehlern und wirklich unschönen Geräuschen.

Umgehen lässt sich dies mit Hilfe der der extract() Methode der Sound-Klasse. Hier wird das gesamte Frequenzspektum des Sounds augelesen und kann weiter verwendet werden. Aber es gibt einen gravierenden Unterschied bei beiden Mehtoden. Die computeSpectrum liefert von Haus aus eine schnelle Fourier Transformation mit. Hingegen liefert die extract()-Methode nur RAW-Daten zurück. Kurz zusammengefasst bedeutet dies, dass mit Hilfe der computeSpectrum die zurückgelieferten Frequenzen nach Bereich sortiert werden und bei der anderen Funktion eben nicht.

Klar könnte man hingehen und selbst eine einfache Sortierfunktion schreiben. Doch bei der etwas größeren Datenmenge die bewältigt werden muss, wird dies das Script auf jeden Fall verlangsamen. Eine Methode die verwendet werden kann zur Sortierung ist die Schnelle Fourier-Transformation, die auf der Diskreten Fourier-Transformation basiert. Aber leider gab es diese Funktion, wie gesagt, nur innerhalb der computeSepctrum() Methode.

Nun hat Eugene Zatepyakin sich die Mühe gemacht und eine Implementierung der schnellen Fourier-Transformation in ActionScript 3 geschrieben, die frei verfügbar bei Google-Code ist. Mit Hilfe dieser Klassen konnte ich, nach ein paar Tests, den SoundVisualizer mit der Funktionalität zur Sortierung der Sound Daten erweitern, ohne die oben kurz angerissenen Probleme wieder aufzureißen.

Die Implementierung ist, wie Eugene sie auch beschreibt, sehr einfach. Für die Verwendung mit Sound wird die FFT-Klasse verwendet. Des weiteren gibt es noch die FFT2D-Klasse, welche die Möglichkeit eine zweidimensionale Transforation durchzuführen bietet, wie sie etwa bei Bildern Verwendung findet. Bei der Initialisierung der Klasse mit deren init()-Methode sollte man auch nicht über 2048 Bytes gehen, da sonst wiederum die Performance leidet. Besonders ist darauf zu achten, dass die Anzahl der ausgelesenen Bytes über die extract-Methode mit der bei der init Methode übereinstimmt.

Der eingentliche Analyzer ist in der FFTSpectrumAnalyzer-Klasse. Hier wird in der initLogarithmicAverages-Methode zunächst die Mindestbandbreite angegeben und die Anzahl an Bändern, in die eine Oktave unterteilt werden soll.
Sehr wichtig ist auch die Einstellung „Little Endian“ für den ByteArray, welcher die resultierenden Daten hält. Innerhalb des onSampleDataEvent-Handlers werden die ausgelesenen Bytes dann der fft-Klass mittels setStereoRAWDataByteArray(bytes) mitgegeben, um dann anschließend die forwardFFT() aufzurufen, welche die eigentliche Transformation ausführt. fftHelp.analyzeSpectrum() liefert dann den analysierten ByteArray, welcher dann weiter benutzt werden kann für alle möglichen visuellen Ausgaben, zurück. Noch ist hier der Sound selbst noch nicht ausgegeben. Dafür müssen die Bytes zurück transformiert werden über fft.inverseFFT(). Nach dem Zurücksetzen der Position innerhalb des BytesArrays können nun die SoundBytes an event.data zur Ausgabe übergeben werden. Den genauen Ablauf der Funktionen kann man auch auf Google Code nachlesen. Hier hat Eugene zwei Beispielscripts eingefügt. Und als anschauliches Beispiel für die Verwendung seiner Bibliothek einfach den zeroseven SoundVisualizer anschauen. Hier ist im letzten Reiter eine weitere Checkbox, in der man angeben kann, ob die Daten sortiert (FFT) oder unsortiert (RAW) verwendet werden sollen.

Links:

Starten von Systemprozessen in AIR 2.0

Eine der Neuerungen von AIR 2.0 ist die NativeProcess API, die es ermöglicht mit Systemprozessen zu interagieren und somit Systemanwendungen zu starten und zu beenden. Diese API bietet eine Menge von neuen Möglichkeiten für AIR-Applikationen. In diesem Blogeintrag werde ich zeigen wie aus AIR Firefox gestartet werden kann.

Native Installers
AIR Applikationen können nicht nur als *.air Dateien exportiert und weitergegeben werden, sondern auch als „Native Installer“ also *.exe für Windows bzw. *.dmg für MacOS. Dies ist die Voraussetzung um mit Systemprozessen kommunizieren zu können. Ein weiterer Vorteil von Native Installers ist, dass die AIR Runtime mit der Applikation installiert wird, falls diese noch nicht auf dem System des Benutzers verfügbar ist und eine Internetverbindung besteht. Falls der Benutzer nicht mir dem Internet verbunden ist, kommt wenigstens eine Meldung man solle sich doch bitte die aktuelle AIR runtime von der Adobe Seite herunterladen. Weiterhin gibt es die Möglichkeit die AIR Runtime zum Beispiel auf einer CD/DVD mitzuliefern, dafür ist allerdings eine Re-Destributable Lizenz von Adobe nötig, siehe Blogeintrag von Mike Chambers.

Erstellen eines Native Installers
Da man aus FlashBuilder standardmäßig nur *.air Files exportieren kann müssen hier auf die Konsole zurückgreifen. Das Packagingprogramm hierfür heißt ADT und befindet sich im bin Ordner des AIR sdks. Es gibt grundsätzlich zwei verschiedene Arten Native Installers zu erstellen:

  • aus dem Sourcecode eines AIR Projekts
  • aus einer bereits bestehenden AIR Datei

Dieser Aufruf erstellt eine Anwendung mit Native Installer für MacOS aus den Quelldaten der Applikation.

adt -package -storetype pkcs12 -keystore myCert.pfx -target native myApp.dmg main-app.xml main.swf

Folgender Aufruf erstellt eine Anwendung mit Native Installer für MacOS aus einer AIR Datei

adt -package -target native myApp.dmg myApp.air

Um einen Native Installer für Windows zu erstellen wird einfach anstatt myApp.dmg myApp.exe verwendet. Einschränkung: Native Installers können immer nur für das Betriebssystem erstellt werden das gerade genutzt wird. Will mal also ein *.exe für Windows erstellen muss ADT unter Windows aufgerufen werden.

Mehr Infos dazu auf der Adobe Hilfe.

NativeProcess API
Die NativeProcess Klasse bietet die Möglichkeit mit einem Systemprozess zu interagieren. Über die Funktionen start(info:NativeProcessStartupInfo):void und exit(force:Boolean = false):void werden Prozesse gestartet und beendet. Über die Eigenschaften running, standardError, standardInput und standardOutput kann der Prozess überwacht werden.

Der Funktion start() wird eine NativeProcessStartupInfo Objekt übergeben das Informationen zum Prozess enthält der gestartet werden soll. Die Eigenschaft executable muss eine Referenz auf die Datei enthalten die gestartet werden soll und über arguments kann eine Vector von Strings
mit Parametern angegeben werden.

var file = new File('/Applications/Firefox.app/Contents/MacOS/firefox-bin');
var nativeProcessStartupInfo:NativeProcessStartupInfo = new NativeProcessStartupInfo();
nativeProcessStartupInfo.executable = file;
var process:NativeProcess = new NativeProcess();
process.start(nativeProcessStartupInfo);

Dies ist nur ein kleines Beispiel das natürlich beliebig erweiter werden kann. Schön ist auf jeden Fall, dass sich dadurch ganz neue Möglichkeiten für AIR Applikationen auftun. Der große Nachteil von AIR bleibt aber weiterhin, dass die AIR Runtime auf jeden Fall installiert werden muss, es ist also zum Beispiel kein Starten von CD möglich.

Links und weitere Beispiele:

FlashForum Konferenz 2010 – Community. Code. Creativity.

Auch dieses Jahr hatte ich die Möglichkeit die FFK zu besuchen, nachdem ich letztes Jahr bereits dort war. Auch Jürgen war diesemal mit dabei. Zwei Tage voller Vorträge über Flash, Flex und ActionScript, aber auch über Themen die über das reine Coding hinausgehen. Also eine breitgefächerte Themenwahl, welche jeden Flasher und Flexer in gewissem Maße betreffen.

Um es gleich Vorweg zu nehmen: Es war der Hammer. Die Fülle an Eindrücken, von neuen Ideen, Technologien und Ansätzen war wieder immens und macht wiederum klar wie mächtig eigentlich die Flash Platform ist. Aber auch die Selbstverständlichkeit im fast schon familiären Umgang der Coder untereinander war wieder beindruckend. Wann hat man denn schon die Möglichkeit die „Größen“ der Szene zu treffen und mit ihnen alltägliche Coderprobleme zu besprechen.

Dieser Text soll nun nur einen kleine Überblick sein, was ich an Themen mitbekommen hab in den Vorträgen. Ich denke in der nächsten Zeit werden Jürgen und ich immer mal wieder ein Thema hier von auf diesem Blog behandeln. Serge Jespers eröffnete die FFK und stellte unter anderem die Flash Platform Services vor. Interessant hier vor allem die Bereiche Distribution und Collaboration. Die ebenfalls dazugehörenden Social Services waren schon aus dem com.adobe Package bekannt.

Ich möchte jetzt nicht auf jeden Vortrag eingehen den ich gesehen habe. Aber ein paar Highlights für mich herauspicken. Dazu zählt unter anderm der Vortag von Michael Wacker „Mind the gaps“, der das Themas Flash Security hatte. Eine richtig gute Anregung und ein Fingerzeig für die Community, was es noch mangelt. Ganz klar mit dabei bei meinen Favoriten mit dabei Andre Michelles „Tanzen mit Krücken“. Sehr beeindruckend, vor allem interessant, dass immer mal wieder Tipps und Trick durchsickerten, wie SWFs schnelle und sicherer Laufen. Aber dies nicht nur bei ihm. Auch Saban Ünlü oder Ralph Hauwert mit seinen experimentellen Animationen, ließen hier und da immer wieder ein paar Worte dazu fallen.

Aber auch Bereiche wie Performance Tuning, Usability Testing, Aufbau von Software für Multitouch Devices waren Themen auf der FFK. Richtig beeindruckend, wie schon letztes Jahr, die beiden Vorträge von Joa Ebert und Mario Klingemann. Joas „Apparat“ ist kurz gesagt einfach der Hammer. SWF ByteCode Optimierung um so noch mehr auf Flash rauszuholen und noch schnelle Animationen laufen lassen zu können. Der experimentelle und künstlerische Ansatz von Mario versetzt jeden Flasher immer wieder in Staunen.

Der für mich am interessanteste Vortrag war aber von Jens Halm: „Enterprise Applications mit dem Parsley Application Framework“. Ich hatte davor wenig gehört von Inversion of Control und der ganzen Thematik die hier vorgestellt wurde. Aber der Ansatz der Modularisierung des Codes und der Vereinfachung der Zugriffe und Abhängigkeiten, vor allem die Implementierung in Cairngorm 3 haben mich hellhörig gemacht. Ein Ansatz der Programmierung der mir sehr entgegen kommt und vor allem auch den Workflow des einzelnen und eines ganzen Teams, aber auch das Testen von Apps und Teilbereiche deren immens vereinfacht und verbessert.

Ich könnte jetzt so noch ewig weiter schreiben, da beide Tage voll solche Eindrücke waren. Aber wie gesagt, in nächster Zeit gibt es hier immer wieder ein paar Auszüge davon. Nur eins noch: Ich warte jetzt schon auf die FFK 2011!

http://ffk10.flashforum.de/
http://www.adobe.com/flashplatform/services/

Multitouch in Flash und AIR

Seit dem 02. Februar ist Adobe AIR 2.0 beta 2 unter Adobe Labs verfügbar und bereits seit Mitte Dezember 2009 gibt es eine Betaversion des FlashPlayers 10.1. Eine der Neuerungen ist die Unterstützung von Multitouch Events. Dies eröffnet neue Wege der Interaktion und bringt ein ganz neue Benutzererfahrung die schon von dem IPhone bzw. IPodTouch bekannt ist.

Die Voraussetzung ist natürlich eine entsprechende Hardware. Um die Multitouchfähigkeit testen zu können ist entweder ein multitouchfähiger Touchscreen oder ein Touchpad wie zum Beispiel beim MacBook Pro erforderlich. Außerdem kommt es darauf an wie viele Touchpunkte das Eingabegerät unterstützt, von Flash Seite gib es hier keine Einschränkungen.

Doch wie sieht das Ganze in ActionScript aus? Die Multitouchfähigkeit basiert hauptsächlich auf folgenden Events

  • flash.events.TouchEvent
  • flash.events.GestureEvent
  • flash.events.TransformGestureEvent

Multitouch Input Mode
Es gibt zwei Multitouch Modi MultitouchInputMode.TOUCH_POINT und MultitouchInputMode.GESTURE. Um Multitouch Events verwenden zu können, muss die statische Variable inputMode der Multitouch Klasse gesetzt werden: Multitouch.inputMode = MultitouchInputMode.GESTURE;. Wird der Modus „touchPoint“ gewählt werden TouchEvents dispatched, wird der modus „gesture“ gewählt werden GestureEvents und TransformGestureEvents dispatched. Anhand der TouchPoint Events können die verschiedenen Berührungspunkte ausgelesen und verarbeitet werden.
In diesem Eintrag will ich aber auf die Gestures eingehen. Es werden die vom IPhone bekannten Gesten für zoomen, drehen und wischen (mit zwei oder drei Fingern) und der tab mit zwei Fingern unterstützt.

  • TransformGestureEvent.GESTURE_ZOOM
  • TransformGestureEvent.GESTURE_ROTATE
  • TransformGestureEvent.GESTURE_PAN (2 Finger)
  • TransformGestureEvent.GESTURE_SWIPE (3 Finger)
  • GestureEvent.GESTURE_TWO_FINGER_TAP

Test Anwendung
Um die Funktionen zu testen habe ich eine einfach AIR Anwendung gemacht in der Bild über die Gesures gedreht, gezoomt, und bewegt werden kann. Mein Test AIR App kann hier heruntergeladen werden, es wird allerdings die AIR 2.0beta Runtime benötigt und natürlich ein Eingabegerät das Multitouch unterstützt.

Anwendung auf Propeller
Mein Kollege Alex hat gestern einen Beitrag zu seinem Propeller-Experiment geschrieben, diesen habe ich genommen und mit Multitouchfähigkeiten ausgestattet. Über die Geste Rotation kann der Propeller rotiert werden, über zoom kann gezoomt werden und das Wischen mit 3 Fingern wechelt die Farbe. Hier gibts die AIR Applikation, viel Spaß beim ausprobieren.

Flash Experiment – Rotation

Eine Rotation über den Abstand der Maus zum Zentrum. Dabei werden hier in diesem Beispiel nur zwei Shapes gezeichnet, um dann eine Animation & Verzerrung über Matrix-Berechnungen und BitmapData.draw() zu realisieren:

This movie requires Flash Player 9

Der zeroseven SOUND VISUALIZER

Der Visualizer ist aus der einfachen Idee entstanden, Sounds mittels Flash zu visualisieren. Begonnen hat es mit einfachen Ausgaben des Spektrums eines Sounds mit Hilfe der computeSpectrum() Methode des SoundMixers. Immer weitere Versuche, was mit dem entstehenden ByteArray machbar ist, entstanden.

In Gesprächen entwickelte sich dann die Idee, eine Plattform zu schaffen, welche Sounds eines Users analysiert, visualisiert und später dann ein Bild zum Download der aktuellen Visualisierung anbietet. Ein einfacher Screenshot wäre hier möglich gewesen und die Bilder jpg- oder png-kodiert zum download anzubieten. Aber solche Bilder sind sehr klein und können dann z.B. nicht als Plakat gedruckt werden. Also suchte ich nach einer anderen Lösung. SVG wäre eine Variante gewesen. Dazu hatte ich auch schon die Grundzüge eines Exporters geschrieben, der die XML-Struktur aus Graphics-Elementen in ActionScript bilden kann. Hiermit wäre zumindest die freie Skalierbarkeit des Plakates gewährleistet. Etwa zu dieser Zeit bin ich dann auf die Bibliothek AlivePDF von Thibault Imbert gestoßen und hab auch hier erste Versuche betrieben (siehe labs-Eintrag dazu). Und nach ein paar Tests war klar, das ist der Weg, den ich für den Visualizer gehen muss.

Aber der SVG Exporter war nicht ganz gestorben. Das Logging-Tool das im Hintergrund mitläuft ist noch immer Teil der Anwendung. Einfach gesagt, merkt sich dass Tool die Spezifikationen aller Elemente. Dieses Log nutze ich jetzt beim PDF-Export zum Erstellen der Elemente des PDFs.

Anfangs mit random-Farben ausgestattet, brachte Sebastian die Idee ins Spiel Kuler für Farbprofile zu nutzen. Also erfolgte mit Hilfe des Adobe Syndication Packages das Laden und Auslesen des Feeds der 20 beliebtesten Farben von Kuler. Dennoch hat auch der User die Möglichkeit eigene Farben zu verwenden. Ein eigenes ColorPicker-Tool kommt hier zum Einsatz.

Auch die Formen wurden vielfältiger. Anfangs nur mit Kreisen gezeichnet, kamen weitere Grundformen und Polygone hinzu. Auch die Möglichkeiten der Ausgabe erweiterten sich, je mehr ich mich darin „reingetestet“ hatte. Eigene Formate entstanden sowie Hilfstools zur Umrechnung von Pixelwerten aus dem Logger hin zu Zoll und Millimeter. Die Oberfläche bekam ein schickes Design verpasst und weitere Funktionen spendiert, um dem User mehr Möglichkeiten zu geben sein eigenes Plakat zu erstellen.

Ein Problem das es zudem zu bewältigen galt, waren die Probleme der SoundMixer.computeSpectrum() Methode. An sich eine tolle Sache und auch die Möglichkeit den ByteArray als RAW-Daten oder als Daten mit einer schnellen Fourier-Transformation zu erhalten ist sehr viel wert. Aber der SoundMixer hat einen entscheidenden Nachteil. Er ist eine globale Klasse und greift somit auf alle möglichen Sounds zu. Das führte dazu, dass der Visualizer zum Beispiel versucht auf die Sounds eines Videos von YouTube zuzugreifen, wenn dieses in einem anderen Browser Tab oder Fenster läuft. Und ganz klar entsteht dabei ein Sandbox-Problem. Umgangen habe ich diese Problematik mit Hilfe der Sound.extract() Methode. Sie liefert den ByteArray gleich zu Anfang zurück und zwar für den gesamten Audiostream. Daher erfolgt hier die Abtastung anders und etwas komplizierter als bei der computeSpectrum() Methode. Aber auch hierzu gibt es schon einen labs-Eintrag von mir (Link).

So entwickelte sich mit der Zeit eine Oberfläche, die für mich zum einen als Versuchs- und Testprojekt diente, aber letztendlich ein Tool darstellt, das ein breites Spektrum der Flashfunktionen abdeckt und auch zeigt was man performancetechnisch mit Flash so anstellen kann.

Aber nun nicht länger lesen sondern einfach ausprobieren:
http://visualizer.zeroseven.de/

Des weiteren möchte ich noch Thibault Imbert für seine Mühe und Arbeit bei AlivePDF danken, ein wirklich hammerkrasses Tool! Ebenso Sascha Wolter für seinen SystemManager, den Junges von Greensock für TweenLite & TweenMax, den Entwicklern des De MonsterDebugger und denen von pixelbreaker.com für das MacMouseWheel.

www.alivepdf.org
www.wolter.biz
www.greensock.com
www.pixelbreaker.com
www.adobe.com
www.demonsters.nl

Flash Experiment – Pixelhole

Ein weiteres Experiment, das ein Bild auf Pixelbasis animiert. In Bezug auf die Mausposition zum jeweiligen Pixel wird eine Verschiebung generiert. Einfach klicken und ausprobieren:

This movie requires Flash Player 9