Geleitwort

Jedes Mal, wenn ich mich über Flex 2 unterhalte, sind die am häufigsten gestellten Fragen auch immer die elementarsten: Was ist das, wozu ist es gut und warum haben wir es überhaupt entwickelt? Es zeigt sich, dass diese Fragen zwar einfach sind, aber auch tatsächlich den Kern dessen treffen, um was es bei Flex 2 eigentlich geht.

Flex 2 ist eine neue Technik zur Entwicklung sogenannter Rich-Internet-Anwendungen, die im Flash Player laufen und daher sehr gut aussehen, schnell reagieren und hochgradig interaktiv sind. Es wurde so entworfen, dass es insbesondere für diejenigen mit einem Hintergrund in der Web- oder Anwendungsentwicklung komfortabel und produktiv zu nutzen ist (auch wenn es für jedermann geeignet ist).

Warum haben wir Flex entwickelt? Nun, das ist eine längere Geschichte.

Das kann doch nicht so schwer sein

Meine Beteiligung an der Entwicklung von Flex 2 begann tatsächlich mit einer Art Initialzündung. Wie jeder andere, der im Web surft, bin ich gelegentlich über eine Anwendung gestolpert, die mir einfach den Atem geraubt hat. Sie war reaktionsschnell, sah hervorragend aus und hatte eine nahezu filmische Qualität. Neugierig geworden, schaute ich mich ein wenig um, um herauszufinden, wie sie entwickelt wurde.

Ich entdeckte, dass die meisten dieser Anwendungen mit Flash entwickelt worden waren. Da ich aus der Softwareentwicklung komme und gerne Dinge entwerfe, wollte ich Flash ausprobieren. Das habe ich auch getan: Das Ergebnis war schockierend und ernüchternd. Ich habe kläglich versagt und konnte mir nicht vorstellen, wie irgendjemand überhaupt irgendetwas mit Flash entwickeln konnte, ganz zu schweigen von den extrem kreativen Anwendungen, die mich inspiriert hatten.

Ein Teil des Problems lag im Flash-Autorentool begründet. Es fühlte sich nicht nur nicht so an wie die Entwicklungswerkzeuge, an die ich gewöhnt war, es schien auch nicht für die Dinge entworfen worden zu sein, die ich damit machen wollte. Zum Beispiel ist die Zeitleiste eines der auffälligsten Merkmale von Flash. Ich konnte um alles in der Welt nicht herausfinden, wie ich sie einsetzen sollte, um eine Anwendung zu entwickeln. Zwar stellen Entwicklungswerkzeuge häufig eine Toolbox mit Komponenten wie Buttons oder Listen zur Verfügung, die man auf die Arbeitsfläche ziehen kann, aber die Flash-Toolbox war anders. Hier bestanden die Komponenten aus Dingen wie Linien, Rechtecken, Stift, Pinsel und Farbeimer. Wie entwickelt man eine Anwendung mit einem Stift?

Das andere Problem war für mich die Terminologie, in der die vom Flash Player genutzten Konzepte erläutert wurden. Bei Flash werden kleine wiederverwendbare UI-Elemente als Movieclips bezeichnet. Der Hauptausgabebereich wird als Bühne bezeichnet. Das Ergebnis der Kompilierung eines Projekts ist ein Movie. Ich kann Ihnen gar nicht sagen, wie verwirrend es war, ein Problem mithilfe des Debug-Movie-Befehls zu untersuchen.

Möglicherweise brauchen wir einen anderen Ansatz

Aus meinem Experiment schloss ich, dass Flash einfach nicht für die Anwendungsentwicklung oder für Entwickler wie mich konzipiert war. Statt das aber als Problem zu betrachten, sah ich es als Chance. Wie viel mehr großartige Flash-Anwendungen könnte es geben, wenn es für Programmierer einfacher wäre, diese zu entwickeln?

