HTML5 vs. Flash

Derzeit ist in aller Munde der anstehende, neue Standard HTML5. Bietet HTML5 wirklich so viele Funktionen und Möglichkeiten, dass Flash zukünftig überflüssig wird? Verliert Flash durch den Einsatz von HTML5 seine Daseinsberechtigung? Eine entscheidende Antwort darauf kann heute nicht gemacht werden, wenn auch Steve Jobs unmissverständlich sich gegen Flash geäußert hat.

Die Grundlage für HTML5 wurde bereits im Jahr 2004 gelegt. In diesem Jahr gründeten kurzerhand die größten Browserhersteller, Apple, Opera und die Mozilla Foundation unter dem Namen „Web Hypertext Application Technology Vorging Group – kurz WHATWG – eine HTML-Arbeitsgruppe und veröffentlichten erste Entwürfe für eine neue Spezifikation namens „Web Applications 1.0“, welche den Grundstein für das heutige HTML5 darstellt. Im Oktober 2009 beschloss das W3c (World Wiede Web Consortium) unter Vorsitz des Internet-Pioniers Tim Berners-Lee den strengeren Standard XHTML durch HTML5 abzulösen. Ursprünglich wollte das W3C Konsortium parallel einen eigenen Webstandard XHTML 2 der auf Basis von HTML 4 und XHTML 1 – welcher seit dem Jahr 2000 als Standard gilt – aufbaut. Der XHTML 2 Standard sollte mit dem aktuellen Standard von HTML 4 und XHTML 1 kaum noch was gemeinsam haben, und rein auf XHTML aufbauen. HTML5 ist dagegen abwertskompatibel und hat vor allem das Ziel, HTML sinnvoll zu erweitern und zu verbessern. Die Entscheidung, welcher Standard letztendlich das Rennen macht, hatte aufgrund der Macht der Arbeitsgruppe WHATWG, der inzwischen Google ebenfalls angehört, die bessere Ausgangssituation. Das W3C hat mittlerweile eine eigene Arbeitsgruppe gegründet, die ebenfalls an HTML5 arbeiten, somit wurde der einst angedachte Standard XHTML 2 zwischenzeitlich wieder eingestellt. HTML5 soll bereits 2012 den Level W3C Candidate Recommendation erreichen.

Was genau bringt denn der neue Standard HTML5 mit?

Genaugenommen sind die Neuerungen von HTML5 ganz überschaubar. Insgesamt wurden weniger als 30 neue Tags definiert (als Tags bezeichnet man die in Klammer gesetzten Elemente, welche die Grundlage der HTML-Programmiersprache bilden). Die vielversprechensten Neuerungen sind hierbei die Canvas- und Video-Elemente. Zusätzlich wurden weitere Ergänzungen für das „semantische Web“ definiert. Diese Tags sind massgeblich dafür verantwortlich, dass mehr Inhalte für Suchmaschinen lesbar werden. Ein klassisches Beispiel ist hier die semantische Suchanfrage direkt in den Ergebnislisten. Mit dem Canvas-Element (deutsch Leinwand), können in einem rechteckigen Bereich – durch die JavaScript-Sprache – pixelgenau Inhalte positioniert werden. Dies ermöglicht viele neue Spielereien, die sinnvoll oder sinnlos sein können. Genauso interessant ist das Video-Element. Der „video-Tag“ ermöglicht in Zukunft ohne Plug-In’s, Videos direkt in Websites einzubetten und abzuspielen. Das hört sich in erster Linie sehr sinnvoll und interessant an. Aber, die Antwort welcher Codec in der Zukunft als Standard-Codec verwendet wird, ist bis heute noch nicht definiert. Eigentlich sollten ja Standards das Ergebnis erzielen, dass einheitliche Regelungen definiert werden. Beim Video-Codec ist sich die Arbeitsgruppe nicht einig. Apple mit Safari setzen hier auf den kommerziellen MPEG-Codec H.264, für dessen Nutzung ab 2016 Lizenzen anfallen. Firefox und Opera setzen dagegen auf den Open-Source-Codec „Ogg Theora“. In der Kompression bietet der H.264 Codec Vorteile gegenüber dem Ogg-Codec. Wie die Lizenzbedingungen des H.264 zukünftig aussehen werden, ist heute noch nicht bekannt. Für Websitebetreiber kann das in Zukunft aber wieder bedeuten, dass mehrere Technologien vorgehalten werden müssen.

