4.2  Clients

4.2.1  Asus Eee PC

Für die Entwicklung von eigenen Programmen auf dem Eee PC muss zuerst die GCC installiert werden. Siehe dazu Kapitel 2.5.1. Ausserdem muss der gpsd-Server installiert sein. Siehe dazu Kapitel 2.5.2. Für den Zugriff auf den gpsd-Server muss der gpsd-Quellcode heruntergeladen werden. Er ist unter http://developer.berlios.de/project/showfiles.php?group_id=2116 erhältlich. Informationen zu dem gpsd-Projekt gibt es unter http://gpsd.berlios.de/. Die Webseite ist leider nur auf Englisch verfügbar. Unter Downloads http://gpsd.berlios.de/#downloads gibt es einen Link zur Projektseite http://developer.berlios.de/projects/gpsd/. Der GPS Daemon ist in der Programmiersprache C geschrieben und nur für Linux erhältlich. Ich habe die Version 2.37 vom 17.02.2008 (http://prdownload.berlios.de/gpsd/gpsd-2.37.tar.gz) verwendet. Dieses Archiv habe ich in ein Unterverzeichnis gpsd entpackt. Die verwendete Bibliothek heisst libgps (C service library for communicating with the GPS daemon). Unter http://gpsd.berlios.de/libgps.html ist sie dokumentiert. Der GPS Daemon liest die GPS-Daten von der GPS-Maus ein und stellt sie lokal unter dem Standard-Port 2947 zur Verfügung. Die libgps-Bibliothek wird wie folgt in das eigene Programm eingebunden:

Zusätzlich benötige ich einen base64-Encoder um die Benutzerdaten zu codieren. Da es in C keine Funktion dafür gibt wie in PHP muss eine externe Bibliothek eingebunden werden. Im Internet findet man solche Zusatzbibliotheken. Eingebunden wird der C-Quellcode mit
#include "base64.c". Die Dateien base64.c und base64.h müssen sich im gleichen Verzeichnis wie der Client befinden. Für den GPS-Status werden drei Konstanten definiert. Die Struktur
static struct gps_data_t *gpsdata enthält später die Standortposition des Eee PC-Clienten. Zu Beginn des Hauptprogramms werden einige Variablen definiert. Dann werden die Parameter ausgewertet. Ein Server muss übergeben werden. Dort liegen die PHP-Skripte. Das Root-Verzeichnis des Servers wird benötigt. So spielt es keine Rolle wo die Anwendung installiert wurde. Der Client ist so flexibel einsetzbar. Die restlichen Parameter Benutzername, Passwort, Intervall und Wiederholungen sind optional. Allerdings hängt dies von der Konfiguration der Server-Anwendung ab. Falls dort die Passwortabfrage aktiviert wurde muss auch bei der Client-Anwendung immer ein Benutzername und Passwort übergeben werden. Die Intervallzeit wird in Sekunden angegeben und legt den Abstand zwischen den Datenübertragungen fest. Voreingestellt ist ein Wert von 9 Sekunden. Die Anzahl der Wiederholungen legt fest wieviele Datenübertragungen maximal stattfinden sollen. Voreingestellt ist hier die grösst mögliche int-Zahl INT_MAX. Sie liegt bei 2147483647, das heisst bei einem Intervall von 9 Sekunden würde die Anwendung viele Jahre ohne Unterbrechung laufen. Falls kein oder mehr als fünf Parameter übergeben wurden wird das Programm mit einer Fehlermeldung sofort wieder beendet. Wenn Benutzerdaten vorliegen werden diese nun in base64 codiert. Nun wird eine lokale Verbindung zum GPS Daemon hergestellt. Das C-Programm kann mit der Tastenkombination STRG+C abgebrochen werden. Falls gpsdata NULL ist wird mit einer Fehlermeldung das Programm beendet. Ansonsten unterbricht das Programm für 2 Sekunden um die Ausgaben sichtbar zu machen. Nun beginnt die Schleife, in der die Daten abgerufen werden. Die GPS-Koordinaten stehen dann in gpsdata->fix.latitude und gpsdata->fix.longitude. Falls 0.0, sind sie ungültig und der Status wird entsprechend gesetzt. Falls sich mindestens eine Koordinate verändert hat nimmt der Status GPS_UPDATE an, sonst GPS_NO_UPDATE. Damit alle GPS-Daten auch später noch auf dem Eee PC zur Verfügung stehen werden diese in einer Log-Datei gespeichert. Sie sollten der Aufzeichnung auf dem Server entsprechen. Mit dem Linux Tool wget wird das PHP-Skript client_saveNewPosition.php aufgerufen und die laufende Index-Nummer, der aktuelle Status, die GPS-Koordinaten und die Benutzerdaten als Parameter angehängt. Die Kommandooptionen -q --spider verhindern die Ausgabe von Debug-Informationen und das Herunterladen der Webseite. Mit der system()-Funktion wird das wget-Tool gestartet. Nach dem Löschen des Konsolenfensters werden die aktuelle GPS-Daten angezeigt. Das Programm unterbricht nun für einige Sekunden um danach den nächsten Schleifendurchlauf zu starten. Die Verbindung zum GPS Daemon wird nach dem letzten Schleifendurchlauf geschlossen. Um den C-Quellcode zu kompilieren muss folgender Befehl in der Konsole eingetippt werden:

