Seit einiger Zeit ist nun die Beta von Flash Catalyst erschienen, dem neuen Tool von Adobe, welches die Brücke zwischen Kreation und Entwicklung bauen soll wenn es um Rich Internet Applications auf Basis von Adobe Flex geht.. Ziel soll sein, dass Designer in die Lage versetzt werden, Interaktivität in ihre Designs zu bringen, ohne dabei eine Zeile Programmcode schreiben zu müssen. Den Programmcode generiert Flash Catalyst nämlich selber. Es gibt eine Codeansicht in der Anwendung, die es einem erlaubt zu jeder Zeit in den aktuell zu generierenden Quellcode zu schauen.

Die Beta ist aktuell noch ziemlich lahm, wenn ich sie mit anderen Anwendungen auf meinem MBP vergleiche, aber es ist ja noch kein optimierter Code und Debugcode dürfte auch noch allenthalben enthalten sein. Dennoch kann man mit der Beta bereits gut arbeiten und auch Projekte damit erstellen, zumindest Testprojekte.

Flash Catalyst benötigt das Flex 4 SDK und am besten den Flashbuilder 4, die beide auch im Betastadium sind und Anfang 2010 final werden. Das erzeugte SWF basiert auf Flex 4 und benötigt zwingend den Flashplayer 10.

Flash Catalyst ist vom Produktmarketing her ein Tool für Designer, denn Ausgangsbasis sind idealerweise fertige Layouts und Designs in Adobe Photoshop oder Illustrator. Man erstellt einfach ein neues Catalyst Projekt auf der Basis eines Designs in einem der beiden Grafikformate und man hat ein bearbeitbares Projekt. Schnell werden Elemente aus Ebenen in interaktive Komponenten umgewandelt und bearbeitet. Man kommt so sehr schnell zu benutzbaren Click-Dummies und es macht einfach Spaß aus einer Grafik eine Anwendungen zusammen zu klicken.

Flash Catalyst kompiliert mittels Flex Gumbo aus einer solchen Projektdatei eine lauffähige Flexanwendung (SWF), die im Browser betrachtet und mit der interagiert werden kann. Soweit so gut, klingt erstmal nicht aufregend bis man es ausprobiert hat. Was Catalyst aber im Hintergrund leistet ist wirklich beeindruckend.

Aus der PSD / AI plus den Bearbeitungsschritten in Catalyst werden grafische Assets für die Flexanwendung erstellt, deren Informationen über die Ebenenstruktur gewonnen werden. Darüber hinaus wird Quellcode generiert, der dann im Flashbuilder 4 (oder einem anderen Editor) bearbeitet und wiederum kompiliert werden kann. Mit Flash Catalyst ist der Designer in der Lage der Entwicklung nicht nur Designs zu liefern, sondern bereits Interaktivität und Dummy-Daten. Dem Entwickler ist es dann überlassen, die echte Datenanbindung an ein Backend auszuprogrammieren und ggf. den generierten Quellcode aufzuräumen und zu optimieren. Aufgrund des Betastatus kann man noch nichts über die Qualität des generierten Quellcodes sagen, das wir sich erst mit der fertigen Version zeigen.

Die Arbeit mit Catalyst macht Spaß, und vor allem ist es interessant einmal den umgekehrten Weg zu beschreiten: Entwickelt man normalerweise anhand von Funktionalität und kümmert sich dann um Skinning etc., geht man hier sozusagen vom fertigen Skin hin zur Funktionalität. Mir als Entwickler war diese Zugangsweise erste fremd, sie ist aber durchaus interessant. Für den Designer umgekehrt dürfte es interessant sein, dass er auch Funktionalität gestalten kann, ein Weg, der ihm vorher versperrt war.

Ob Flash Catalyst der große Wurf wird, muss sich erst noch zeigen. Aber es weist sowohl für Entwickler als auch für Designer neue Perspektiven auf – ganz abgesehen davon, dass der Austausch der beiden Lager besser wird, sowohl hinsichtlich der Daten als auch der Kommunikation. Darüber hinaus ist Code- und Assetgenerierung ein sehr interessantes Feature, was Projekte deutlich beschleunigen kann.

