Techniken, mit denen man statt schlichter Webseiten ergonomische Internetanwendungen entwickeln kann, gibt es seit Längerem. Jetzt führt der Weg zurück auf den Desktop. Adobes Apollo - neuerdings AIR - soll Rich Internet Applications aus der Enge des Webbrowsers befreien.
Zumindest unter Fachleuten sind Rich Clients - wie das viel beschworene Buzzword „Web 2.0“ - in aller Munde. Es scheint, als fühle sich jeder Anbieter dazu berufen, einen Web-2.0- beziehungsweise Mashup-fähigen Ableger der Plattform X, Y oder Z bereitzustellen. Microsoft führt dazu Silverlight ins Feld, das Unternehmen Sun hat unlängst JavaFX Script angekündigt, und seitens Adobe erhielt das gute, alte Flash-Format .swf eine enorme Aufwertung mit der Bereitstellung von Flex 2 im Juni des letzten Jahres. Die Flex-Plattform ermöglicht Entwicklern erstmals ernsthafte Applikationsentwicklung mit der Zielplattform Flash Player 9.
Neben Flex 2 hat Adobe in den letzten Monaten verstärkt für ein weiteres, neues Konzept mit dem Codenamen „Apollo“ geworben. Dabei soll es sich um eine Desktop-Laufzeitumgebung für Webapplikationen handeln. Als zukünftige Entwicklungssprachen für Apollo nennt der Hersteller Flash, Flex, HTML/Ajax sowie PDF. Ende März erblickte die erste Apollo-Version das Licht der Welt und stand seitdem als öffentliche Alpha-Release auf Adobe Labs. Kurz vor Redaktionsschluss veröffentlichte der Hersteller nicht nur die erste Beta-Release, sondern gab auch bekannt, dass die Software künftig den Namen Adobe Integrated Runtime, kurz AIR, trägt (siehe „Onlineressourcen“). Neu in der Beta-Release sind unter anderem eine eingebettete SQLite-Engine zur Speicherung lokaler Daten und die Unterstützung von PDF.
Die Grundidee ist einfach: Rich Internet Applications (RIAs) sind im Trend und werden zunehmend in verschiedenen Umgebungen akzeptiert - vom Surfer im Web bis hin zum Business-Nutzer in Intranet-Umgebungen. Schließlich bieten sie anders als statische HTML-Seiten den vom Desktop gewohnten Komfort. Während in den letzten Jahren verschiedene Techniken entstanden sind, um Webanwendungen mit einer ergonomischen Benutzerschnittstelle zu versehen (Web 2.0), geht Adobe mit Apollo jetzt den umgekehrten Weg. Nicht für jede mit Javascript oder Flex entwickelte Anwendung ist es sinnvoll, in einer Browser-Umgebung mit all ihren Eigenheiten zu laufen.
Einer der offensichtlichen Stolpersteine ist die Behandlung der Navigations-Buttons des Browsers. Als Beispiel sei das Löschen einer E-Mail in einem webbasierten Mail-Client angeführt. In diesem Kontext soll ein Klick auf den Zurück-Button des Browsers sicherlich nicht das Löschen der E-Mail rückgängig machen - aber was erwartet ein durchschnittlich begabter Benutzer an dieser Stelle? Im besten Fall landet er in seiner Inbox oder in dem Folder, in dem er vor dem Löschen gearbeitet hat. In der Vielzahl der Fälle initiiert der Zurück-Button allerdings nur den Rücksprung zur letzten Seite in der Browser-History (hier vielleicht des Bestätigungsformulars zum Löschen der E-Mail).
Es finden sich leicht weitere Beispiele, die ersichtlich machen, dass grundlegende Konzepte von Webbrowsern nicht unbedingt mit den Kontexten vieler Applikationen harmonieren. Letztlich verwundert das nicht, waren Webbrowser doch ursprünglich für nichts anderes konzipiert, als miteinander verlinkte Dokumente darzustellen. Der Schritt weg vom Browser und hin zu einer Applikationsumgebung für Rich-Internet-Anwendungen scheint also nahe liegend zu sein.
Adobes Apollo ist bei Weitem nicht die einzige Plattform, die versucht, sich in diesem Marktsegment zu etablieren. Bekannte Wettbewerber hinsichtlich des Deployments auf den Desktop sind im weitesten Sinne beispielsweise Java Web Start oder .Net Click Once. Einer der Hauptunterschiede zwischen Apollo und den Mitbewerbern ist jedoch, dass das .swf-Format nur eine von verschiedenen Möglichkeiten darstellt, Apollo-Applikationen zu entwickeln und zu installieren. Apollo unterstützt HTML, Javascript und Ajax, wohingegen Web Start beziehungsweise Click Once jeweils nur einen vereinfachten Deployment- und Installationsmechanismus für die jeweilige Sprache respektive Plattform bieten. Bedenkt man weiterhin die große Reichweite der Flash-Plattform und den hohe Verbreitungsgrad des Flash-Players, sprechen allein diese Argumente für einen Erfolg von Apollo.
Weitere Aspekte heutiger RIAs sind ihre relativ starke Kapselung in den Browser sowie ihre buchstäbliche Entfernung vom Desktop. So ist es in der Regel nicht möglich, eine Datei via Drag & Drop in eine Webanwendung zu ziehen, analog kann die Webanwendung im Browser (aus gutem Grund) meist nicht auf das Dateisystem des Rechners ihres Benutzers zugreifen.
Alle im Weiteren getroffenen Aussagen zu Adobes Apollo beziehen sich auf die am 19. März veröffentlichte Alpha-Version von Adobe Labs; die im Rahmen dieses Artikels durchgeführten Tests und Experimente erfolgten unter Windows XP Professional.
Die verfügbare Alpha-Version ist zurzeit noch deutlich von der Fertigstellung entfernt, daher enthält sie bei Weitem nicht alle APIs, die Adobe mit der finalen Release 1.0 ausliefern will. So zielt die Alpha-Version auf Flash- beziehungsweise Flex-Entwickler und macht hinsichtlich der gesamten Flash-Plattform einen relativ reifen Eindruck. Javascript- und HTML-Entwickler erhalten einen Vorgeschmack, sind aber in ihren Möglichkeiten noch etwas limitiert und werden erst mit der nächsten Release eine deutlich bessere Unterstützung erhalten; die aktuelle Beta-Version soll bereits verbesserte Funktionen für Javascript-Entwickler enthaltn. Als Release-Termin nennt der Hersteller die zweite Jahreshälfte 2007, was vermuten lässt, dass vor der finalen Version noch Beta-Zyklen ins Land gehen werden.
Die Bestandsaufnahme der Funktionen der Alpha 1 bringt die folgenden Listen ans Tageslicht. Für die Runtime:
Für die Release 1.0 geplant sind neben einem vollständigen Support für HTML-Anwendungen die Unterstützung von Kontextmenüs, APIs für die lokale Speicherung von Daten und für Offline-Applikationen, Drag & Drop, Zugriff auf die Zwischenablage, eine API für Systembenachrichtigungen und mehr. Bei näherer Betrachtung der beiden in dieser Release verfügbaren Anwendungstechniken stellt man fest, dass Apollo weder neue Sprachen einführt, noch existierende Plattformen modifiziert.
Grundlage des Flash-Zweigs ist der Flash Player 9 und somit Actionscript 3 (siehe dazu den Artikel auf Seite 66 in der Druckausgabe). Der Vorteil dieser Einbettung ist, dass alle existierenden APIs (sowie einige erweiterte beziehungsweise neue Schnittstellen) des Flash Player auch in Apollo Einzug halten. Der HTML-Zweig stellt eine Engine für das Rendering der Hypertext Markup Language bereit, die neben HTML Javascript, CSS, XHTML, DOM et cetera unterstützt. Adobe hat sich für WebKit entschieden, eine Open Source HTML-Engine, die als Kern verschiedener Browser dient. Unter anderem basiert Safari darauf.
Der Hauptgrund für diese Wahl dürfte in der Kompaktheit der Engine liegen, denn Adobe hat als Zielgröße für die finale Version der Apollo-Laufzeitumgebung 5 bis 9 MByte genannt. Zurzeit liegt die Download-Größe knapp über der Untergrenze - zieht man in Betracht, dass darin der Flash Player 9 und WebKit bereits enthalten sind, lässt sich damit gut leben. Es stellt sich allerdings die Frage, welchen Einfluss eine spätere Erweiterung der Apollo-Laufzeitumgebung um .pdf-Features haben wird - der Acrobat Reader ist nicht gerade als kleiner und kompakter Download bekannt. Vorstellbar sind hier Szenarien, die die Features eines bereits auf dem Client installierten Acrobat Reader in Apollo-Anwendungen einbetten.
Die Integration der beiden Zweige - HTML und Flash - findet in der Tiefe der Apollo-Runtime statt und ist noch nicht in allen Details dokumentiert. Von besonderem Interesse ist die genaue Zusammenarbeit jedoch, wenn es um die Erstellung von Apollo-Anwendungen geht, die auf der Kombinationen beider Zweige basieren, also Flash-basierte Applikationen mit HTML-Inhalten oder HTML/JS/Ajax-basierte Applikationen mit Flash-Inhalten. Eigene Experimente und Demo-Anwendungen zeigen, dass HTML-Inhalte innerhalb von Flash anscheinend direkt über den Flash Player ausgegeben werden, da es beispielsweise möglich ist, visuelle Flash-Effekte auf HTML-Inhalte anzuwenden. Würde die HTML-Ausgabe hier allein durch die WebKit-Engine gesteuert, ließen sich solche Ergebnisse nicht erzielen.
Aber auch auf (Skript-)Sprachenebene sind beide Zweige integriert, im Adobe-Jargon realisiert durch eine „Bridge“ zwischen Javascript und Actionscript. Diese Brücke ist nicht neu, sondern existiert seit einiger Zeit als „Flex-Ajax Bridge“ auf Adobe Labs. Apollo nutzt deren Funktionen, um mit Javascript- respektive Actionscript-Code auf die APIs der jeweils anderen Seite zuzugreifen. Darüber hinaus kann Actionscript auf das DOM im HTML-Part der Anwendung zugreifen und es manipulieren.
Der Einstieg in Entwicklung und Deployment von Apollo-Anwendungen ist einfach. Zunächst benötigt man die Laufzeitumgebung (die für Windows als .msi-Datei vorliegt) sowie das SDK. Benutzer von Flex Builder sollten zusätzlich die Apollo-Erweiterungen für Flex Builder 2.0.1 installieren. Das SDK bietet neben Klassenbibliotheken und Dokumentation vor allem zwei wichtige Tools: ADL und ADT.
ADL ist ein Launch-Programm für Apollo-Anwendungen, das es Entwicklern erlaubt, Applikationen zu testen, ohne diese in die Laufzeitumgebung installieren zu müssen. Mit ADT kann der Anwender den Sourcecode in das Paketformat für die Apollo-Runtime wandeln, das die Endung .air hat.
Der Entwicklungs- und Installationsprozess einer Apollo-Anwendung besteht im Wesentlichen aus vier Schritten:
Es sei angemerkt, dass diese vier Schritte den Prozess hochgradig abstrahiert darstellen und keineswegs einen konkreten Softwareentwicklungsprozess beschreiben sollen. Bei der praktischen Umsetzung trennen sich der HTML- und der Flash-Zweig, denn Flex-Entwickler erzeugen jetzt ein neues Apollo-Projekt in Flex Builder, wohingegen diejenigen, deren Ziel eine HTML-/JS-basierte Anwendung ist, zunächst noch auf Handarbeit angewiesen sind.
Der Apollo-Projekt-Wizard in Flex Builder erfragt beispielsweise während der Erstellung des Projekts die nötigen Parameter für application.xml: neben dem Namen und der Beschreibung der Anwendung eine Applikations-ID sowie Informationen zu Copyright, Publisher et cetera. Die ID hat in dieser Release die Aufgabe, eine Applikation in der Runtime-Umgebung eindeutig zu identifizieren, also dafür zu sorgen, dass sie nur einmal installiert ist. Dieses Modell wird in künftigen Versionen um detailliertere Mechanismen zur Aktualisierung erweitert werden. Listing 1 zeigt eine beispielhafte application.xml-Datei.
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://ns.adobe.com/apollo/application/1.0.M3"
appId="nz.co.ventego.apollo.ixdemo.HelloWorld" version="1.0">
<properties>
<name>HelloWorld for iX</name>
<publisher>Kai Koenig</publisher>
<description>A sample and simple Apollo alpha1 application</description>
<copyright>2007</copyright>
</properties>
<rootContent systemChrome="standard" transparent="false" visible="true"
width="600" height="800">HelloWord.swf</rootContent>
<icon>
<image16x16>icons/ApolloApp_16.png</image16x16>
<image32x32>icons/ApolloApp_32.png</image32x32>
<image48x48>icons/ApolloApp_48.png</image48x48>
<image128x128>icons/ApolloApp_128.png</image128x128>
</icon>
</application>
In der application.xml spezifiziert der Entwickler unter anderem den Namen und die ID einer Apollo-Anwendung.
Die im Wizard abgefragten Parameter decken sich mit dem appId-Attribut des -Start-Tag sowie der -Sektion. Der Bereich definiert schlichtweg Desktop-Icons für die installierte Applikation und das -Element beinhaltet genau das, was sein Name vermuten lässt - den zentralen und im Apollo-Archive zu verpackenden Inhalt. Im Fall einer Flash- oder Flex-Anwendung handelt es sich dabei in der Regel um eine SWF-, bei einer HTML-/JS-Anwendung um eine HTML-Datei.
Zurück in Flex Builder funktioniert die Entwicklung einer Flex-Anwendung für die Apollo-Runtime prinzipiell genauso wie die einer Anwendung mit dem Deployment-Ziel Flash Player 9 in einem Browser. Der einzige offenkundige Unterschied ist die Verwendung des MXML-Tag-Paars
<mx:ApolloApplication ... >
...
</mx:ApolloApplication>
als Root-Tag der Flex-Anwendung (anstelle von ). Somit ist die Konvertierung einer bestehenden Flex-Anwendung in eine für Apollo nutzbare denkbar einfach. Diese Vorgehensweise eröffnet jedoch dem Entwickler keine der neuen APIs in Apollo.
Nutzt man das Apollo-SDK anstelle von Flex Builder, ist die Vorgehensweise analog - application.xml sowie eine HelloWorld.mxml-Datei muss man jedoch von Hand erstellen. Danach muss der Entwickler Letztere zunächst mit amxmlc kompilieren (amxmlc ist ein modifizierter MXML-Kommandozeilen-Compiler, der automatisch die Apollo-Klassenbibliothek benutzt); danach lässt sich die Apollo-Anwendung ohne vorherige Installation mit ADL testen (Eingabeparameter ist die application.xml-Datei). Der Flex Builder beherrscht das Erzeugen von .air-Dateien über das Export-Menü, SDK-Nutzer arbeiten mit ADT.
Als erstes Beispiel für die Nutzung der erweiterten Apollo-APIs soll die Einbindung von HTML in einer Flash-/Flex-basierten Applikation dienen (Listing 2).
<?xml version="1.0" encoding="utf-8"?>
<mx:ApolloApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical">
<mx:TextInput id="urlTxt" width="100%" enter="html.location=urlTxt.text;"
text="http://www.heise.de" />
<mx:HTML id="html" width="100%" height="100%" location="http://www.heise.de" />
</mx:ApolloApplication>
Über die erweiterten Apollo-APIs können Flash-Applikationen HTML-Komponenten nutzen.
Diese Mini-Anwendung besteht aus einem Texteingabefeld und einer HTML-Komponente: Trägt der Benutzer eine URL in das Eingabefeld ein, fängt der enter-Eventhandler diese Eingabe ab und weist die HTML-Komponente an, die URL zu laden. Die HTML-Komponente erbt von DisplayObject und kann daher wie jedes andere Display-Objekt mit Flash-Hilfsmitteln wie visuellen Effekten manipuliert werden.
Ein anderes Beispiel für eine der erweiterten APIs in Apollo ist das File I/O. Darunter ist zu verstehen, dass eine Apollo-Applikation auf dem Dateisystem des Clients Operationen wie Erzeugen, Löschen, Bewegen von Dateien und Ordnern vornimmt. Dabei muss man sich vergegenwärtigen, dass Apollo-Anwendungen nicht dem Sicherheitsmodell von Browser-Applikationen unterworfen sind, sondern auf dem Client des Benutzers im Prinzip mit dessen Rechten ausgeführt werden. Die finale Release von Apollo soll daher ein Zertifikat-basiertes Sicherheitsmodell beinhalten, das zurzeit noch nicht im Detail spezifiziert ist.
Listing 3 zeigt einige Zeilen Actionscript-Code, die den Inhalt des Desktop-Verzeichnisses des Benutzers einlesen. File.desktopDirectory ist hierbei eine Referenz auf den Desktop des Benutzers, die die Apollo-Runtime jeweils in Übereinstimmung mit dem zugrunde liegenden Betriebssystem verwaltet.
var directory:File = File.desktopDirectory;
var contents:Array = directory.listDirectory();
for (var i:int = 0; i < contents.length; i++) {
if (contents[i].isDirectory) {
trace(contents[i].name);
} else {
trace(contents[i].name,contents[i].size,"bytes");
}
}
Über die Referenz File.desktopDirectory hat die Apollo-Applikation Zugriff auf den Inhalt eines Desktop-Verzeichnisses.
Wer Geschmack an Apollo gefunden hat, sollte einen Blick auf die Beispielanwendungen werfen (siehe „Onlineressourcen“). Besonders empfehlenswert sind Fresh und Maptacular sowie Ascension, ein Apollo-basierter MP3-Player, der die lokale iTunes-Library nutzt.
Zusammenfassend kann man sagen, dass Apollo-Programme Desktop-Applikationen sind. Es ist jedoch wichtig, zu unterscheiden, was sinnvolle Anwendungsfelder sind und in welchen Fällen Apollo nicht das geeignete Werkzeug ist. Die Software ist als Desktop-Laufzeitumgebung für Rich-Internet-Applikationen auf dem Desktop zu verstehen. Gegenwärtig - und aller Wahrscheinlichkeit nach auch zukünftig - wird man nicht die nächste Version von Adobes Photoshop in Apollo erwarten dürfen. Bedenkt man allerdings den Trend zu Anwendungen in Internet (Mail, Text- und Spreadsheet-Tools et cetera), bietet die Runtime ein großes Bestätigungsfeld für Pioniere auf diesem Gebiet.
All das garantiert noch keinen Erfolg oder gar Siegeszug für Apollo, aber Adobe hat der Rakete offenkundig gute Voraussetzungen und eine starke Community mit auf den Weg gegeben.
Kai König
lebt in seiner Wahlheimat Wellington, Neuseeland, und arbeitet dort als Software Solutions Architect für Ventego Creative Ltd.
Dieser Text ist der Zeitschriften-Ausgabe 07/2007 von iX entnommen.
iOS, Android, Windows Phone 7 und HTML5 - das neue Sonderheft von heise Developer führt Einsteiger und Profis in die Programmierung mobiler Geräte ein.