Um den Client zu starten müssen folgende Kommandos nacheinander ausgeführt werden:

Zuerst wird der GPS Daemon gestartet. Danach der GPS-Client client_sendNewPositions mit der Server-Adresse. Benutzer und Passwort werden ersetzt durch eigene Werte. In diesem Falle beträgt die Intervallzeit 9 Sekunden. Siehe auch Abbildung 5.1.

4.2.2  Smartphones mit Java Platform, Micro Edition (Java ME)

Mit Java ME können sogenannte MIDlets erstellt werden, die auf neueren Handys mit Java-Unterstützung ausgeführt werden können. Auf der Webseite http://www.karbacher.org/java-j2me/die-besten-j2me-tutorials/ gibt es einige Links zu guten Jave ME Tutorials. Ich habe mich für das Einsteiger-Tutorial von Sun entschieden. Es ist unter
http://today.java.net/pub/a/today/2005/02/09/j2me1.html veröffentlicht.

Zuerst muss das Java 2 SDK und das Java Wireless Toolkit installiert werden. Es sollte nicht die aktuelle Version des SDK installiert werden, da es laut dem Tutorial zu Konflikten mit dem Wireless Toolkit kommen kann. Das Tutorial schlägt vor, eine 1.4.2 Version des SDK zu installieren. Ich verwendet das Java 2 SDK, SE v1.4.2_18. Es ist unter
http://java.sun.com/j2se/1.4.2/download.html zu bekommen. Im Tutorial wird das Wireless Toolkit 2.2 verwendet, das unter http://java.sun.com/products/j2mewtoolkit/download-2_2.html verfügbar ist. Zu dieser Version sind noch zwei Updates erhältlich. Mit dieser Kombination können problemlos MIDlets erstellt werden, allerdings bietet diese Version noch keine Unterstützung für das Testen von GPS-Funktionalitäten an. Im aktuellen Java Wireless Toolkit 2.5.2 for CLDC gibt es einen External Event Generator, der einen aktiven GPS-Empfang simulieren kann. Das Java Wireless Toolkit 2.5.2 for CLDC ist unter
http://java.sun.com/products/sjwtoolkit/ zu bekommen. Wenn die beiden Programme installiert sind wird noch die JSR-179 Location API Bibliothek benötigt, allerdings nur für das Wireless Toolkit 2.2. Sie ist im Nokia Forum erhältlich. Sie wird mit dem Java Wireless Toolkit 2.5.2 for CLDC bereits mitgeliefert (jsr179.jar). Im Installationsverzeichnis des Wireless Toolkit gibt es einen Unterordner apps, darin befinden sich alle entwickelten MIDlets.