Adobe lud zum ersten Mal die Usergroup Manager DACH der Flash Technology Platform zu sich nach Hamburg ein.

Es waren viele Flex UG Manager anwesend aber auch Vertreter von ColdFusion und Flashgruppen, sogar ein Vertreter der einzigen LiveCycle Usergruppe war da. Auch Vertreter aus der Schweiz und Österreich waren gekommen – Adobe übernahm großzügigerweise die Reisekosten.

Ziel war es, dass sich die UG Manager untereinander kennenlernten. Mir gefiel besonders, dass ich UG Manager wie Jens (Hamburg), Thomas (München) und Bettina (Berlin) auch einmal im Reallife treffen konnte – man kannte sich sonst nur oberflächlich über Netzwerke. Aber auch das Schliessen neuer Bekanntschaften war sehr positiv. Es war das erste mal in meinem Leben, dass in einem Raum mit weniger als 20 Leuten, neben mir ein zweiter Reto anwesend war – und das dann noch in Deutschland und nicht in der Schweiz…

Adobe berichtete über das Engagement für die Community, die Pläne für die Zukunft und stellte das Evangelistenteam vor. Der Austausch zwischen des Usergruppenvertretern und Adobe stand jedoch im Mittelpunkt. Es wurde offen besprochen was gut läuft und was verbessert werden sollte. Der konstruktive Austausch ging in ein sehr gelungen Abendprogramm über, bei dem dann weitere Diskussionen und Networking stattfand.

Insgesamt ein gelungener Tag und einen herzlichen Dank an Sven und Sabina, die alles organisiert und begleitet haben!

In letzter Zeit rückt die Webentwicklung (zumindest des Frontends) mit den typischen Web 2.0 Technologien wie standardkonformes HTML, CSS der neuesten Generation und Ajax / JavaScript immer mehr in meinen Blickwinkel. Das bedeutet nicht, dass in diesem Bereich tatsächlich mehr passiert als sonst, sondern kann auch lediglich bedeuten, dass mir das Augenfällige dann doch noch aufgefallen ist. Ich bin auch nicht mehr so der Frontendentwickler wie noch vor acht oder zehn Jahren und wenn dann eher in Adobe Flex.

Anyway, es tut sich was im Webbereich und gerade im Bereich der offenen Standards. Neue Technologien sprießen, Frameworks werden immer besser und leichter einzusetzen und Altbewährtem werden neue Aspekte abgewonnen. Wer wie ich schon etwas länger im Webapplication Developement dabei ist, kennt einen Teil der Bewegung, die jetzt aufgezogen ist unter dem Stichwort DHTML. Schon vor rund zehn Jahren war man durchaus in der Lage mittels JavaScript DOM Bäume zu manipulieren und einiges an Dynamik in statische Webseiten bringen. HTML und CSS aber auch JavaScript entwickelte sich fort und brachte immer neue Möglichkeiten.

Neu hinzugekommen (und an das ist das wirklich Neue) ist, dass man aus einer Webseite heraus, Daten nachladen kann, etwas, dass vorher nur proprietären Technologien wie Flash oder Applets möglich war. Ajax fand sich schnell als eingängiges Brand für asynchrone Requests die Daten mittels JSON oder XML von einem Backend holten und darstellten.

Mit Ajax kamen die Frameworks, die Animationen, völlig neue Widgets für HTML und Interaktivität auf Webseiten brachten und den Datenaustausch mit Backends vereinfachten. Mit ExtJS und bspw. jQuery UI stehen komponentenbasierte Frameworks zur Verfügung, die sonst eher im Bereich von Java und Flex zu suchen waren. Neue Browserversionen überbieten sich mit immer schnelleren JavaScript-Engines und ein Ende der Entwicklung ist noch nicht abzusehen.