Ich konzentrierte mich auf diese Frage, statt mich weiter an Flash selbst zu versuchen, weil mein Hauptinteresse bei Software nicht so sehr in der Anwendungsentwicklung, sondern vielmehr im Prozess der Entwicklung selbst liegt. Daher interessiert mich am meisten, wie der Code tatsächlich aussieht. Aus diesem Grund habe ich einen Großteil meiner Karriere mit Anwendungsframeworks und Tools verbracht, die die Entwicklung vereinfachen sollen.

Mein erstes Framework hieß zApp, und ich begann 1989 mit seiner Entwicklung. Ich hatte seit drei Jahren unter Windows (Version 1.03) entwickelt und war zunehmend frustriert, wie kompliziert die Sache war. zApp machte die Entwicklung unter Windows nicht nur wesentlich einfacher, sondern löste auch einige Schlüsselprobleme der Entwickler. Es erlaubte die Portierung der Anwendung auf andere Plattformen wie OS/2 oder Unix durch eine einfache Neukompilierung. zApp wurde 1991 veröffentlicht und wurde ein populäres Cross-Platform-Anwendungsframework.

Mitte der 1990er, als ich für Microsoft arbeitete, hatte ich etwas mehr mit Webanwendungen zu tun und war überrascht, wie schwierig es war, sie zu schreiben. 1997 entwickelten daher ein Kollege und ich den Prototypen eines Frameworks für die Webentwicklung, den wir XSP nannten. Basierend auf dem Erfolg des Prototyps führte ich ein Team an, das eine entsprechende Produktionsversion entwickelte, die wir 2002 unter dem Namen ASP.NET auslieferten.

Als ich also über Flash nachdachte, kam die gleiche Begeisterung in mir auf wie bei diesen vorangegangenen Projekten. Ich wollte etwas mit Flash machen und dabei gleichzeitig zwei Bereiche erkunden, die mir eh schon am Herzen lagen: die Entwicklung von Webanwendungen und (umfang)reiche Cross-Platform-UIs. Mitte 2004 kam ich daher zu Macromedia, um Flash zu einer hervorragenden Plattform für Entwickler zu machen.

Meine erste Begegnung mit Flex

Bei Macromedia bestand meine erste Aufgabe darin, alle Projekte kennenzulernen, die etwas mit Flash zu tun hatten, und so hörte ich das erste mal von Flex. Die Version 1.0 war ein paar Monate zuvor veröffentlicht worden und wurde mir als Presentation-Server für erfahrene Java-Entwickler beschrieben, die Anwendungen für Unternehmen entwickeln. Als ich das hörte und den Preis (der sehr hoch war) erfuhr, wusste ich, warum ich bisher keine Notiz davon genommen hatte. Ein hochpreisiger Enterprise-Server war für mich nicht gerade ein einfacherer Weg zur Entwicklung von Flash-Anwendungen.

Dennoch machte ich mich mit der Funktionsweise von Flex vertraut, und mein Interesse begann zu wachsen. Das von Flex bereitgestellte Schlüsselelement war ein leistungsfähiges, einfach zu verwendendes, entwicklerfreundliches Framework zur Entwicklung von Flash-Anwendungen. Es besaß außerdem eine XML-basierte Sprache zur Definition der UI-Strukturen, die ironischerweise der Programmierung in ASP.NET stark ähnelte.

Die Serverkomponente von Flex hatte einen Compiler zu bieten, der den gesamten Code in eine SWF-Datei übersetzte, die vom Flash Player ausgeführt werden konnte. Dieses »Kompilieren bei Bedarf«-Modell ähnelte sehr stark dem Aufbau von Anwendungen unter ASP.NET. Im Gegensatz zu ASP.NET lief der geschriebene Code aber auf dem Client und nicht auf dem Server.

An diesem Punkt stellte ich mir die Frage, warum Flex eigentlich ein Server war. Man braucht keinen Server, um etwas zu kompilieren, und es schien mir wesentlich einfacher zu sein, dies auf dem Rechner des Entwicklers zu tun.