HTML5 bietet vor allem im Bereich der Usability neue Möglichkeiten. Denkt man alleine einmal an die vielen Formular-Seite, die zukünftig durch den neuen Standard besser und einfacher bedient werden können. Oder sehen wir das rasante Wachstum von mobilen Endgeräten wie zum Beispiel das iPhone, das iPad oder die Android Handys. Hier bietet HTML5 mit der Gesten- oder Touchscreensteuerung viele neue Möglichkeit für die Bedienung einer mobilen Website.

Abschließend ist aus meiner Sicht die Technologiefrage noch lange nicht geklärt. Ob HTML5 Flash wirklich ablöst glaube ich nicht. Alleine die Unentschlossenheit im Video-Codec setzt schon voraus, dass hier weiterhin unterschiedliche Technologien zum Einsatz kommen können. Warum dann nicht gleich mit Flash entwickeln? Genauso bleibt die Frage offen, wie viele User weiterhin trotz HTML 5 Standard den Flash-Player installiert haben. Wenn die Zahl der installierten Flash-Player von 90 Prozent – oder selbst 80 Prozent – immer noch überschritten ist, sehe ich die Diskussion der Technologie als überflüssig. Dass sich Flash in Zukunft weiterentwickeln wird ist auch klar. Adobe wird schon in absehbarer Zeit sämtliche mobile Plattformen wie Android, Symbian, WebOS, BlackBerry oder auch Windows Mobile mit dem Flash-Player oder der Laufzeitumgebung AIR bedienen. Was für die Entwicklung wiederum bedeuten kann, dass mit der Entwicklungsumgebung von AIR ein Großteil der mobilen Technologien abgedeckt werden kann. Welcher Marktanteil dann Apples iOS übernimmt bleibt abzuwarten. Ob Apple sich auf Dauer der Flash-Technologie verschließt, bleibt abzuwarten.

Weiterführende Links zum Thema HTML5.

Möchten Sie Ihren Browser auf HTML5 testen? Rufen sie hierzu die Internetseite „www.html5test.com“ auf. Bei dem Projekt von Niels Leenheer erhält man in einer grafischen Übersicht, welche HTML5-Funktionsbereiche Ihr Browser unterstützt. Die maximale Punktzahl die erreicht werden kann ist 300 Punkte. Beim Test mit Safari 5.0.3 erreichte dieser 208 Punkten.

– Apples HTML5 Showcase: www.apple.com/html5
– Googles Showcase: www.chromeexperiments.com
– Canvas 3D Modell: http://bit.ly/3d_modell
– Diverse HTML5 Showcases: http://bit.ly/showcases
– Drag and Drop: http://html5demos.com/drag

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:

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

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

Flash Experiment – Lines

Ein kleines Flash-Experiment das knapp 1300 gebogene Linien mittels der Graphics Klasse zeichnet. Diese Linien werden dann aber nicht dem DisplayStack hinzugefügt, sondern über BitmapData.draw in ein Bitmap-Objekt gezeichnet. Damit ist eine relativ performate Animation möglich.

This movie requires Flash Player 9

Baut man diese Animation weiter aus, kann man die Überlagerungen und Alpha-Werte dazu nutzen, einen DisplacementMapfilter zu verwenden. Durch dessen Einsatz bekommt die Animation einen fluiden Eindruck.

This movie requires Flash Player 9

Flash CS5 [Viper] Preview

Flash CS5 steht in den Startlöchern und die ersten Features sickern langsam durch. Auch erste Preview-Videos stehen im Netz zum Ansehen bereit. Zudem soll noch im Dezember 2009 die Beta-Version von Viper bei Adobe zum Download bereit stehen. Der endgültige Release ist zeitlich noch nicht genau definiert, soll aber im Frühjahr 2010 erscheinen. Aber jetzt ist schon ein guter Zeitpunkt mal reinzuschauen was Flash CS5 mit sich bringt:

Apps fürs iPhone
Applications fürs iPhone schreiben. Diese Info ist wohl die am meisten verbreitete über das kommende Flash. Anfangs war ich noch recht skeptisch, in wie weit dies funktioniert. Gibt es Systemzugriffsmöglichkeiten auf zum Beispiel uad den Accelerator oder die Kamera im iPhone? Lee Brimelow hat dazu ein Video gemacht, worin er einen einfachen Codingansatz zeigt. Und es zeigt ganz klar, dass eben diese Hardwarezugriffe möglich sind. Hierfür gibt es eigene Klassen, die auch funktionieren sollen für andere mobile Endgeräte die z.B. einen Accelerator eingebaut haben. Leider ist es immer noch nicht möglich, Flash-Inhalte auf Webseiten auf dem iPhone anzusehen.

TextLayout Framework
Aber es gibt noch weitere Features neben dem Entwicklen von iPhone-Apps, auch wenn sie dagegen leider etwas untergehen. Zum Beispiel ist nun das TextLayout Framework in Flash CS5 integriert. Dieses Framework ist schon bereits veröffentlicht (opensouce) und kann in Flash wie auch Flex Projekten verwendet werden. Es bietet, vor allem im Vergleich mit den bisherigen Textmöglichkeiten, unglaublich viel mehr Möglichkeiten. Hier sollen sich die Entwickler von Flash mit denen von InDesign zusammengesetzt und zusammen dieses Framework erstellt haben. Auf jeden Fall ist dieses nun mit im neuen Flash fest integriert. Eine detailierte Info hierüber ist einen eigenen Blogeintrag wert und würde hier die Grenzen überschreiten, aber Jürgen hat dazu schon was geschieben:
http://labs.zeroseven.de/development/air/text-layout-framework-fur-flash-flex-und-air/
http://labs.zeroseven.de/development/flex/schriften-fur-die-neue-text-engine-des-flash-player-10-einbetten/

Coding
Bisher war es sehr umständlich in Flash direkt zu programmieren. Dies wird besonders auffällig, wenn man das bisherige Actions-Panel mit zum Beispiel Eclipse vergleicht. In Flash gibt es kein ordentliches Codehinting oder so unterstützende Features wie automatisches Erstellen von Klassen-Imports oder Snippets gibt es einfach nicht. Das hat den eigentlichen Programmieraufwand innerhalb von Flash extrem nach oben geschraubt. Im Video von Lee Brimelow zum iPhone, sieht man aber auch schon diese neuen Features von CS5. Imports und Snippets sind nun integriert. Auch werden Codehints für eigene Klassen dargestellt.

FlashBuilder Integration
Auch dieses Feature ist besonderns für Coder interessant. Wie gesagt, soll das Actions-Panel verbessert werden und das ist ja schon mal nicht schlecht. Es bleibt aber eine Panel und kann nicht Eclipse oder das darauf basierende FlashBuilder-Tool ersetzeb. Auch dies haben die Entwickler von Adobe erkannt und bieten eine Integration als ActionScript-Editor an.

Das waren jetzt meiner Meinung nach die ersten und auch wichtigsten Features zum neuen Flash CS5. Sicherlich kommen noch einige dazu. Aber es ist schon abzusehen, dass die diesmalige Weiterenticklung sehr stark zu Gunsten von Coding ausfallen wird.

Weitere Infos zum Thema:

Twitter zu Flash: http://twitter.com/adobeflash
Facebook-Seite zu Flash: http://www.facebook.com/flashplatform
Adobe Labs Flash CS5: http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/
Lee Brimelow iPhone-App Preview: http://theflashblog.com/?cat=50
TextLayout Framework: http://opensource.adobe.com/wiki/display/tlf/Text+Layout+Framework

Nachtrag:
Wie ich gerade gelesen habe, wurde die Beta-Version des neuen Flash CS5 abgesagt. Aus Gründen der Stabilität laut Adobe. Eine etwas detailiertere Nachricht hat Lee Brimelow auf seinem Blog: http://theflashblog.com/?p=1546. Nun bleibt zu hoffen, dass wenigstens der Realease wie angekündigt bestehen bleibt.

Farben in ActionScript

Neben der weitgehenden Browserunabhängigkeit bietet ein SWF dem Entwickler auch die Möglichkeit, Umgebungen zu schaffen die den User zu begeistern. Der Weg dorthin ist vielfältig. So sind, im Vergleich zu HTML, die freie Schriftwahl, einfach zu erstellende Animationen oder die Integration verschiedenster Medien wichtige Bestandteile davon. Aber auch der richtige Umgang mit Farben ist ungemein wichtig.