Und ein Blick in die Glaskugel (wobei eigentlich schon alles bekannt ist) zeigt, dass mit Anwendungstypen wie Google Wave oder Google Docs, Calendar etc. der Browser als Applikationsträger immer wichtiger wird und das eigentliche Betriebssystem zurückgedrängt wird. Googles angekündigtes Betriebssystem Chrome OS scheint vorwiegend als Browserruntime zu dienen. HTML 5 und immer schnellere JavaScript Engines zeigen schon heute was mit Video und Animationen bis hin zum Raytracing im Browser möglich ist – von den neuen Gestaltungsmöglichkeiten mit CSS 3 ganz zu schweigen. Da wird selbst die Luft für Rich Internet Technologien wie Flash, JavaFX und Silverlight dünner.

Aber sollte die Zukunft der Anwendungsentwicklung wirklich in JavaScript liegen? Diese Sprache, die so unleserlich und unschön ist. die noch nicht einmal einen eigenständigen Namen von ihren Schöpfern bekam, sondern sich als Java Irgendwas bezeichnen lassen musste – ohne dabei irgendeine vorteilhafte Eigenschaft von Java zu haben? Ich will und kann es mir nicht recht vorstellen. Selbst wenn die Tools einmal ausgefeilter sind, wird es immer noch eine große Mühe sein, JavaScript zu entwickeln – und damit meine ich nicht nur das eine oder andere Framework zu benutzen, sondern richtig zu programmieren.

Gestandenen Anwendungsentwicklern ist noch nicht einmal ein einigermaßen ausgereiftes Framework wie Flex mit einer relativ elaborierten Sprache wie ActionScript 3 ausreichend, um komplexe Anwendungen zu schreiben. Wie soll das dann erst mit JavaScript vonstatten gehen, wenn wir mal den Umweg über Googles Web Toolkit beiseite lassen?

Auch wenn vieles danach aussieht als würden die Anwendungsoberflächen der Zukunft in JavaScript programmiert werden will es mir nicht wirklich in den Kopf. Trends und Hypes gehen und kommen im Internet schneller als sonst wo aber an den Grundfesten der Softwareentwicklung wird nicht so schnell gerüttelt, das braucht Zeit. Das Versprechen der Offenheit und Plattformunabhängigkeit der Webstandards ist da, aber das wird bspw. auch von Java gegeben. Und wenn sich Adobe entscheiden sollte den Flashplayer zu öffnen, wird wieder ein Konkurrent um die Technologie der Webanwendungen gleichberechtigte Ansprüche anmelden können.

Es ist verblüffend was heute mit Webstandards und Ajax möglich ist, aber das Entwicklungsmodell ist nicht überzeugend. Zu viele Einzeltechnologien mit Interdependenzen und kein so ausgereifter Toolsupport wie bspw. in Java, ganz zu schweigen von Browser-Inkompatibilitäten. Aber JavaScript als Entwicklungssprache muss nicht die Zukunft gehören. Über Google Wave, die vermutlich am weitestgehende Ajax Anwendung sagen die Entwickler selbst: Ohne das Google Web Toolkit (was Javacode in JavaScript/Ajax “kompiliert”), also direkt in JavaScript programmiert, wäre Google Wave nie möglich geworden.

Auf der Google Hausmesse Google I/O wurde eine Demo eines neuen Google Dienstes / einer neuen Anwendung gezeigt, die die Art und Weise wie wir elektronisch kommunizieren nachhaltig verändern könnte.

Google Wave vereint Email, Instant Messaging, (Micro-)Blogging, Collaborative Working und vieles andere mehr in einer Anwendung. Ein sog. Wave Objekt beinhaltet all diese Kommunikations- und Kollaborationsmöglichkeiten und ist das Zentrum der Anwendung. Folgt man der Demo kommt man aus dem Staunen nicht mehr raus. Neben der Integration von allen möglichen Diensten und der Verfügbarkeit einer API sind die Robots interessant, die einer Wave als Teilnehmer hinzugefügt werden können.

Wer Google Wave verstehen will, dem sei empfohlen sich 80 Minuten Zeit zu nehmen – es lohnt sich und man gewinnt einen Eindruck von der Zukunft der elektronischen Kommunikation. Die ganzen Möglichkeiten aufzuzählen ist kaum möglich, das muss man sich anschauen. Ergänzend ist dieses Interview mit Sergey Brin interessant sowie das Interview mit dem Kern des Google Wave Teams.