Ich habe dort einen neuen Ordner GpsClient angelegt, darin nochmals zwei Ordner bin und src. Diese enthalten dann jeweils die Programm- und Quelldateien. Beim Erstellen der JAR-Archivdatei wird eine Textdatei Manifest.mf benötigt, die zuvor angelegt werden muss. Ich habe sie in dem Verzeichnis src gespeichert. Sie sollte wie folgt aufgebaut sein:

Die Namen müssen jeweils dem Programmnamen entsprechen. Die letzten zwei Zeilen sind sehr wichtig. Hier wird die zu verwendende Konfiguration des MIDlets festgelegt. Sie muss vom vorhandenen Endgerät unterstützt werden. Auf den Seiten des Handy-Herstellers steht meistens welche Konfiguration verwendet werden kann. Falls die Version zu hoch gewählt wurde ist das MIDlet auf dem Endgerät nicht lauffähig. Die Textdatei muss am Ende einen Zeilenumbruch enthalten. Die Sourcecode-Datei GpsClient.java in src enthält den Java-Code des MIDlets. Um das MIDlet auf dem Rechner zu testen oder im Internet bereitzustellen wird eine Application Descriptor-Datei GpsClient.jad benötigt. Sie hat folgendes Format:

Wichtig ist, dass sämtliche Daten wie Programmname, MicroEdition-Configuration und MicroEdition-Profile mit denen aus Manifest.mf übereinstimmen. MIDlet-Jar-Size muss der aktuellen Grösse des JAR-Archivs in Bytes entsprechen. Durch Doppelklick auf die Application Descriptor-Datei kann das MIDlet mit dem integrierten Simulator getestet werden. Für das Kompilieren und Erstellen des JAR-Archivs habe ich ein Batch-Skript compile.cmd geschrieben:

Es wird in bin gespeichert. Zuerst wird die alte Class-Datei und das alte JAR-Archiv gelöscht. Danach wird der Java-Quellcode kompiliert. Dabei müssen die verwendeten Java-Bibliotheken über einen Parameter angegeben werden. Der bootclasspath muss gesetzt werden, da es sich hier nicht um eine normale Java-Applikation handelt sondern um eine Java ME-Anwendung. Alle Bibliotheken befinden sich im Wireless Toolkit Installationsverzeichnis im Unterordner lib. Es gibt verschiedene Versionen der Bibliotheken die mit den Angaben in der Manifest.mf und der GpsClient.jad übereinstimmen müssen. Die lapi.jar ist die JSR-179 Location API Bibliothek von Nokia. Falls vorhanden kann anstattdessen auch die jsr179.jar eingebunden werden. Nachdem die Class-Datei erstellt worden ist muss diese vor-verifiziert werden, da auf dem mobilen Endgerät dafür nicht genug Resourcen zur Verfügung stehen. Auf dem Handy wird dann der zweite Teil der Verifikation vorgenommen. Der jar-Befehl erstellt die JAR-Archivdatei, die dann auf das Handy kopiert werden kann. Dabei wird die Manifest-Datei und ein Icon eingebunden. Der letzte Befehl unterbricht das Batch-Skript.

Das entwickelte Programm heisst GpsClient, die Klasse des Programms entsprechend genauso. Beim Start des Programms werden verschiedene Eingaben vom Benutzer abgefragt. Der Server mit den installierten PHP-Skripten, der Benutzername und das Passwort und die Intervallzeit. Sie gibt an (in Sekunden) in welchen Abständen jeweils eine neue GPS-Information übertragen werden soll. Für den Multimedia-Server der HTW Aalen muss folgende Server-Adresse verwendet werden:

Diese Eingaben werden über ein TextField abgefragt. Der Server und die Intervallzeit werden mit einem RecordStore-Objekt auf dem Handy gespeichert. Zu Beginn werden bereits vorhandene Daten geladen und im Eingabeformular angezeigt. Da dies sofort nach dem Start des Programms erfolgt steht der zugehörige Programmcode in der Funktion public GpsClient(), die zu Beginn aufgerufen wird. Ausserdem werden noch zwei Befehlsbuttons zum Starten und Beenden des Programms hinzugefügt.