Es gab noch eine weitere (mit Java-Code auf dem Backend implementierte) Serverkomponente, die es Flash ermöglichte, über ein optimiertes binäres Protokoll mit dem Server zu kommunizieren. Das war die einzige Komponente, die wirklich als Server ausgelegt sein musste. Allerdings wurde sie nur in bestimmten Szenarien genutzt und war tatsächlich optional. Sie adressierte also nicht das fundamentale Problem, das ich lösen wollte, nämlich die Entwicklung von Flash-Anwendungen für Entwickler einfacher und intuitiver zu machen.

Flex, die Zweite

Das größte Problem, das ich bei Flex 1.0 sah, war also nicht die Technologie an sich, sondern vielmehr das daraus geschnürte Paket und dessen Positionierung. Flex als teuren Enterprise-Server zu verkaufen, machte es für diejenigen Entwickler uninteressant, die einfach nur coole Dinge in Flash programmieren wollten. Ich konnte mir nicht vorstellen, dass jemand, der Flash auf die gleiche Weise kennengelernt hat wie ich, sagen würde: »Hmmm, eigentlich nichts für mich, aber vielleicht probiere ich mal den zigtausend Dollar teuren Enterprise-Presentation-Server aus.« Das Ergebnis war eine verpasste Gelegenheit, denn ich war davon überzeugt, dass Entwickler Flex lieben würden, wenn sie es denn mal ausprobieren würden.

Nachdem ich mich umgesehen hatte, formulierte ich einige Empfehlungen, was meiner Meinung nach getan werden sollte. Die erste Empfehlung lautete, den Teil von Flash, der zur Entwicklung von Flex-Anwendungen verwendet wurde (d.h. das Flex-Framework und den Compiler), vom Server getrennt anzubieten. Ich hatte kein Problem mit dem Server, da er durchaus seinen Wert hatte, aber er sollte nicht zwangsläufig verwendet werden müssen.

Ich empfahl außerdem die Entwicklung eines echten Entwicklertools für Flash, das ein etwas traditionelleres Client-Entwicklungsmodell unterstützen würde. Flex 1.0 besaß ein Entwicklertool namens Flex Builder, das aber als Erweiterung von Dreamweaver ausgelegt war und viele Features vermissen ließ, die man bei einer echten Entwickler-IDE erwartet. Ich wünschte mir eher etwas, was sich mehr nach einem Tool wie Visual Studio oder Eclipse anfühlte.

Das Flex 2-Framework

Glücklicherweise gab es breite Zustimmung, und meine Empfehlungen gingen in die Entwicklung von Flex 2 ein. Was heißt das nun genau?

Den Kern von Flex 2 bildet das Flex-Framework, eine Bibliothek von ActionScript-Objekten, die die Grundlage zum Aufbau von unter Flash laufenden Rich-Internet-Anwendungen bilden. Es handelt sich dabei um ein entwicklerorientiertes Framework, das eine starke Architektur bereitstellt und Entwurfsmuster nutzt, die Entwicklern mit .NET-, Java- oder Webhintergrund vertraut sind.

Flex 2 besitzt ein Rich Component-Modell, das dem von Visual Basic, .NET und Java ähnelt. Diese Komponenten legen Eigenschaften offen, um deren Konfiguration zu ermöglichen, stellen Methoden zur Verfügung, die das Anstoßen Ihrer Funktionalität erlauben und lösen Ereignisse aus, wenn sich ihr Zustand ändert. Flex 2 bietet Standardmechanismen an, um diesen Komponenten Daten zur Verfügung zu stellen, ihr Aussehen anzupassen und ihr Layout zu verwalten.

Aber Flex stellt nicht nur die Architektur bereit. Es bietet auch eine Vielzahl nützlicher Komponenten an, damit Entwickler das Rad nicht jedes Mal neu erfinden müssen. Hierzu gehören unter anderem Buttons, Listen, Menüs, Slider, Reiter, Akkordeons und Data-Grids. Natürlich ist es einfach, eigene Komponenten von Grund auf neu zu entwickeln oder die vorhandenen Komponenten anzupassen.