Eine kleine Kröte ist zu schlucken – das ist die Tatsache, dass die Anwendung auf HTML 5 aufsetzt. Google Wave wird dazu erst möglich, aber die Nutzer des Internet Explorers bleiben außen vor – Microsoft muss nun nachziehen.

Am Rande bemerkenswert ist die Tatsache, dass Google Wave als OpenSource verfügbar sein wird, der Dienst also nicht nur von Google sondern auch von anderen Unternehmen angeboten (und modifiziert) werden kann, sehr interessant. Weiterhin bemerkenswert ist, dass by Google nach der Devise “Eat your own dogfood” verfahren wird – der Client für Google Wave wurde komplett mit dem Google Web Toolkit erstellt.

Es ist noch nicht lange her, da erschien die Version 1.1 von JavaFX, der Rich Internet Application (RIA) Technologie von Sun Microsystems. Neben der neuen Laufzeitumgebung “mobile” waren hunderte von Bugfixes für die Desktopversion in dem Release enthalten – so kann man von einer jungen aber stabilen Technologie reden.

Sun bringt eine ganze Menge an Tutorials, Demos und Dokumentationen mit, so dass der Einstieg via der Projektseite leicht fällt. Die Sprache JavaFX Script ist leicht erlernbar und bringt viele Features und syntaktische Ausdrucksmöglichkeiten moderner Sprachen mit. JavaFX Script erinnert nicht unbedingt an Java, wenn auch ihre Kompilate in der Java Virtual Machine laufen.

Neben allem, was eine Programmiersprache so braucht ist eine besondere Eigenschaft von JavaFX Script, dass es eine Sprache ist, die von Grund auf designed wurde, um grafische Oberflächen zu programmieren. Dies erfolgt nicht via XML, wie etwa bei Flex oder Silverlight, sondern in dieser objektliteralen Notation, die ein wenig wie JSON aussieht. So lassen sich auch schnell die ersten Gehversuche in Sachen grafischer Programmierung unternehmen, was sehr leicht fällt, weil der Code vornehmlich deskriptiv ist und sich leicht “mit”lesen lässt.

Schnell findet man sich in die Systematik ein, wobei ich persönlich den Ansatz über XML sympathischer empfinde. Durch die nicht XML Syntax ist der Quellcode aber deutlich lichter und bei entsprechender Einrückung fast ebenso leicht zu lesen.

Selbst komplexeste Layouts sind mit JavaFX machbar. Wer dies bezweifelt, der erstelle mit Photoshop oder Illustrator eine entsprechend aufwändige Grafik und exportiere diese nach JavaFX. Der generierte Quellcode und das Resultat im JavaFX Viewer entsprechen der Vorlage 1:1.

Von der Programmierung von Grafiken und Oberflächen ist man weiter als die Konkurrenz von Adobe – ein Vorsprung, der nur durch zusätzliche Frameworks wie Degrafa oder dem neuen Flex 4 Gumbo kompensiert werden kann. Und selbst da scheint JavaFX Script ein Schnippchen vorne zu sein. Was bei JavaFX jedoch sehr negativ ist, dass es keine ausgereiften Komponenten, wie man sie etwa von Flex her kennt, gibt. Man kann zwar einige Swing Komponenten in die RIAs einbauen, jedoch sind diese Swing Komponenten nicht leicht skinbar und erweiterbar. Hier muss Sun spätestens in der Version 2 sehr deutlich nachlegen, sonst gerät JavaFX zu sehr ins Hintertreffen. Komponentenbasierte Frameworks wie Flex leben einfach von der Stärke ihrer Komponenten und die meisten GUI Entwickler aus der Javawelt, werden eben solche Komponenten in JavaFX vermissen.

