4. Konzept
Das im Projekt entworfene Konzept des Frameworks wird in Kapitel4.1 erläutert. In Kapitel 4.2werden die einzelnen Aufgabengebiete des Autors beschrieben.
4.1. Framework
Abbildung1zeigt den Aufbau des Frameworks und die darum liegende Struktur. Zu sehen sind 3 Schichten.
In der ersten Schicht (violett gefärbte Kästen) sind diekonkreten Anwendungenzu sehen. In diesen werden die von dem Framework vorgegebenen Schnittstellen verwendet und imple-mentiert. Die Konfiguration dieser einzelnen Klassen wird in einer XML-Datei vorgenommen, die für dieses Projekt den Namen spine.xml erhielt. Der Anwendungsentwickler legt in ihr den Zusammenhang der Klassen und die Verantwortlichkeiten fest.
Abbildung 1: Übersicht des Frameworks
4. Konzept 11
Die zweite Schicht stellt dasFrameworkdar (grün gefärbte Kästen). Es setzt sich wiederum aus zwei Schichten und weiteren Komponenten zusammen.
Als Oberste ist dieApplikationsschicht zu sehen. Darin enthalten ist die Komponente für die Trennung von Anwendungslogik und Darstellung. Die Umsetzung ist orientiert sich an dem MVC Pattern7.
Die zweite Komponente ist verantwortlich für die Konfiguration und Handhabung der Events.
Zur Konfiguration entnimmt sie ebenfalls Informationen aus der oben beschriebenen XML-Datei. Sie verwaltet die aktiven Events und führt bei deren Auftreten die festgelegte Funktio-nalität der Anwendung aus. Weiterhin besitzt sie eine Schnittstelle, um aus der Anwendung heraus nachträglich Events manuell registrieren zu können.
Unter der Applikationsschicht wird dieAbstraktionsschicht für die Hardware dargestellt. Sie abstrahiert die vorhandene Hardware durch Schnittstellen, die so ihre Dienste anbieten. Die-se sind so angelegt, dass sie nicht direkt die Technik darunter widerspiegeln, sondern ihre Funktionalität. Das heißt, für den Location-Service z.B. ist es nebensächlich, ob er die Posi-tion über GPS oder W-LAN TriangulaPosi-tion erhält.
Neben diesen zwei Schichten gibt es noch die KomponentenConfigurationundUtilities.
Utilities beinhaltet zusätzliche Funktionalitäten. Dort findet man u.a. das Logging, welches sich an Log4J orientiert. Es ist möglich Logging-Informationen auf dem Desktop-Rechner zu sehen, aber auch auf dem mobilen Gerät. Sie enthalten ebenso die grundlegenden Klassen für den XML-Parser, der die XML-Datei zur Konfiguration der Anwendung analysiert.
Configuration ermöglicht es, Konfigurationsparameter in eine externe Properties-Datei aus-zulagern, sodass diese auf einfache Weise geändert werden können, ohne einen Eingriff in die Anwendung vornehmen zu müssen. Beispielsweise kann darüber das Logging auf dem mobilen Gerät aktiviert werden.
Die unterste Schicht stellt die konkrete Hardware dar (blau gefärbte Kästen), die vom mobilen Gerät zur Verfügung gestellt wird. Je nach Gerät können diese variieren.
Mit Abbildung 2 soll grob veranschaulicht werden, wie sich der Zusammenhang zwischen den konkreten Anwendungen und der Applikationsschicht verhält. Die Applikationsschicht hält in den einzelnen Komponenten Interfaces bereit, die in der Anwendung fest implemen-tiert werden.
Auf der einen Seite ist die MVC Komponente zu sehen. Darin ist verdeutlicht, wie die Dar-stellung von der Anwendungslogik getrennt ist. Für die Anzeige auf dem mobilen Gerät sind dieViewsverantwortlich. Grundlegend implementiert man für jede neue Seite eine View in der Anwendung.
Die Anwendungslogik wird in den Actionsimplementiert. In der Konfiguration kann definiert werden, ob nachdem Ausführen einer Action eine weitere Action-Klasse oder eine View
auf-7Model View Controller Pattern nach [3].
4. Konzept 12
gerufen wird.
In denEventActionswird festgelegt, welche Aktion ausgeführt werden soll, wenn ein gewis-ser Event aufgetreten ist. Das kann z.B. sein, wenn der Spieler einen bestimmten vordefi-nierten Ort erreicht hat und dies per Location-Service erkannt wird.
Abbildung 2: Übersicht Anwendung und Applikationsschicht
4.2. Realisierung
Hier werden kurz die einzelnen Aufgaben des Autors dargestellt. Für die Entwicklung hat sich das Projektteam auf die Programmiersprache Java geeinigt. Nach Überlegungen, wel-che Sprawel-che denn am sinnvollsten wäre, ist man zur Entswel-cheidung gekommen, dass Java aus Kompatibilitätssicht am geeignetsten ist und auch die heutigen Spielehersteller darauf setzen. Die Problematik bei Java ist, das die Java API’s8 von jedem Hersteller unterschied-lich implementiert und unterstützt werden. Es gibt jedoch schon Bemühungen, die die API’s auf den verschiedenen Geräten mehr und mehr standardisieren (Stichwort Umbrella JSR9).
Zum Ende des Projektes gab es sogar die Nachricht, dass wegen der steigenden Leistungs-fähigkeit der neuen mobilen Geräte in weiterer Zukunft die J2ME10sogar ganz in die JSE11 eingebunden werden soll.
8Engl. für Application Programming Interface, deutsch: Schnittstelle zur Anwendungsprogrammierung
9Java Specification Request
10Java Micro Edition. Entwickelt für „embedded-“ und mobile Geräte.
11Java Standard Edition
4. Konzept 13
4.2.1. XML-Parser
Wie im vorherigen Abschnitt4.1bereits erwähnt, wird zur Konfiguration der Anwendung ei-ne XML-Datei verwendet. Darin definiert der Entwickler den Zusammenhang und die Ver-antwortlichkeiten der einzelnen Klassen. Ein Beispiel für die XML-Datei findet man in An-hangA.1. Weiterführende Informationen zum Aufbau sind in der Ausarbeitung von Jan-Peter Tutzschke zu finden [9].
Der XML-Parser ist für das Auslesen der XML zuständig. Bei jedem Start der Anwendung durchläuft der Parser die Datei und liest aus ihr die Daten zeilenweise aus. Dabei interpre-tiert der Parser die Tags der Datei und wandelt diese an gegebener Stelle in Java-Klassen um. Mitgelieferte Attribute werden ebenso ausgelesen und an die Klassen übergeben. Zuvor müssen die Tags dem Parser als statische Variablen bekannt gemacht werden und die ent-sprechenden Klassen mit eventuellen Attributswerten zur Verfügung stehen.
Der Parser arbeitet nach dem Prinzip eines Zustandsautomaten. Ihm ist bekannt, welche Art von Tags eingelesen wurden und er weiss, welche oder welches Tag direkt darauf folgen darf. Stimmt das folgende Tag nicht damit überein, wird eine Fehlermeldung generiert und der Parser stoppt. Gleiches geschieht bei falschen bzw. fehlenden vorausgesetzten Attribu-ten.
Somit entstehen alle nötigen Klassen, die dann zum Starten der Anwendung in den Speicher geladen werden. Nicht untersucht wurde, ob es zwecks Speicherverwaltung vorteilhafter wä-re, die XML-Datei nur teilweise auszulesen und bei Bedarf den jeweiligen Teil nachzuladen, oder ob das ständige Öffnen und Parsen einer Datei den Vorteil wieder aufhebt.
4.2.2. Kamera
Um in den Anwendungen die Kamera nutzen und gegebenenfalls Bilder aufnehmen zu können, wurde ein Camera-Service implementiert. Ziel war es, diese Funktio-nen so einfach wie möglich nutzbar zu machen. Dazu wurde der konkrete Service (CameraServiceImpl())mit einfachen Funktionen ausgestattet, welche die detail-lierte Implementierung vor dem Entwickler verbirgt. Zur Anzeige des aktuellen Kamerabilds muss lediglich die Methode showCamera(..) aufgerufen und der Funktion ein Objekt mitgeliefert werden, auf dem das Bild angezeigt werden soll. Das Aufnehmen eines Bildes läuft genauso einfach ab, in dem man die Methode getSnapshotAsByteArray() oder getSnapshotAsImage() aufruft, je nachdem in welchem Format man die Bilddaten zurück geliefert bekommen möchte. Zum Beenden reicht der Aufruf von discardPlayer().
4. Konzept 14
4.2.3. Barcode
Als Weiteres wurde die Möglichkeit zur Erkennung von Barcodes implementiert. In diesem Projekt wurde die Erkennung von Semacodes12 realisiert. Es ist ein 2D Barcode und steht samt den Bibliotheken frei zur Verfügung.
Das Dekodieren eines Semacode kann mit Verwendung des eigenen Camera-Service vollbracht werden. Wurde ein Bild eines Codes aufge-nommen, ruft man in der Klasse SemacodeServiceImpl einfach decode(..) mit den Bildinformationen als Parameter auf. Die Methode kann die Informationen als Byte-Array oder als Image Objekt verarbeiten.
Zurückgeliefert wird der dekodierte Wert als String.
4.2.4. Audio
Das Abspielen von Audiodateien sollte in gleicher Weise einfach anwendbar sein wie der Camera-Service. Der Audio-Service stellt hierzu zwei Methoden zur Verfügung. Die erste Methode der KlasseAudioServiceImplheißtplayAudio()und erhält als Parame-ter den Pfad zu der Audiodatei. Diese erkennt anhand der Dateiendung um welches Format es sich handelt und spielt den Ton ab. Die zweite Methode ist eine überladene Methode der Ersten und ruft diese intern auf. Davor wird allerdings noch die Lautstärke gesetzt, die in dieser Methode als zusätzlicher Parameter mitgegeben werden kann.
4.2.5. Weitere Aufgaben
Sobald während des Projektes etwas Leerlauf entstand, konnte man seine freie Kapazität dazu nutzen in anderen Themengebieten Unterstützung anzubieten, wenn durch die steti-ge Weiterentwicklung nicht neue Anforderunsteti-gen aufsteti-gekommen sind. Der Autor hatte hierbei noch Mitarbeit beim Thema Location-Service und Timer-Service geleistet.
Der Location-Service bezog sich hauptsächlich darauf, Positionsangaben über GPS zu Emp-fangen und diese der Anwendung zur Verfügung zu stellen bzw. Events zu generieren, wenn eine bestimmt Position mit dem Gerät erreicht wurde.
Beim Timer-Service handelte sich es um Konfiguration und Generierung von Events zu ei-nem bestimmten Zeitpunkt oder Zeitintervall.
Für weitere Informationen sei auf die Arbeiten der jeweiligen Kommilitonen verwiesen [9].
12Semacode Homepage