In Flex programmiert man hauptsächlich über einen Mix aus ActionScript und einer XML-basierten Sprache namens MXML. Jedes Tag in MXML bildet eine Komponente ab, so dass man im Gegensatz zu HTML keinen festen Satz von Tags besitzt. Wenn Sie neue Komponenten schreiben, können Sie neue Tags verwenden. Die Eigenschaften einer Komponente werden zu den Attributen der Tags. MXML unterstützt außerdem Skriptblöcke, in die Sie ActionScript-Code zum Event-Handling oder Utility-Funktionen packen können.

Eine weitreichende Entscheidung von uns bestand darin, das Software Development Kit (SDK) frei zur Verfügung zu stellen. Es umfasst das Flex-Framework mit dem vollständigen Quellcode, den Compilern und anderen Utilities. Wir taten das, um die Akzeptanz zu erhöhen und die freie Verwendung mit Tools, die nicht von Adobe stammen, zu ermöglichen. Sie können es von der offiziellen Flex-Website (http://www.flex.org) herunterladen.

Flex Builder 2

Flex Builder 2 ist eine IDE, die den Einsatz des Flex-Frameworks noch produktiver macht. Es stellt eine großartige Umgebung bereit, in der Code für ActionScript und MXML bearbeitet werden kann, nämlich eine WYSIWYG-Designansicht, in der Sie Ihre Benutzerschnittstelle (UI) visuell aufbauen können, einen leistungsfähigen Debugger sowie ein Projektsystem, das die Kompilierung Ihrer Anwendung automatisiert.

Die Quelleditoren sind besonders nützlich, weil sie Ihnen dabei helfen, leichter korrekten Code zu schreiben, und Sie beim Erlernen des Framework-Objektmodells unterstützen. Wir haben sehr viel Zeit in die Codevervollständigung gesteckt, um sie immer auf dem neuesten Stand zu halten, und zwar unabhängig davon, ob es um Empfehlungen für fest eingebaute oder für von Ihnen selbst entwickelte Klassen geht.

Eine der Herausforderungen dabei ist die Tatsache, dass MXML und ActionScript grundsätzlich zwei verschiedene Sprachen sind, die die gleichen Objekte definieren und verwenden, so dass sich die Frage stellt, was zu tun ist, wenn die eine die andere beeinflusst. Zum Beispiel können Sie eine Klasse in ActionScript definieren und in MXML nutzen. Sobald Sie Änderungen an der Klassendefinition vornehmen, spiegeln sich diese in den Hinweisen (Hints) wider, die Ihnen bei der Bearbeitung von MXML-Code angeboten werden.

Weil wir aus dem Flex Builder ein Tool machen wollten, das Entwickler wirklich mögen, haben wir es, basierend auf dem Eclipse-Framework, in einer Reihe von Plug-ins realisiert. Eclipse ist ein weit verbreitetes Tools-Framework, das ursprünglich von IBM entwickelt worden war, aber seit Jahren Open Source ist. Es gibt eine große Community, die Erweiterungen entwickelt, und viele dieser Erweiterungen sind Open Source, frei verfügbar und können sehr einfach in Flex Builder 2 integriert werden. Sie können Flex Builder als eigenständiges Tool installieren oder als Reihe von Plug-ins in eine bestehende Eclipse-Installation einbinden.

ActionScript 3

Einer der wichtigsten Aspekte von Flex 2 ist die Tatsache, dass es vollständig in ActionScript 3 (das als Teil von Flash Player 9 eingeführt wurde) integriert ist. Beide Produkte wurden gleichzeitig ausgeliefert. ActionScript 3 ist aus einer Reihe von Gründen eine unglaublich wichtige neue Sprache.

ActionScript basierte schon immer auf EcmaScript (dem Standard, auf dem JavaScript basiert), war in der Vergangenheit aber nicht hundertprozentig gemäß der Spezifikation implementiert worden. Um den Standard und seinen Fortschritt besser zu unterstützen, wurde Macromedia im EcmaScript-Planungskommittee aktiv und machte ActionScript 100% kompatibel zur nächsten Major-Revision des Standards.

Sie werden feststellen, dass das nicht das JavaScript ist, das Sie von den heutigen Browsern kennen, sondern dass es sich um eine wesentlich modernere und robustere Sprache handelt. Tatsächlich erinnert sie mich mehr an C# oder Java, und ich glaube, dass sie von diesen Sprachen kommende Entwickler wirklich ansprechen wird. Ein Schlüssel-Merkmal das ich wirklich mag ist die Möglichkeit der starken Typisierung. Das führt zu nützlicheren Fehlermeldungen und ermöglicht es Ihnen, wesentlich korrekteren und zuverlässigeren Code zu produzieren.

Um eine robustere Ausführungsumgebung für ActionScript 3 zu schaffen, hat das Flash Player-Team eine neue virtuelle Maschine (VM) namens ActionScript Virtual Machine 2 (oder kurz AVM2) entwickelt. Diese wurde von Grund auf neu entwickelt, wobei das besondere Augenmerk auf Schnelligkeit und Skalierbarkeit lag. Sie enthält einen Just-in-Time-Compiler (JIT), der den ActionScript-3-Bytecode in maschineneigenen (nativen) Code umwandelt. In dieser Hinsicht ähnelt sie viel mehr einer Java VM oder der .NET CLR als den Script-Engines heutiger Browser. Das Ergebnis ist eine 10-fach schnellere Ausführung als bei der vorherigen VM, wobei gleichzeitig deutlich weniger Speicher benötigt wird. Die vorherige Version der VM, die jetzt AVM1 genannt wird, ist im Flash Player übrigens immer noch enthalten, um Rückwärtskompatibilität zu gewährleisten.

Wir haben die AVM2 jüngst zu Open Source erklärt und sie der Mozilla Foundation zur Einbindung in Firefox überlassen. Wir glauben, dass das die Annahme des neuen Standards beschleunigt und dabei hilft, die Kompatibilität mit zukünftigen JavaScript-Implementierungen sicherzustellen.

Flex Data Services

Die letzte Komponente von Flex 2 sind die Flex Data Services (FDS), die eine Weiterentwicklung des ursprünglichen Flex-Servers darstellen. FDS ist um unglaublich viele Features erweitert worden, um reichhaltigere, besser reagierende Anwendungen zu ermöglichen, z.B. Client/Server-Messaging, JMS-Integration, ein Rich Data Model- und Datensynchronisationsframework, Data-Paging und Proxy-Services.

Eines der faszinierendsten Features ist die Unterstützung von Messaging zwischen Client und Server in beide Richtungen. Das erlaubt es dem Server, Daten an den Client zu senden, ohne dass dieser nach Updates pollen muss. Das löst eines der Schlüsselprobleme beim Aufbau von Rich-Internet-Anwendungen für Echtzeitdatenausgaben, etwa für Finanzdienste.

Auch wenn FDS für den Aufbau einer Flex-Anwendung nicht immer notwendig ist, ist es doch extrem nützlich, wenn es benötigt wird. Um die Akzeptanz von FDS zu erhöhen, haben wir eine freie Express-Edition entwickelt, die die freie und zeitlich unbegrenzte kommerzielle Nutzung erlaubt. Die einzige Einschränkung besteht darin, dass die Anwendungen nicht geclustert oder über mehrere CPUs hinweg laufen können.

Ein weiterer Blick auf Flash

Nachdem ich bei Macromedia angefangen hatte, konnte ich einen weiteren Blick auf Flash werfen und mehr Zeit damit verbringen, in Flash zu programmieren. Das war wichtig, damit ich besser verstand, wie Flash-Entwickler heutzutage arbeiten. Mit der Zeit konnte ich einige der ursprünglich entdeckten Barrieren durchbrechen, und ich begann zu verstehen, wie die Flash-Abstraktionen mit denjenigen in Verbindung standen, die ich gewohnt war. Auf diese Weise habe ich irgendwann die Tatsache verinnerlicht, dass ein Movieclip nur eine weitere Art von Komponente ist.

Ich hatte auch die Gelegenheit, eine Reihe der weltbesten Flash-Entwickler kennen zu lernen, was wirklich großartig war, weil ich durch sie ja erst auf die Idee gekommen war, mich mit Flash zu beschäftigen. Das war auch die Zeit, zu der ich Chafic Kazoun und Joey Lott kennenlernte, also die Autoren, deren Buch Sie gerade in Händen halten.

Eine Sache, die ich sehr interessant fand, war, dass die heutigen Flash-Entwickler etwas anders sind als die in anderen Communities. Einige kamen mit einem kreativen Hintergrund zu Flash und begannen mit Flash zu programmieren, um ihre Arbeit zu verbessern. Andere kamen mit einem Programmiererhintergrund zu Flash, waren aber auch an ästhetischen Aspekten von Software interessiert. Wie auch immer sie dazu kamen, sie besaßen immer eine Mischung kreativer und technischer Fertigkeiten, die eher untypisch war für Entwickler.

Ich glaube, dass Flex das ändern wird, denn man braucht keine großartigen Designer-Fähigkeiten mehr, um etwas in Flash zu entwickeln, was fantastisch aussieht. Flex-Anwendungen sehen von Haus aus fantastisch aus.

Eine Sache, die mich sehr freut, ist der Enthusiasmus, mit dem Flex von Flash-Entwicklern angenommen wurde. Man hätte denken können, dass sie sich nicht für Flex interessieren, weil sie die für Flash notwendigen Fähigkeiten bereits besitzen, aber das Gegenteil ist der Fall. Tatsächlich habe ich in der letzten Zeit auf einigen Konferenzen gesprochen, und die anderen Flex-Redner waren meist Flash-Entwickler, die sich auf Flex eingeschossen hatten.

Als wir miteinander sprachen, erfuhr ich, dass sie produktiver sein können, wenn sie etwas entwickeln, was in das Flex-Paradigma passt. Sie glauben, dass die Architektur gut gelungen ist und umfassend die Dinge löst, die sie immer ad hoc lösen mussten. Sie mögen die Tatsache, dass der Flex Builder eine gute Umgebung zum Coden zur Verfügung stellt. Und natürlich gefällt ihnen, dass Flex und Flash zusammenarbeiten können, so dass sie beides ganz nach Bedarf einsetzen können. Flex ist nicht für jede Aufgabe die richtige Lösung, aber wenn es die richtige Lösung ist, sind sie davon so angetan wie jeder andere.

Programmieren in Flex 2

Was Frameworks wie Flex so großartig macht, sind die reichhaltige Architektur und die vielen vorgefertigten Softwarekomponenten, die eine wesentlich schnellere Softwareentwicklung ermöglichen, als wenn man alles selbst schreiben müsste. Und die besten Frameworks, zu denen auch Flex zählt, erlauben eine tiefgehende Anpassung und Erweiterung der bereitgestellten Funktionalität, so dass man in seiner Kreativität nicht eingeschränkt ist.

Mit all diesen Dingen geht aber auch ein gewisser Grad an Komplexität einher. Wir haben sehr große Anstrengungen unternommen, um sicherzustellen, dass alles so konsistent wie möglich ist, dass die richtigen Entwurfsmuster verwendet werden und dass die richtige Balance zwischen unkomplizierter Nutzung und Flexibilität herrscht – in dem Bemühen, die Sache so einfach wie möglich lernen und nutzen zu können. Es gibt nichts Besseres als ein gutes Buch, das Ihnen die Konzepte vermittelt, damit Sie wirklich verstehen, was passiert.

Was ich an Programmieren mit Flex 2 mag, ist, dass es Ihnen nicht nur den ganzen Umfang dessen zeigt, was Flex zu bieten hat, sondern dass es sie auch tiefer in dessen Funktionsweise einführt. Es zeigt die höher angesiedelten Konzepte ebenso wie die Details dessen, was tatsächlich passiert.

Ich mag das Buch außerdem, weil Programmieren mit Flex 2 einen praktischen Ansatz verfolgt, der gängige Techniken beschreibt, mit denen ActionScript-Programme üblicherweise arbeiten, und das in einer Weise, die über die Vorstellung der von Flex bereitgestellten Klassen hinausgeht.

Chafic Kazoun und Joey Lott sind die idealen Autoren, um diese Informationen zu präsentieren. Beide sind langjährige Flash-Entwickler, sind in der Flash-Szene wohlbekannt und zählen zur Elite der Flash-Entwickler. Beide nutzen Flex seit langer Zeit.

Ich denke, dass die Tiefe ihrer Flash-Erfahrung ein Teil dessen ist, was Programmieren mit Flex 2 so besonders macht. Ihre Beherrschung der Flash Player-API in Kombination mit ihrem umfassenden Wissen über Flex ermöglicht es ihnen nicht nur, Ihnen die von Flex bereitgestellten Features zu vermitteln, sie können das auch mit einem tiefen Verständnis für das gesamte System tun.

Ein Blick nach vorn

Als wir am 27. Juni 2006 mit der Auslieferung von Flex 2 begannen, waren gerade einmal etwas über 18 Monate Entwicklungszeit vergangen. Das war eine große Leistung, weil wir ein Tool von Grund auf neu entwickelt, das Framework in ActionScript 3 (das sich immer noch im Entwicklungszustand befand) neu geschrieben und das Ganze fristgerecht ausgeliefert haben.

Das war eine fantastische Zeit und wir hatten viel Spaß. Natürlich war das Größte, was dann passierte, der Kauf von Macromedia durch Adobe Systems. Zwar drückten einige Macromedia-Fans ihre Sorge aus, dass Adobe Flex nicht unterstützen würde, aber diese Stimmen hätten nicht falscher liegen können. Es war erstaunlich zu sehen, wie angetan die Adobe-Mitarbeiter von Flex waren und von der ganzen Technologie, die von den früheren Macromedia-Teams entwickelt worden war. Und im letzten Jahr seit der Übernahme wurde das durch das von uns Erreichte bestätigt.

Am 4. Januar 2007, nur sechs Monate nach der Auslieferung von Flex 2, haben wir Flex 2.0.1 veröffentlicht. Auch wenn das nur nach einem kleinen Update klingt, enthält es doch eine Reihe neuer Features und Verbesserungen. Ein Hauptpunkt war die Tatsache, dass wir in der Lage waren, Flex Builder 2 für den Mac auszuliefern, und zwar sowohl für PowerPC als auch für Intel.

Dem folgte am 16. Januar Flash Player 9 für Linux. Flex 2-Anwendungen verhalten sich jetzt unter Windows, Mac und Linux hinweg gleich.

Eine der wichtigsten Erweiterungen von Flex ist ein Projekt, das unmittelbar begonnen wurde, nachdem Adobe und Macromedia verschmolzen waren. Adobe AIR (ehemals Apollo) ist eine Technik, die Entwicklern den Aufbau von außerhalb des Browsers laufenden Desktop-Anwendungen mit den heute üblichen Webtechnologien wie Flex/Flash, HTML/AJAX und PDF ermöglicht.

Das bedeutet, dass Sie eine Flex-Anwendung entwickeln und unter Windows oder auf dem Mac (Linux folgt etwas später) installieren können, die sich dann wie jede andere Anwendung auf Ihrem System verhält. Unter Windows kann sie im Startmenü erscheinen und in der Taskleiste, und auf dem Mac erscheint sie im Dock. AIR wird zusätzliche APIs enthalten, die Ihnen eine Interaktion mit dem System ermöglichen, die aus dem Browser heraus nicht möglich ist. Zum Beispiel können Sie mehrere Fenster öffnen, Drag-and-Drop nutzen und direkt auf das Dateisystem zugreifen.

Außerdem können Sie HTML in Ihre Flex-Anwendung integrieren. Das bedeutet, dass Sie die HTML-Engine in Ihre Flex-Anwendung integrieren können, die den Safari-Browser des Mac antreibt.

Ich denke also, wir arbeiten an einer Reihe von Dingen, um Flex weiter voranzubringen. Dennoch bin ich sehr gespannt auf die Anwendungen, die Sie mit Flex 2 entwickeln werden. Viel Glück und viel Spaß beim Programmieren!

Mark Anders

Senior Principal Scientist, Adobe Systems Incorporated