Das Tooling mit der Production Suite (Photoshop- und Illustrator-Plugin samt JavaFX Viewer) ist gut gelungen. Die Exporte nach JavaFX entsprechen der Vorlage und sind leicht im Editor veränderbar. Mit dem Netbeans-Plugin wird auch der Programmierer zufrieden gestellt, bietet die IDE jedoch annehmbaren Komfort beim Programmieren. Von einer Unterstützung wie etwa für Java ist man jedoch noch Welten entfernt. Es gibt für Eclipse auch ein JavaFX-Plugin, was jedoch in der Entwicklung der Netbeansversion hinterher hinkt – hier bevorzugt Sun eindeutig die IDE aus dem eigenen Haus. Insgesamt ist das Tooling für eine 1.1 Version in Ordnung und es macht zuversichtlich für die Zukunft.

Summa summarum ist es kein großer aber ein gelungener Wurf, der Sun mit der Veröffentlichung von JavaFX geglückt ist. Man ist schnell in der Programmierung drinnen und die ersten Tools stellen geeignete Werkzeuge zur Verfügung. In Sachen Grafikprogrammierung ist JavaFX Script sehr mächtig und übertrifft die aktuelle Version von Flex in diesem Punkt deutlich. Jedoch macht es das Fehlen von leicht programmierbaren Komponenten fast unmöglich mit JavaFX RIAs zu entwickeln, die im Geschäftsumfeld anzusiedeln sind. Ein gewichtiger Punkt an dem Sun schnell nachbessern muss, um JavaFX den Durchbruch zu verschaffen. Solange sich da nichts ändert bleiben Swing/SWT die Mittel der Wahl um Geschäftsanwendungen im RIA-Space auf Basis von Javatechnologie zu entwickeln. Da kann das Versprechen von Sun, für eine Technologie zu entwickeln, die auf mobilen Geräten, PCs und Geräten wie Fernsehern läuft, auch nichts daran ändern.

Erinnert sich noch jemand an SVG, jenes XML Format des W3C um skalierbare Vektorgrafiken zu beschreiben? Natürlich, noch ist es nicht ganz vergessen und einige Browser unterstützen dieses Format auch. Jedoch, man sieht es selten in der freien Wildbahn und die Einsätze sind nicht gerade zahlreich wenn man mal von etwas exotischeren Programmen wie Inkscape absieht.

Dabei ist die Idee hinter SVG nicht schlecht, sie ist sogar so gut, dass sie heute im RIA-Bereich eine maßgebliche Rolle spielt, wenn auch nicht in der Gestalt von SVG, sondern in moderneren, teilweise proprietären Formaten. Die Idee hinter SVG ist eine Grafik so zu beschreiben, dass die Beschreibung (mittels XML) für Maschinen wie für Menschen gleichermaßen lesbar ist. Hinzu kommt, dass man die Grafiken verändern kann, indem man zur Laufzeit Änderungen an der Beschreibung vornimmt.

Ich will jetzt gar nicht drauf eingehen warum SVG nicht der Flashnachfolger geworden ist, wie es sich die Open Standards Fraktion erhoffte. Vielmehr ist es interessant, dass die Grundidee der deklarativen Grafikbeschreibung im RIA Umfeld mittlerweile eine große Rolle spielt.

Für Flex gibt es mit dem Degrafaprojekt einen Ansatz, Grafiken deklarativ zu beschreiben. Mit der Creative Suite 4 und im Vorgriff auf das kommende Flex 4 (Codename Gumbo) setzt Adobe aber selbst ein deklaratives Grafikformat ein: FXG. FXG erlaubt den leichten Austausch von Grafiken in Textform. Flex 4 kann FXG-Elemente zur Laufzeit transformieren und bietet so einen neuen völlig neuen Ansatz zur Echtzeit-Grafikmanipulation und Animation. Die Ähnlichkeit von SVG und FXG reicht über XML als gemeinsame Basis hinaus – die Gründe warum sich Adobe jedoch für eine eigene Sprache entschieden hat, werden hier dargelegt.

Auch Microsofts Silverlight kann mittels XAML auch Grafiken beschreiben dazu kann ich jedoch mangels Erfahrung nicht mehr schreiben – auch hier ist wieder XML der gemeinsame Nenner.