Farbe ist in ActionScript nicht nur einfach eine bunte Fläche. Das ist was der User am Bildschirm sieht. Jede Farbe ist letztlich ein HEX-Code. So lässt sich weiß zum Beispiel mit 0xFFFFFF aus drücken oder wenn eine Alphakanal dabei sein soll eben 0xFFFFFFFF.

Beschränken wir uns aber zunächst auf den RGB-Raum ohne Alphakanal. Jeder Farbkanal umfasst einen Bereich von 0 (0x00) bis 255 (0xFF), oder binär ausgedrückt 0 bis 11111111. Durch diese Definition kommen die fast 16,6 Millionen Farben zusammen, denn 255 * 255 * 255 ergibt eben fast 16,6 Millionen. Und mit 16 Millionen Farben lässt sich wirklich einiges Anfangen.

Zu beachten ist aber, bevor man anfängt mit Farben zu rechnen, dass Farben im 16er-System definiert sind und nicht, wie der normale Mensche rechnet, im 10er-System. Um die Farben ausgeben zu können ist es daher notwändig anzugeben in welchen Zahlensystem. Gibt man den Farbwert einfach über einen trace aus, schreibt der FlashPlayer den Wert im 10er-System. Will man aber eine hexadezimale oder binäre Ausgabe, muss man die toString-Methode nutzen, wobei hier als Parameter das System angegeben werden kann (z.B. 16 für hexadezimal).

Will man die einzelnen Känale getrennt von einander bearbeiten, muss die Farbwert zerlegt werden. Dafür werden bitweise Operatoren benötigt. Will man nun den Wert für den grünen Kanal auslesen sieht das Script dazu wie folgt aus:

var baseColor:uint = 0x4598FF;
var green:unit = (baseColor & 0x00FF00) >> 8;
trace (green.toString(16)); // 0x98

Um das kurz zu erklären: Zunächst nimmt man die Ausgangsfarbe und entfernt alle Farbwerte, außer die grünen, durch den logischen AND-Operator (&). And ist so definiert, dass, nur wenn beide miteinander zu „verundende“ Bits den Wert 1 haben, das Ergebnis 1 zurückgegeben wird. Deswegen gibt diese Rechnung nur die grünen Werte zurück. Anschließend werden die Bits noch um 8 Stellen nach rechts verschoben, damit die grünen Werte am Ende stehen. Diese Prozedur ist für alle anderen Farbbereiche die selbe.

Hat man nun alle seine Berechnung durchgeführt und will die einzelnen Känale wieder zusammensetzen geschieht auch dies wieder mit bitweisen Operatoren:

var color:uint = alpha << 24 | red << 16 | green << 8 | blue;

Hier nimmt man die Werte für die einzelnen Känale schiebt sie soweit, wie eben eine ARBG oder RGB Farbe definiert ist und „verodert“ die einzelnen Werte. Das logische oder sagt aus, dass sobald eines der beiden zu vergleichenden Bits 1 ist, das Ergebnis 1 zurück gegeben wird. Wie die einzelnen nun Farben berechnet werden, ist jedem Entwickler freigestellt. Nur eben die oben gezeigt Basics müssen beachtet werden, dmait die richtigen Farben zu sehen sind.

Aber nicht alles muss berechnet werden. So bietet die TweenMax-Bibliothek auch schon die Möglichkeit Farbtweens zu scripten:

TweenMax.to(colors, 0.15, {hexColors:{targetColor}, onUpdate:updateColorizedObject});

Hier ist colors ein Object das einen oder möglicherweise mehrere Farbwerte einhält. TweenMax macht dann einen Tween über die Farbe. Dabei werden Update-Events dispatched und im Handler lässt sich der aktuelle Farbewert aus colors wiederum auslesen.

Auch ein interessante Ansatz Farben zu verändern ist der ColorMatrixFilter. Dieser ist als 4×5 Matrix definiert und ist ein BitmapFilter. Mit Hilfe dieser Matrix lässt sich aber nicht nur die Farbe verändern sondern auch die Sättigung und die Luminanz. Anwendbar ist dieser filter auf jedes DisplayObject.
Weiter auf diese Klasse einzugehen ist aber wiederum ein eigener Blogeintrag wert.

http://blog.greensock.com/tweenmaxas3/
http://www.adobe.com/devnet/flash/articles/bitwise_operators_03.html
http://help.adobe.com/de_DE/AS3LCR/Flash_10.0/flash/filters/ColorMatrixFilter.html