Falls der Befehl „Starten“ausgeführt wurde findet eine base64-Encodierung der Anmeldedaten statt. Danach wird ein separater Thread für die weiteren Funktionalitäten gestartet. Dies hat den Vorteil, dass die Programmoberfläche während der Laufzeit nicht blockiert wird. Die Thread-Funktion heisst public void run(). Für die Ausgaben werden StringItem-Elemente angelegt. Das sind Text-Ausgabe-Boxen, deren Inhalt jederzeit geändert werden kann. Es werden noch zwei Befehle hinzugefügt, Hide und Beenden. Mit dem Hide-Befehl kann die Anwendung in den Hintergrund gebracht werden. So können während das Programm läuft noch andere Funktionen des Mobiltelefons genutzt werden. Das neu zusammengestellte Formular wird nun angezeigt. Mit dem Befehl lp=LocationProvider.getInstance(cr) wird die GPS-Standortbestimmung initialisiert. Der Benutzer muss diese Funktionalität erlauben indem er die Anfrage des Programms bestätigt. In einer meiner vorigen Programmversionen musste der Anwender bei jeder Positionsbestimmung bestätigen. Da dies nicht benutzerfreundlich ist habe ich nach einer anderen Lösung gesucht. Mit Hilfe des Location-Listeners ist es möglich neue GPS-Daten ohne weitere Bestätigungen zu erhalten. Dazu implementiert die GpsClient-Klasse den LocationListener. Um dies zu realisieren müssen zwei Callback-Funktionen implementiert werden, die vom LocationProvider automatisch aufgerufen werden:

Falls sich die Standortposition geändert hat wird die erste Callback-Funktion aufgerufen mit den aktualisierten Koordinaten. Diese speichere ich dann in zwei globalen Variablen (lat, lng). So kann ich im Thread auf diese Daten zugreifen. In einer Endlosschleife werden die GPS-Daten überprüft und an den Multimedia-Server geschickt. Anfangs sind die Koordinaten beide GPS_NULL(=200.0). Dies wird als Fehler interpretiert. Sonst werden die aktuellen Koordinaten mit den vorigen Koordinaten verglichen. Hat sich mindestens eine davon geändert werden die aktuelle Koordinaten für den nächsten Vergleich gespeichert. Die Standortposition hat sich in diesem Fall geändert. Sonst ist sie gleich geblieben. Danach werden die Koordinaten in Strings umgewandelt und auf dem Display dargestellt. Jetzt wird eine HTTP-Verbindung erstellt. Dabei wird der vom Benutzer angegebene Server mit den PHP-Skripten verwendet und alle Daten als Parameter angehängt. Als Request-Methode verwende ich HEAD, da die Ausgabe der Seite nicht benötigt wird. Ansonsten ist diese Methode identisch zu einer GET-Anfrage. Als nächstes setze ich noch den User-Agent auf den Mobiltelefon-Namen. Diese taucht dann im Log-File der Software auf dem Server wieder auf. So können Anfragen von verschiedenen Handy-Modellen erkannt werden. Die Status-Nachricht des Servers wird gespeichert. Mit dem Befehl conn.openInputStream() wird die Anfrage der URL schliesslich ausgeführt. Auf dem Display wird jetzt die laufende Nummer, der Statuscode der GPS-Abfrage und die Status-Nachricht vom Server dargestellt. So kann der Benutzer genau nachvollziehen ob die GPS-Daten fortlaufend erfasst wurden, fehlerfrei sind und ob sie korrekt zum Server übertragen wurden.

Auf diesselbe Weise werden die Nachrichten vom Kontrollzentrum abgerufen. Diese Anfrage wird per GET-Methode gestellt. Sie wird nur bei jedem 6. Durchlauf der Endlosschleife durchgeführt. Bei einer eingestellten Intervallzeit von 9 Sekunden also alle 54 Sekunden. Dadurch werden weniger Daten übertragen, was Kosten einspart. Dieser Intervall reicht vollkommen aus um aktuelle Nachrichten zu empfangen. Die Nachricht ist auf 255 Zeichen beschränkt, dies wird beim Server durch das HTML-Attribut maxlength="255" garantiert. Der Thread wird jetzt für die eingestellte Zeit in Sekunden unterbrochen.