Selbst der Nachzügler im RIA-Bereich Suns JavaFX verfügt über eine Methode um grafische Assets zu beschreiben und somit austauschbar zu machen. JavaFX nennt diese Dateien FXD (reine Beschreibung eines Vektorassets) oder auch FXZ (komplettes Archiv von grafischen Assets). Die JavaFX Production Suite erlaubt es mittels Plugins Photoshop- und Illustrator-Dateien in FXD/FXZ Dateien zu exportieren und direkt in JavaFX zu einzusetzen und zu verändern. Analog des Sprachdesigns von JavaFX sind die die FXD Dateien kein XML sondern eher etwas JSON ähnliches, Sun spricht von objektliteral und entspricht JavaFX Script selbst. Ob sich der Alleingang von Sun auf XML zu verzichten durchsetzt wird die Zukunft zeigen. Der Vorteil vom XML ist die Verbreitung von Tools und Know-how darüber, bei JavaFX muss von Neuem begonnen werden.

Es ist interessant zu sehen, wie sich die relativ neue Technologie der Rich Internet Applications dem Thema der deklarativen Grafikbeschreibung erneut annimmt. Auf der anderen Seite ist es bedauerlich, dass dem offenen Standard SVG keine rechte Chance gegeben wurde, seine Stärken in dem neuen Kontext auszuspielen.

Es ist so ziemlich Common Sense unter den Flexern, dass es wesentlich einfacher ist einen Java-Entwickler mit Erfahrung in der GUI-Entwicklung auf Flex einzustimmen als einen eingefleischten Flasher. Diese Meinung teile ich und um so erfreulicher ist der hier vorgestellte Artikel, der Java-Entwicklern aus Java-Sicht die Sprache ActionScript 3 näher bringt und so einen wichtigen Beitrag dazu leistet, Flex-Entwickler zu gewinnen.

Der Autor Chet Haase kennt beide Welten sehr gut. Früher arbeitet er bei Sun in der Java Client Group und wurde mit dem Buch Filthy Rich Clients bekannt – heute hat die Lager gewechselt und entwickelt für Adobe am Flex SDK.

Seit vorletzten Freitag ist die Version 1.1 des JavaFX SDK von Sun erhältlich. Neben hunderten Bugfixes für die seit Dezember 2008 erhältliche Desktopversion von JavaFX steht nun erstmals ein offizielles Release für die mobile Version zur Verfügung.

Vergleicht man den jetzigen Ansatz des JavaFX mobile Releases mit den Ankündigungen, die noch auf der JavaOne 2008 getätigt wurden, so stellt man fest, dass sich Suns Strategie im mobilen Markt grundlegend gewandelt hat. Zur JavaOne 2008 wurde JavaFX Mobile noch als voller Stack für mobile Endgeräte herausgestellt. Sun unternahm in diesem Zusammenhang auch Akquisitionen, wie etwa die der Savage Technologie.

Mittlerweile ist man von der Idee eines weiteren mobilen Betriebssystems weit entfernt. Statt einfach ein weiterer me too Hersteller zu sein, versucht JavaFX mobile, das vollständig auf die Java ME aufsetzt, nun das verbindende Element in der Betriebssystem Heterogenität darzustellen – wohl auch zum Wohlgefallen der Hersteller von mobilen Endgeräten und den TelKo-Carriern.

Bei den vielen inkompatiblen Betriebssystemen ist die Java ME und das darauf aufsetzende JavaFX eine plattformübergreifende Technologie, die es Entwicklern ermöglicht auf eine möglichst breite Zahl von Endgeräten zu setzen. Das write once, run everywhere passt ein weiteres Mal auf die Java Technologie. Und mit JavaFX werden reichhaltige Oberflächen, die auf eine verbesserte User-Experience setzen wirklich, deren Codebasis im besten Fall nur einmal geschrieben werden muss: Im besten Fall skaliert eine Mobilanwendung auf eine Computeranwendung auf ein TV-Gerät, alles Dank JavaFX.

Wir müssen warten ob sich diese Marketingversprechen bewahrheiten, aber JavaFX (mobile) legt einen guten Start vor.