Webapplikationen mit Adobe Flex, Microsoft.net und AMFPHP - I
Software as a Service ist in aller Munde. Doch welche Entwicklungsumgebungen soll man speziell bei browsergestützten Applikationen für das GUI verwenden? In dem zweiteiligen Beitrag werden zwei Praxisbeispiele für die Kombination von Adobe Flex mit Microsoft.net sowie für die Integration von Flex und AMFPHP vorgestellt. Die Ergebnisse können für Webapplikationen aller Art interessant sein.
Im ersten Teil wird der Schwerpunkt auf die Darstellung von Flex-spezifischen Fragestellungen gelegt:
Herausforderung
Immer öfter stellt sich für Softwarehersteller die Frage, wie eine Business-Applikation so umgesetzt werden kann, dass sie sowohl als browserbasierter Webservice sowie als Installer- bzw. Desktop-Variante angeboten werden kann.
Diese Fragestellung existierte auch bei "Apollo" – einem der Kernprodukte der Superwise AG , Wolfratshausen. Bei Apollo handelt es sich um eine hoch innovative, auf .NET basierte Suchmaschine, die dem menschlichen Gehirn nachempfunden ist. Mit Apollo lassen sich Text-Dokumente, Filme oder Bilder durchsuchen. Ende 2009 entstand der Entschluss, ein einheitliches RichClient-GUI zu entwickeln, das alle Möglichkeiten der Distribution offen lässt.
Bei der Findung der letztendlichen Lösung spielte ein zweites Projekt mit hinein: Zeitgleich wurde bei der Superwise AG die Projektsteuerungssoftware "Leonardo" überarbeitet. Diese Applikation war bereits vor einiger Zeit als RichClient-Lösung mit HTML/PHP/MySQL und AJAX umgesetzt worden. Die mit HTML/AJAX gesammelten Erfahrungen waren allerdings nicht immer zufriedenstellend. Insbesondere stellte sich die Browserkompatibilität sowie die einfache Anpassung an Kundenwünsche als Herausforderung dar.
Es galt daher, dem bisherigen HTML/AJAX-Ansatz Alternativen gegenüber zu stellen. Im Zusammenhang mit anspruchsvollen RichClient-Lösungen sind dies insbesondere Adobe Flex und Microsoft Silverlight. Um die Vor- und Nachteile der drei Lösungsvarianten strukturiert zu prüfen wurde vorab folgende Kriterienliste erstellt (übergreifend für beide Projekte):
* von 1 = wichtig bis 3 = sehr wichtig
** die Bewertung erfolgte auf Basis eigener Erfahrungswerte und Internet-Recherchen
*** diesbezügliche Erfahrungswerte fehlten im Vorfeld der Entscheidung bzw. die bisherigen eigenen Erfahrungen und Recherchen reichten aufgrund widersprüchlicher Ergebnisse nicht als Maßstab für die Entscheidung
Letztlich fiel die Entscheidung in beiden Projekten zu Gunsten von Flex/Flash. Daraus ergab sich folgende Matrix:
| Übersicht | ||
| Projektname: | "Apollo" | "Leonardo" |
| Anwendungsart: | Suchmaschine | Projektsoftware |
| Architektur: | Client/Server, Desktop, Mobile | Client/Server |
| Daten: | Textfiles, Bilder, Videos | MySQL-Datenbank |
| Frontend / GUI: | Adobe Flex / AIR | Adobe Flex |
| Middleware: | Flourine FX Aperture / .NET-DLL | AMF-PHP |
Hybridprojekte mit Flex/AIR
1. Flex/Flash
Beim Flex-Builder handelt es sich um eine auf Eclipse basierende Entwicklungsumgebung zur Erstellung von Flash-Files (swf-Format). Flex nutzt dabei die Scriptsprache Actionscript 3 (AS3). AS3 basierte swf können mit dem Flash-PlugIn ab Version 9 in nahezu jedem Browsertyp dargestellt werden. Die Verbreitung der Flash-PlugIns 9/10 liegt Anfang 2010 bei über 95%.
Mit Flex ist die effiziente Erstellung anspruchsvoller RichClient-Oberflächen möglich. Dafür verfügt Flex neben AS3 über die XML-basierte Layoutscriptsprache "mxml". Dabei handelt es sich um vereinfachtes AS3 mit XML-Logik (Nodes, Children, Attribute etc.). Durch die Vereinfachung lassen sich komplexe, in sich verschachtelte Applikationen mit hoher Frontend-Komplexität erstellen.
2. Flex vs. Silverlight
Das Microsoft-PlugIn "Silverlight" verfügt mit "xaml" über eine ähnliche Scriptsprache wie "mxml". Daher soll kurz darauf hingewiesen werden, dass der Ausschlag für Flex nicht in erster Linie aufgrund technischer Features erfolgte. Entscheidend war vielmehr der höhere Reifegrad von Flex sowie die größere Community, die viele praxisbewährte Code-Beispiele und umfänglichen Support ermöglicht. Da sich Flex auch im Hinblick auf die Integration mit Microsoft.net als geeignete Wahl erwies, fiel die Entscheidung in beiden Projekten zugunsten von Flex.
3. Adobe AIR
Während das Adobe Flash-PlugIn in erster Linie ein Addon für Browser darstellt, ist das Ergänzungsprodukt Adobe AIR die Brücke zur Entwicklung klassischer Desktop-Applikationen. Das PlugIn unterliegt allen browserspezifischen Sicherheitsrestriktionen: Das Öffnen und Speichern von lokalen Files, der Zugriff auf die Registry oder andere sicherheitsempfindliche Bereiche des Rechners sind strikt unterbunden. Will man also mit Flex jenseits der Browserbarrieren "echte" Applikationen erstellen, benötig man Adobe AIR. Die mit AIR erstellen Applikationen werden über eine Installationsroutine auf dem Rechner installiert. Mit AIR lassen sich auch plattformübergreifende Lösungen erstellen (PC und MAC).
Durch das Zusammenspiel von Adobe AIR und Flex/Flash lassen sich mit hoher Effizienz "Hybrid-Projekte" erstellen. Das sind Applikationen, die mit vielfach identischem Code einerseits über den Browser und andererseits als Standalone-Applikation ausgeführt werden. Damit aber für beide Varianten der gleiche Source-Code verwendet werden kann, empfiehlt es sich, die Architektur einer solchen Hybrid-Applikation vorab genau zu durchdenken.
4. Module und Komponenten
Bei Flex wird grundsätzlich zwischen Applikation, Modulen und Komponenten unterschieden.
Ein Flex-Projekt besteht im Regelfall aus einer Applikation und mehreren Modulen. Letztere sind wiederum in verschiedene Komponenten und/oder Klassen unterteilt. Relevanz hat diese Unterteilung für die Aufteilung in solche Elemente, die von beiden Varianten gemeinsam oder nur in einer der beiden Applikations-Varianten genutzt werden.
Die Unterteilung in Module und Komponenten ist auch für die Arbeitsteilung im Team von Relevanz. Diesbezüglich ist je nach Projektumfang und Größe des Teams die Verwendung eines zusätzlichen Frameworks wie PureMVC oder Carnigorm zu empfehlen.
Hohe Relevanz besitzt die Architektur von Flex-Projekten auch für das Ressourcen Management. Dieser Aspekt spielte sowohl bei Apollo als auch bei Leonardo eine wichtige Rolle. Ihm wird daher nachfolgend etwas mehr Aufmerksamkeit gewidmet.
5. Memory- und Cache Management
Mehr noch als bei AS2 basierten Flash-Code (bis Version 8) spielt bei Flex und AS3 (ähnlich bei JAVA Link) das Memory Management eine wichtige Rolle. Das heißt:
- Genutzter Speicher ist so klein wie möglich zu halten
- Nicht mehr genutzter Speicher muss rasch wieder frei gegeben werden
Da viele Flex-Programmierer ehemalige Flasher sind, müssen diese im Rahmen von Flex- Komponenten stärker als bisher beachten, dass Klassen und Komponenten weitgehend als Singleton erstellt bzw. mehrfach (wieder-)verwendet werden. Bei Apollo gilt diese Herausforderung insbesondere für die Visualisierung von Suchtreffern in Form von Relevanz-Auswertungen.
Apollo erlaubt unterschiedliche Suchtreffer-Auswertungen die z.B. als mehrfach verschachtelte Mindmap oder dynamisch generierte Balkendiagramme ausgegeben werden. Die dabei entstehenden Grafik-Elemente sind jeweils neue Instanzen z.T. recht komplexer Einzel-Komponenten. Die mehrfach aufeinander folgende Visualisierung von Suchtreffern kann bei schlechtem Memory-Management in Flex zu erheblichen Performance-Problemen führen.
Gerade bei Webapplikationen mit einer Vielzahl von Pop Up-Fenstern, großen Mengen von dynamisch erstellen Tabellen, Visualisierungen und anderen dynamisch erstellten Inhalten muss folglich bei Flex darauf geachtet werden, dass einmal erstellte und nicht mehr verwendete bzw. benötigte Instanzen restlos gelöscht bzw. zentrale Instanzen als Singleton erstellt und permanent wieder verwendet werden. Um das Memory-Management zu unterstützen, hat Flex extra einen Profiler integriert. Dieser hilft dabei, die Übersicht über die erstellten bzw. (nicht) gelöschten Instanzen und damit die Auslastung des Speichers zu behalten.
Flex Memory-Use bei größeren Applikationen
Erläuterung: links und rechts wurden Flex je 1000 Suchtreffer-Komponenten zur Laufzeit dynamisch zugefügt. Bei der Lösung auf der linken Seite wurden die nicht mehr verwendeten Objekte lediglich von der sichtbaren Oberfläche, nicht jedoch aus dem Speicher gelöscht. Die linke Applikation hat bereits nach kurzer Laufzeit erhebliche Performanceprobleme, da sämtliche Objekte noch geladen sind. Die rechte Variante hat dagegen trotz gleicher Gesamtmenge erstellter Instanzen nur 30 Instanzen im Speicher.
Es empfiehlt sich in jedem Fall, diesen kritischen Punkt bei Webapplikationen mit Flex und/oder AIR entsprechende Aufmerksamkeit zu widmen. Das heißt z.B. auch, dass die Bindung von Objekten in Arrays, ebenso wie die Verwendung von Event-Listenern genau geplant werden muss.
Flashpräsentation: Resource Management für ActionScript 3 (AS3) und Flex 2
Im zweiten Teil, der voraussichtlich in der KW 15 in unserem Magazin erscheint, geht es vornehmlich um das Zusammenspiel von Flex und DOT.net bzw. die Kombination von AMFPHP und Flex.
Kommentare
Bitte beachten Sie unsere Informationen zum Datenschutz.
blog comments powered by DisqusWeitere Artikel zum Thema
alle Artikel zum Thema
© 2012 FEiG & PARTNER