IKommHelp:P&E Programmierung
From Wiki
2. Planung und Entwurf
2.3. Programmierung
Contents |
1. Ablauf der Planungs- und Entwurfsphase
Die Aufgabe der Programmiergruppe bestand in der technischen Umsetzung der allgemein formulierten Ziele des Praxisprojekts.
Zu Anfang beschäftigten wir uns mit den Möglichkeiten multimediale Inhalte in Java einzubauen. Zuerst gingen wir davon aus, dass ein Video die benutzerfreundlichste Form der Hilfe für den Daffodil-Benutzer darstellen würde. Wir konzentrierten uns also auf die Einbettung von Videos in Java. Folgende Alternativen haben wir dabei herausgearbeitet:
Video in Java
Das JMF ist ein von Sun entwickeltes, relativ verbreitetes Framework um Mulitmedia in Java abzuspielen. Bei unseren Tests lieferte es allerdings auf unterschiedlichen Systemen leider sehr uneinheitliche Ergebnisse. Des weiteren ist es schon relativ alt und unterstützt keine modernen hochkomprimierenden Video-Codecs.
JVLC ist ein Projekt, das versucht, den populären Open-Source Media-Player VLC (VideoLAN Client) in Java einzubetten. Der Vorteil dieses Projekts wäre, einen wirklich modernen Media-Player mit Unterstützung der entsprechenden Codecs zu haben, allerdings befindet es sich in solch einem frühen Entwicklungsstatus, dass es für den Produktiveinsatz auf keinen Fall geeignet ist.
Quick Time for Java wird von Apple entwickelt. Es dient zum Abspielen von Multimediainhalten im QuickTime-Format, welches mittlerweile im Internet eine hohe Verbreitung findet. Insbesondere die einfache Streamingfähigkeit macht es zu einem idealen Format für die Videoübertragung in internetbasierenden Anwendungen. Diese Streamingfähigkeit ließ uns später auch zum QuickTime-Format zurückkehren. Leider unterstützt QuickTime for Java keine Unix/Linux basierenden Betriebssysteme und kam so für eine Anwendung in Daffodil nicht in Frage.
Die Einbindung von Videos mit den oben genannten Programmen erwies sich als problematisch und zeitaufwendig. Deswegen schauten wir uns nach Alternativen um und kamen dabei durch Überlegungen der gesamten Projektgruppe auf Flash. Also war es unsere nächste Aufgabe, nach Möglichkeiten zur Implementation von Flash in Java zu suchen:
Flash in Java
Die erste Alternative, die wir in Erwägung zogen, war der JFlashPlayer. Eine kommerzielle, ausgereifte Erweiterung in Java, die auf den ersten Blick einen guten Eindruck machte. Allerdings hätte man für ein "1 Developer License" 125$ bezahlen müssen und, was den Ausschlag dafür gab, sich gegen den JFlashPlayer zu entscheiden. Zudem ist er leider nur für Windows verfügbar.
Außerdem prüften wir das Open-Source-Projekt jflash.org auf seine Verwendbarkeit für unser Projekt. Allerdings befindet sich das Projekt derzeit noch im "developement status", z.B. unterstützt es erst die Flash-Features bis Version 3 und, zumindest zu diesem Zeitpunkt, "contribution ware" (man muss erst Code zum Projekt beisteuern bevor man es benutzen darf).
Als Fazit mussten wir leider erkennen, dass es derzeit keine ausgereifte bzw. plattformübergreifende Möglichkeit gibt, Flash in Java abzuspielen.
Statische Hilfe
Als Konsequenz aus den gemachten Erfahrungen wurde beschlossen sich auf eine rein statische Hilfe zu beschränken. Diese statische Hilfe sollte aus Texten und Screenshots für die einzelnen Tools bestehen und einfach zu benutzen sein.
Als Format für die Hilfe kamen wir auf HTML, da dieses relativ einfach, sehr verbreitet und mit relativ geringen Kenntnissen zu pflegen ist. Zur Darstellung von HTML in Java bietet sich die HTML-Pane-Klasse an, mit der wir daraufhin erste erfolgreiche Tests absolvierten. Die Frage die noch offen blieb, war, wo die HTML-Hilfe gespeichert werden und wie diese erstellt bzw. gepflegt werden sollte.
Als Alternativen hierfür diskutierten wir den HTML-Inhalt außerhalb des Programmes zu erstellen, in ein jar-Archiv zu packen und zusammen mit Daffodil auszuliefern. Oder den Inhalt in einer Datenbank (z.B. MySQL) zu speichern, den man dann über ein rudimentäres Webinterface pflegen könnte, welches wir beispielsweise mit PHP entwickelt hätten. Zuletzt entschieden wir uns dafür die Hilfe-Inhalte direkt in das bestehende Wiki des Informatik-Fachbereichs einzutragen und die Inhalt in Daffodil über einen Parser daraus auszulesen. So konnten wir die bereits bestehende Infrastruktur verwenden.
Die Nutzung des Wikis als Speicherort des Hilfecontents ersparte uns zudem die Entwicklung eines eigenen Administrationsinterfaces für den Content und gab uns so die Möglichkeit die freigewordenen Resourcen für weitere Tests der Videodarstellung zu verwenden.
Hierbei wandten wir uns wieder dem JMF zu, welches als einziges unseren Anforderungen entsprach (kostenlos, betriebssystemunabhängig, stabil). Nach zahlreichen Tests mit verschiedenen Videocodeces und -formaten haben wir es geschafft, ein Videofenster in die Daffodil-Anwendung einzubinden. Dieses sollte nun einen Film im QuickTime-Format anzeigen, der von einem Webserver als Stream empfangen wird.
2. Einführung in die Weiterentwicklung von Daffodil
Zeitgleich mit den Tests an der HTML-Pane und dem JMF machten wir unsere ersten Gehversuche mit der Programmierung in Daffodil. Diese endeten mit einem ersten Tool, welches einem Webbrowser gleich, Webseiten in einem Fenster innerhalb von Daffodil anzeigte. Bis dahin war es allerdings ein weiter Weg, zuerst mussten wir lernen wie Dateien aus dem CVS (Concurrent Versions System - System um die verschiedenen Versionen des Quelltextes zu speichern und zu verwalten. So haben alle Programmierer Zugriff auf die Quelltexte und können Änderungen der anderen nachverfolgen) ausgecheckt werden und wie eigene Änderungen den anderen Programmierern zugänglich gemacht werden. Als Entwicklungsumgebung wurde uns eclipse empfohlen. Wir konnten so unter einer Oberfläche mit dem Repository kommunizieren, neue Dateien programmieren und abschließend das ganze compilieren. Um nun unser erstes eigenes Tool programmieren zu können, mussten wir zuerst das Daffodil zugrunde liegende Model-View-Controller Konzept verstehen. Dieses ermöglichte es uns, die Darstellung (View) eines Tools von seinen eigentlichen Daten zu trennen (Modell). Die Kommunikation zwischen diesen beiden Bereichen übernimmt der Controller. Ein gegebenes "HelloWorldTool" zeigte uns diese Interaktion zwischen den verschiedenen Komponenten und gab uns einen ersten Einblick in den konkreten programmiertechnischen Aufbau von Daffodil.
Nachdem wir nun einen ersten Überblick über Daffodil hatten, konnten wir und mit den Prinzipien der Externalisierung vertraut machen. Hierbei werden alle für den User sichtbaren Textstellen im Programm, zentral an einer Stelle gesammelt. So ist es möglich für unterschiedliche Sprachen einfach unterschiedliche Dateien zu erstellen, die die jeweiligen Textstellen in der richtigen Sprache enthalten.
Zur Gesamtübersicht: Abschlussbericht Praxisprojekt IKommHelp Wintersemester 2005/2006 Gruppe 1
