Facharbeit

Geschwister-Scholl-Gymnasium
GK / Informatik / ZL
Von-Humboldt-Str. 54
42549 Velbert
Schuljahr 2003/04
Facharbeit
Entwicklung einer (HTTP-)
clientbasierten Software für
Mobiltelephone zur Abfrage
und Organisation von
Klausurterminen mittels der
J2ME-Technologie
Johannes Brakensiek
Zum Waschenberg 71
42551 Velbert
[email protected]
Abgabetermin: 15. März 2004
Betreut durch OStR’ Zielke
Inhaltsverzeichnis
1. Einleitung / Zielsetzung
3
2. Anforderungen an das Programm
4
3. J2ME, CLDC und MIDP
5
4. Konzeption
4.1. Datensicherung . . . . . . . . . . . . . . . . . . . . . .
4.2. Userinterface . . . . . . . . . . . . . . . . . . . . . . .
4.3. Klassenstruktur . . . . . . . . . . . . . . . . . . . . . .
6
6
7
8
5. Klassenbeschreibung
5.1. KlautorMIDlet . . .
5.2. Termin . . . . . . . .
5.3. Termine . . . . . . .
5.4. AbstractLoadScreen
5.5. Database . . . . . .
5.6. Parser . . . . . . . .
5.7. Browser . . . . . . .
.
.
.
.
.
.
.
8
8
9
9
10
10
11
11
6. Probleme und deren Lösung
6.1. Allgemein . . . . . . . . . . . . . . . . . . . . . . . . .
6.2. Qualitätssicherung . . . . . . . . . . . . . . . . . . . .
12
12
13
7. Fazit
14
A. Erklärung über die selbstständige Anfertigung der Arbeit
17
B. Erläuterungen
B.1. Schrift . . . . . . . . . . . . . .
B.2. Zitate und Literaturverzeichnis
B.3. Quelltext . . . . . . . . . . . .
B.4. Fortsetzung der Entwicklung . .
18
18
18
18
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
C. Anhang
C.1. Übersicht über die Klassenstruktur . . . . . . . . . . .
C.2. Protokoll der Qualitätssicherung zu Version 1.0a1 . . .
C.3. Protokoll der Qualitätssicherung zu Version 1.0a2 . . .
C.4. CD mit weiterer Dokumentation, Quelltext und ausführbaren Anwendungen . . . . . . . . . . . . . . . . .
19
19
19
19
19
1. Einleitung / Zielsetzung
Vor wenigen Jahren führte der Beginn einer gewaltigen Vergrößerung
des Mobiltelefonmarktes dazu, dass inzwischen ein Großteil der Bürger der Industriestaaten ein Mobiltelephon besitzt. Es ist also nicht
verwunderlich, dass auch die technische Entwicklung in diesem Bereich rasante Fortschritte machte. Inzwischen haben viele der aktuellen Handies ein 12-bit Farbdisplay und bieten Möglichkeiten JavaProgramme auszuführen, wie z.B. eine Produktübersicht der aktuellen
Nokia-Handies zeigt1 .
Da die Inhalte des Informatikunterrichts2 ausschließlich mittels der
Programmiersprache Java konkretisiert werden, lag nahe, dass eine
praktische Facharbeit in diesem Fach diese Programmiersprache ebenfalls nutzen sollte. Durch die Verknüpfung der soeben geschilderten
Punkte und der neuerdings eingeführten Vorschrift, eine Facharbeit
in der Sekundarstufe II solle sich mit einem lokal relevanten Thema
auseinandersetzen, entstand der Gedanke, ein Programm für Mobiltelefone zu entwickeln. Dieses Programm soll es dem Benutzer (in diesem
Fall einem Schüler) ermöglichen aus dem Internet seine Klaursurtermine abzurufen und zu verwalten, und das, dank mobilem Telefon, an
nahezu jedem beliebigen Ort.
Das vorliegende Schriftstück soll das Ergebnis, aber auch die wichtigsten Schritte der Entwicklung dieses Programmes dokumentieren.
Leider zeigte sich, dass sowohl der zeitliche, als auch der formelle Rahmen dieser Facharbeit dies nur sehr grob ermöglichen.
Nichtsdestotrotz möchte ich im folgenden zuerst die Anforderungen
an das Programm beschreiben. Daraufhin mit Hilfe welcher Technologien diese erfüllt werden sollen und wie die Software konzipiert ist.
Anschließend werde ich grob die Module des fertiggestellten/funktionsfähigen Programmes dokumentieren, um danach darauf einzugehen,
welche Probleme beim Programmieren der Software auftraten und wie
diese (teilweise) gelöst wurden.
1
Nokia Corporation (2003): Nokia Developer Platforms“. URL: http://www.forum.nokia.com”
/main/1,6566,040,00.html?fsrParam=2-3-/main.html&fileID=4144 [Stand: 4.2.2004] (Datei:
Literatur/Device matrix 111903.pdf) [1]
2
Am Geschwister-Scholl-Gymnasium in Velbert/Rheinl.
3
2. Anforderungen an das Programm
Die vor Beginn der Arbeit formulierte Aufgabenbeschreibung nannte
Zweck und Funktionen des zu entwickelnden Programmes. Der Zweck
wurde bereits in der Einleitung erwähnt: Schüler sollen mit ihrem Mobiltelefon über das Internet Klaursurtermine abrufen können, welche
auf einem Webserver3 gespeichert sind. Das Programm soll darüber
hinhaus die Möglichkeit bieten, nur für den Benutzer relevante Termine zu selektieren und alle übrigen zu verwerfen. Die ausgewählten
Termine wiederum sollen persistent im Speicher des Mobiltelefons abgelegt werden können, damit die Daten nicht nach Beendigung des
Programmes verloren gehen. Desweiteren soll der Benutzer die Termine in einer Übersicht oder auch einzeln betrachten und, wenn gewünscht, eine Notiz zu einem Termin speichern können. Auch sollen
die Termine in der Übersicht nach einem auswählbaren Kriterium sortiert werden können und der Benutzer soll die Möglichkeit haben, die
Termindaten bei Änderungen über das Internet aktualisieren zu lassen. In der Aufgabenstellung nicht beschrieben, aber aus ihr folgernd,
ist, dass es zudem eine Möglichkeit geben muss, mit der der Benutzer
individuelle Informationen einstellen kann, welche für den Ablauf des
Programmes wichtig sind.
Wünschenswert ist zudem eine Kurzdokumentation oder hilfreiche
Erläuterung, welche der Benutzer im Programm selbst aufrufen kann,
die ihm kurz beschreibt, welche Optionen das Programm bietet und
wie zu diesen zu gelangen ist.
Dies sind die Funktionen, die das Programm4 bieten muss. Zu den
Anforderungen gehört jedoch noch weit mehr, insbesondere bei einer
Software für kleine, mobile Geräte. So kann bei der Entwicklung von
Software für derartige Geräte nicht davon ausgegangen werden, dass
diese von technisch hochversierten Personen bedient werden (gerade
da, wie bereits in der Einleitung beschrieben, das Mobiltelefon ein
noch größeres Massenprodukt als der Personal Computer ist). Auch
werden diese Geräte in allen Alltagssituationen verwendet, es kann
also vermutet werden, dass der Benutzer sich nicht immer voll auf die
Bedienung des Gerätes konzentriert.
Ebenso müssen die technischen Eigenschaften der Geräte selbst bei
der Entwicklung mit einkalkuliert werden: Obwohl es Minimal-Anfor3
Webserver: Ein Computer im Internet, der anderen Computern (sog. Clients) im Netzwerk über
ein standartisiertes Protokoll Informationen anbietet und diese auf Abfrage zusendet.
4
Das Programm wurde aufgrund der oben genannten Funktionen Klautor“ genannt, was für
”
KlausurTerminOrganisator“ steht.
”
4
dernungen für Java-fähige Geräte gibt, unterscheiden sich diese teilweise sehr stark in Bildschirm- und Speichergröße, sowie Prozessorgeschwindigkeit. Auch stellen diese Geräte ihre Netzwerkverbindung
zum Internet meist über einen Funk-Zugang her, dessen Stabilität keineswegs gesichert ist5 . Es gilt also eine Software zu entwickeln, die von
jedem – auch nebenbei“ – bedienbar ist, der ein Mobiltelephon bedie”
nen kann und die auf die technischen Gegenbenheiten achtet“ und in
”
Fehlerfällen entsprechend reagiert.
Ein weiterer wichtiger Aspekt, der bei diesen Überlegungen eine
Rolle spielt, ist die Portierbarkeit der Software. Um eine möglichst
große Anzahl von Benutzern anzusprechen, sollte das Programm auf
möglichst vielen (unterschiedlichen) Geräten lauffähig sein.
3. J2ME, CLDC und MIDP
Die Software sollte mit Hilfe von Java realisiert werden. Nun ist Java
an sich zuerst nicht mehr als eine Programmiersprache, erst die – von
den Firmen so genannten – Technologien“ ermöglichen eine praktische
”
Anwendung dieser Sprache. Die Java 2 MicroEdition (kurz: J2ME) ist
die zur Erfüllung der genannten Anforderungen relevante Technologie,
wie ja auch bereits das Thema dieser Arbeit vorgibt. Um treffend zu
beschreiben, was J2ME genau ist, zitiere ich aus einer Antwort der
FAQ von Sun 6 zu diesem Thema: It is comprised of a set of confi”
gurations, profiles, and standard extensions that can be used to build
complete Java runtime environments that meet the requirements of a
broad range of devices on the market. Each combination is designed
to fit specific market requirements and device capabilities.“
J2ME wiederum ist durch viele weitere Spezifikationen eingeteilt.
Die für die Entwicklung von Programmen für mobilen Geräten interessante Spezifikation ist die Connected Limited Device Configuration
(kurz: CLDC). In ihr ist durch das JCP-Programm7 ein grundlegender
5
vgl. Nokia Corporation (27.11.2002): Java™MIDP Application Developer’s Guide for Nokia De”
vices“. URL: http://www.forum.nokia.com/main/1,6566,21 10,00.html#java [Stand: 4.2.2004]
(Datei: Literatur/Java MIDP App Dev Guide v1 0.pdf) [2], S. 5f.
6
Sun Microsystems, Inc. (Herausgabedatum unbekannt): J2ME CLDC and K virtual machi”
ne: Frequently Asked Questions“. URL: http://java.sun.com/products/cldc/faqs.html [Stand:
6.3.2004] (Datei: Literatur/J2ME CLDC and K virtual machine - FAQ.html) [3]
7
JCP: Java Community Process: Über 500 Partner aus der internationalen Wirtschaft, die zusammen mit Sun Microsystems, Inc. Java-Standards festlegen.
5
Satz von Bibliotheken8 , sowie eine Virtual Machine“9 definiert worden,
”
die speziell für diese Geräte entwickelt wurden10 .
Das Mobile Information Device Profile (kurz MIDP) ist eines der
Profile, welches (durch einen weiteren Satz von Bibliotheken) die CLDC
so erweitert, dass sie für die konkrete Entwicklung von Programmen
für bestimmte mobile Geräte, besonders Mobiltelephone, brauchbar
wird. Ich habe mich bei der Entwicklung von Klautor“ für die Versi”
on 1.0.3 dieses Profiles entschieden, welche nicht so ausgereift ist wie
die Version 2.0, dafür aber in wesentlich mehr Geräten Verwendung
findet.
4. Konzeption
Vor und bei der Programmierung einer Software spielt die Konzeption
derselben eine tragende Rolle. Nur mit einem sauberen Design der einzelnen Programmteile wird die Software schnell, leicht bedienbar und
möglichst fehlerarm, um einmal die wichtigsten Faktoren zu nennen.
Im Folgenden sollen kurz die Überlegungen hierzu dargestellt werden.
4.1. Datensicherung
Die Geschwindigkeit, aber auch die Kompatibilität einer Software zu
anderen Programmen, hängt stark von der Struktur und Art ab, in
der die Daten gespeichert werden, mit denen die Anwendung arbeitet.
Das Programm Klautor“ hat es grundsätzlich mit zwei verschiedenen
”
Typen von Daten zu tun: Den Einstellungen für das Programm sowie
den eigentlichen Informationen über die Klausurtermine. Auf letztere
werde ich an dieser Stelle exemplarisch eingehen.
Da in diesem Fall nur relativ wenige (Termin-)Daten zu verarbeiten
sind, wählte ich eine einfach Struktur der Informationen, die folgenden
Konventionen – sowohl auf Seite des Webserver, als auch auf Seite des
Mobiltelefones – folgt:
• Alle Termin-Informationen werden als Zeichenkette verarbeitet.
8
Bibliothek: engl. Library; in Java eine Sammlung von Befehlssätzen, die von außen in Programme
eingebunden und genutzt werden können.
9
Virtual Machine: Software, die die vom Programm javac in die Java-Pseudo-Maschinensprache
übersetzten Quelltexte für die jeweilige Hardware interpretiert.
10
vgl. FAQ von Sun [3]
6
• Die einzelnen Termine werden hierbei durch Zeilenumbrüche getrennt, d.h. jeder Informationsblock wird durch einen Zeilenumbruch beendet.
• Die Informationen eines Termins wiederum werden durch Doppelpunkte ( :“) getrennt, jeder Informationsblock wird hier also
”
durch einen Doppelpunkt beendet, d.h. eine Termin-Zeile“ ent”
hält Informationen, die in folgender Form aufgelistet werden:
Fach:Kurstyp:Raum:Lehrer:Thema:Datum:11
• Das Datum wird im Format DD.MM.JJJJ angegeben, also z.B.:
06.03.2004. Das Programm ist aber auch in der Lage ein Datum
des Formats D.M.JJ zu verarbeiten, also z.B.: 6.3.04.
Auf dem Webserver werden die Informationen in einer einfachen Textdatei gespeichert, welche den Namen der Jahrgangsstufe trägt, für
die die Termine relevant sind. Für die Oberstufe eines Gymnasiums
wird es also i.d.R. drei Dateien für die Stufen 11, 12 und 13 geben,
welche ihrerseits der Übersicht halber am Besten in einem eigenen
Verzeichnis gespeichert werden. Im Mobiltelefon werden die Daten in
sog. Records“ eines RecordStores“12 gespeichert. Die Daten müs”
”
sen dort allerdings im Byte-Format, also als Binärdaten, hinterlegt
werden, weswegen die für den Benutzer relevanten Termine aus dem
Zeichenketten-Format umgewandelt müssen. Die Einteilung der Daten
nach Jahrgangsstufen entfällt an dieser Stelle.
4.2. Userinterface
Auch das Userinterface, also die Oberfläche, mit der der Benutzer mit
dem Rest des Programmes kommuniziert“, soll den im vorherigen
”
Kapitel beschriebenen Anforderungen genügen.
Ansonsten ist die Strukturierung und Gestaltung eines Userinterfaces aber auch Geschmackssache“.
”
Um einen Überblick darüber zu erhalten, wie das Userinterface geplant und dann auch realisiert wurde, startet man am Besten das Programm selbst und schaut sich die Struktur live“ an, da eine Übersicht
”
nicht auf einigen wenigen DIN-A4-Seiten darzustellen war.
11
12
Wofür diese Platzhalter stehen, ist im Abschnitt 5.2 auf S. 9 erläutert.
vgl. MIDP-Spezifikation (Sun Microsystems, Inc. (2000): Mobile Information Device Pro”
file (MIDP) Specification“. URL: http://jcp.org/aboutJava/communityprocess/final/jsr037/index.html [Stand: 26.1.2004] (Verzeichnis: Literatur/MIDP 1 0 a/) [4], Datei: html/javax/microedition/rms/RecordStore.html
7
4.3. Klassenstruktur
Das MIDlet13 hat viele Menüs und diverse andere Benutzeroberflächen.
Viele dieser Menüs sollten schon zur Übersichtlichkeit des Programmquelltextes durch eigene Klassen14 repräsentiert werden. Es ist also
naheliegend, dass die Reaktionen, die nach Betätigung einer Aktion in
der Benutzeroberfläche erfolgen sollen, in den selben Klassen realisiert
werden.
Nicht ideal wäre jedoch, wenn die Struktur der Klassen untereinander der Menüstruktur entspräche. Denn dann würden z.B. beim Aufrufen eines Menüs direkt alle Untermenüs mitgeladen werden. Dies
würde nicht nur zu einer unlogischen, sondern auch zu einer sehr dezentralen und speicherintensiven Klassenstruktur führen, zumal es ja
eventuell auch sinnvoll ist, mehrere Oberflächen“ in einer Klasse zu
”
verankern. Besser ist also, wenn eine zentrale Klasse das Aufrufen
der Menüs vornimmt und diese (die Menü-Klassen) nach Beendigung
ihres Vorganges dieses der zentralen Klasse mitteilen (sog. CallbackMethode).
Der Übersicht im Anhang kann entnommen werden, wie die Klassenstruktur schlussendlich konzipiert und später auch umgesetzt wurde.
5. Klassenbeschreibung
In diesem Kapitel werden nun kurz die Aufgaben der wichtigsten Klassen, so wie sie am Ende der Entwicklung15 bestanden, beschrieben.
Dabei werden die Klassen mit den wichtigsten Funktionen zuerst aufgeführt.
5.1. KlautorMIDlet
Die Klasse KlautorMIDlet erweitert die Klasse MIDlet16 und stellt
somit die zentrale Klasse des Projekts dar. Hier befinden sich die Methodenaufrufe17 für Start und Beendigung des Programmes, außerdem
13
MIDlet: Eine Java-Anwendung, die das MIDP benutzt.
In der objektorientierten Programmiersprache Java beschreiben Klassen die elementaren Datenstrukturen: Objekte. Beim instantiieren einer Klasse wird ein Objekt, auch Instanz genannt,
erzeugt.
15
Klautor-Version 1.0a3
16
vgl. Mobile Information Device Profile (MIDP)
Specification [4], Datei: html/javax/microedition/midlet/MIDlet.html
17
Methode: In Java werden Klassen durch Attribute und Methoden definiert. M. beschreiben,
welche Vorgänge ein Objekt der entsprechenden Klasse durchführen kann.
14
8
werden von hier aus alle Userinterface-Elemente und somit (fast) alle
weiteren Funktionen aufgerufen und verwaltet.
Die Eigenschaften dieser Klasse sind zum größtenteil Menüklassen/objekte, die so strukturiert sind, dass sie nach oder bei Erledigung ihrer Aufgabe wiederum diese (KlautorMIDlet-) Klasse aufrufen, welche
dann alle weiteren Vorgänge einleitet (in Abschnitt 4.3 bereits erwähnte Callback-Methode). Eine weitere Aufgabe dieser Klasse, neben der
Reglung der Funktionsabläufe, ist die Speicherverwaltung. Alle Objekte sollen, sobald sie nicht mehr benötigt werden, vom GarbageCollector18 eingesammelt werden können, weshalb ihre jeweilige Referenz
so bald als möglich auf null“ gesetzt wird, um so Speicher freizuge”
ben. Desweiteren wird bei der Erzeugung einiger Objekte überprüft,
ob dafür noch genug Speicher vorhanden ist. Wenn nicht, wird der
GarbageCollector losgeschickt, der Speicher freigeben soll, damit eine Fehlermeldung angezeigt werden kann und das Programm nicht in
sehr uneleganter Weise abstürzt.
5.2. Termin
Diese Klasse repräsentiert einen Klausurtermin. Sie definiert die Attribute fach“, kurstyp“, raum“, lehrer“, thema“, datum“ und
”
”
”
”
”
”
notiz“. Für welche Werte diese Eigenschaften gedacht sind, ist trivi”
al. Eine besondere Erläuterung vielleicht zu den Eigenschaften kurstyp und notiz: In ersterer kann angegeben werden, ob es sich um
einen Klausurtermin zu einem Leistungskurs oder Grundkurs handelt,
in zweiterer werden Notizen des Benutzers zu einem Termin gespeichert.
5.3. Termine
Die Termine-Klasse ist ein Vektor, der jedoch zusätzlich die Singletontechnik implementiert. In diesem Vektor werden alle Termine gespeichert, die für alle Programmmodule global erreichbar sein müssen.
Ein Vektor ist eine einem Array nachempfunde, dynamische Datenstruktur19 . Mit Hilfe der Singleton-Technik kann sich jedes beliebige
Objekt des Programmes mit Hilfe der getTermine()-Methode eine Referenz zu der Instanz dieser Klasse abholen”. Die Instanz, weil dafür
”
18
GarbageCollector: In Java muss sich der Programmierer i.d.R. nicht um Speicheradressen und
Speicherfreigabe kümmern, der G. sammelt“ alle Objekte ein, die nicht mehr benötigt werden.
”
19
vgl.
Mobile Information Device Profile (MIDP)
Specification
[4],
Datei:
html/java/util/Vector.html
9
gesorgt wird, dass nur ein einziges Objekt instantiiert wird, sodass
sichergstellt ist, dass alle Module mit denselben Daten arbeiten.
5.4. AbstractLoadScreen
Von dieser abstrakten Klasse werden (momentan) die Klassen Load”
Screen“ und UpdateScreen“ abgeleitet20 . Die Klasse führt durch den
”
Lade- und Parsevorgang. Dabei werden zwei neue Threads21 erstellt
(insgesamt wird also mit drei Threads22 gearbeitet). Die Threads synchronisieren23 sich am Objekt sync“.
”
Der Main-Thread24 ist für das Userinterface zuständig, während der
TerminLoader“-Thread die Daten aus dem Internet lädt und dabei
”
einen Ladebalken darstellt und aktualisiert. Hat der TerminLoaderThread alle Daten geladen, beginnt der ParseManager“-Thread mit
”
dem Parse-Vorgang25 während der TerminLoader-Thread die Verbindung zum Internet schließt und andere Aufräumarbeiten durchführt.
5.5. Database
Diese Klasse beschreibt ein Objekt, welches den (persistenten) Speicher des Mobiltelephones verwaltet. Mit diesem kann der Zugang zum
Datenspeicher geöffnet und geschlossen werden und es können Termine
und Einstellungen gespeichert und geladen werden. Hierzu wird die in
der API26 definierte Klasse RecordStore“ benutzt, welche allgemein
”
20
Abstrakte Klasse: In Java sind abstrakte Klassen nicht instantiierbar, sondern müssen erst durch
eine andere Klasse erweitert werden (Vererbung).
21
Thread: Threads sind Prozesse eines Programmes, die scheinbar nebenläufig arbeiten (dadurch,
dass ein sog. Scheduler des Betriebssystems oder der JavaVM sie, wenn möglich, sehr schnell
verzahnt laufen lässt) und auf den selben Adressraum zugreifen. Dadurch kann u.U. ein erheblicher Geschwindigkeitsvorteil erreicht werden (vgl. Ullenboom, Christian: Java ist auch eine
Insel. Programmieren für die Java 2-Plattform in der Version 1.4. 3. Aufl. Bonn: Galileo Computing, 2004 (URL: http://www.galileocomputing.de/openbook/javainsel3/ [Stand: 31.1.2003],
Verzeichnis: Literatur/javainsel3/) [5], Abschnitt 9.1)
22
Ein Thread läuft von vornherein, zwei weitere werden erzeugt.
23
Synchronisieren: Wenn mehrere Prozesse auf die selben Daten zugreifen, kann es zu Komplikationen kommen (Überschreiben von Daten an falscher Stelle), weswegen sie teilweise synchronisiert
werden müssen: Während ein Thread an einer Ressource arbeitet, müssen die anderen warten,
die darauf ebenfalls zugreifen wollen.
24
Main-Thread: Der M. ist der Thread, der beim Starten des Programmes ausgeführt wird.
25
Parsen: Als P. bezeichnet man den Vorgang, bei dem Informationen aus einer Quelle (i.d.R. einer
Datei) gefiltert und nach einer best. Regel weiterverarbeitet werden.
26
API: Application Program Interface: Schnittstelle eines Betriebssystems oder Programmes, die
es anderen Programmen ermöglicht bestimmte Funktionen zu nutzen (ausführen zu lassen) oder
Informationen abzurufen.
10
den Speicher des Gerätes repräsentiert und Methoden bietet, um mit
diesem zu arbeiten.
5.6. Parser
Der Parser enthält nur drei statische27 Methoden:
parse(String string), parseUpdates(String string) und deparse(). Erstere wird genutzt, um die Termininformationen aus der Datei (bzw. eigentlich dem String28 ) aus dem Internet zu filtern und in
den Termine-Vektor einzufügen, letztere fügt alle Termininformationen aus dem Vektor wieder zu einem String zusammen, damit sie im
permanten Speicher des Mobiltelephones unkompliziert gesichert werden können. parseUpdates“ tut fast das selbe wie parse“, jedoch
”
”
mit dem Unterschied, dass Daten im Termine-Vektor überschrieben
werden, wenn die übergebenen Informatinen anders/aktueller sind, als
die im Vektor befindlichen.
5.7. Browser
Der Browser“ sei an dieser Stelle exemplarisch für die 11 weiteren
”
Klassen aufgeführt, die ebenfalls ein Userinterface darstellen. Im Browser werden alle Termine mit den wichtigsten Daten aufgelistet. Der
Benutzer hat die Möglichkeit über verschiedene Befehle mit diesen
Daten zu arbeiten. Die Befehle sind dabei in der Klasse Command“29
”
definiert und werden der eigenen Benutzoberfläche hinzugefügt. Anschließend muss der Browser (oder die jeweilige andere Klasse) noch
einen CommandListener“30 implementieren und diesem die einzelnen
”
Befehle zugeordnen, sodass klar ist, welche Klasse für Reaktionen auf
die Betätigung eines Befehles zuständig ist.
27
Statische Methode: Statische Methoden sind Klassen-Methoden, die ausführbar sind, ohne ein
Objekt der Klasse zu erzeugen.
28
Ein String ist in Java die Implementierung des Datentyps, der eine Zeichenkette darstellt, vgl.
Mobile Information Device Profile (MIDP) Specification [4], Datei: html/java/lang/String.html
29
vgl. Mobile Information Device Profile (MIDP)
Specification [4], Datei: html/javax/microedition/lcdui/Command.html
30
vgl. Mobile Information Device Profile (MIDP)
Specification [4], Datei: html/javax/microedition/lcdui/CommandListener.html
11
6. Probleme und deren Lösung
6.1. Allgemein
Selbstverständlich verlief die Konkretisierung des Konzepts, aber auch
die Konzeption an sich nicht ganz problemlos, sodass an einigen Stellen
Lösungen oder sog. Workarounds“31 entwickelt werden mussten.
”
Ein erstes Problem trat bei der Konzeption des GUI32 auf, wie ja
auch schon im Abschnitt 4.3 angedeutet wurde. Am einfachsten wäre
gewesen, wenn GUI- und Klassenstruktur sich entsprächen; dass dies
jedoch logisch und programmiertechnisch nicht sinnvoll war, wurde
bereits erläutert33 .
Weitere Probleme gab es in Zusammenhang mit der Datensicherung.
So sollte das Datum in einem gängigen Format angegeben werden können34 , doch ist es als Teil der Termininformation erst einmal nur eine
– besonders zum Sortieren – sehr unpraktisch formatierte Zeichenkette. Also musste mit Hilfe eines recht umständlichen Algorithmus diese
Zeichenkette in eine Zahl konvertiert werden, die sich mit anderen
Zahlen (die ebenfalls ein Datum darstellen) vergleichen lies.
Damit wären wir auch schon beim nächsten Problem angelangt:
Den Eingeschränkungen des MID Profiles. Aus Gründen der geringen
Speicher- und Performanzoptionen der mobilen Geräte, unterscheidet
sich dieses zu anderen Java-Bibliotheken dadurch, dass einige – in
Bezug auf Ressourcen – anspruchsvolle Klassen und Methoden weggelassen wurden.
So ließe sich normalerweise eine Datums-Konvertierung mit Hilfe
der Klassen StringTokenizer“ und Date“/ Calender“35 problemlos
”
”
”
durchführen, doch existieren diese Klassen im MIDP nicht, oder nur
in gekürzter Form, sodass eine eigene Alternative entwickelt werden
musste. Dies gilt nicht nur für die Datumskonvertierung, sondern auch
für das Parsen der Daten.
Mit Hilfe der Klasse StringTokenizer hätte der Parse-Algorithmus
sehr ressourcensparend und elegant arbeiten können, stattdessen musste nun eine eigene, speicherintensive Lösung nur mit Hilfe der Klasse
31
Workaround: Bei einem W. wird nicht der Kern eines Problems gelöst, sondern um das Problem
herum gearbeitet“, also ein anderer (oft stupiderer) Ansatz gewählt.
”
32
GUI: Graphical User Interface: Ein GUI ist eine Schnittstelle, über die der Benutzer eines Programmes über grafische Elemente mit diesem kommuniziert.
33
vgl. Abschnitt 4.3 auf S. 8.
34
s. auch Abschnitt 4.1 auf S. 6
35
vgl. Java ist auch eine Insel, [5], Abschnitt 4.6 und 10.2
12
String36 geschrieben werden37 .
Ein anderes Problem, welches nicht gelöst werden konnte, trat in
Zusammenhang mit der Textcodierung der Termininformationen auf
dem Webserver auf. Die Mobiltelefone nutzen je nach Implementation des MIDP verschiedene Formatierungen, um Text zu codieren. Der
PC, auf dem die Informationen i.d.R. eingetippt werden sollten, nutzt
wiederum andere. Dies führt zu einer Inkompatibilität in Bezug auf
Sonderzeichen, welche auf dem Mobiltelefon nicht richtig dargestellt
werden. An dieser Stelle wurde keine Lösung, die nicht einen sehr hohen Aufwand erforderte, gefunden, sodass Sonderzeichen/Umlaute bei
der Eingabe der Daten einfach durch die entsprechenden normalen“
”
Zeichenfolgen zu umschreiben sind (also ae statt ä, ss statt ß . . . ).
Weitere Probleme gab es in Bezug auf den Aspekt der Portierbarkeit der Software. Das Hauptproblem war hier die unterschiedliche
Bildschirmgröße der einzelnen Geräte. Kompromisse führten an dieser
Stelle zu einer akzeptablen Lösung. Die Icons38 z.B. wurden von dem
Grafiker39 in ihrer Größe so gewählt, dass sie auf einem normalen PCBildschirm und auch auf dem Emulator40 , welcher zum Testen der Anwendung benutzt wurde, gut erkennbar waren. Jedoch zeigte sich, dass
diese Grafikengröße für Telefone mit kleineren Bildschirmen gänzlich
ungeeignet war, da sie nur teilweise angezeigt werden konnten. Dasselbe gilt für die Länge von Texten/der Menüpunkte, welche stellenweise
zu lang waren, um komplett angezeigt werden zu können. Es musste jeweils ein Kompromiss zwischen Darstellungsqualität/Verständlichkeit
und dem Rahmen der Anzeigemöglichkeiten gefunden werden.
6.2. Qualitätssicherung
Ein wichtiger Schritt im Entwicklungsprozess einer jeden profesionellen Software ist die Qualitätssicherung, bei der von den Programmierern unabhängige Personen die Software stückweise genau protokolliert
testen.
36
vgl. Mobile Information Device Profile (MIDP) Specification [4], Datei: html/java/lang/String.html
37
vgl. jeweils die entsprechenden Teile im Quelltext, welche auf der im Anhang befindlichen CD
sind.
38
Icon: Dient als Element eines GUI zur Veranschaulichung von Funktionen oder ist selbst Element
mit Aktionsmöglichkeit(en).
39
Die Grafiken wurden freundlicherweise von Tobias Wingerter gezeichnet und zur Verfügung
gestellt.
40
Emulator: Programm, welches versucht“ Attribute und Verhaltensweisen einer Hardware nach”
zuahmen.
13
Auch bei diesem Projekt sollte dieser Schritt nicht fehlen, da sich die
Firma HoeTec freundlicherweise zu einigen kurzen QS-Testläufen bereit erklärte. Dabei wurde in Version 1.0a1 des MIDlets eine Instabilität des im Informatik-Unterricht entwickelten QuickSort-Algorithmus41
gefunden42 , welcher in der Klasse Sorter“ zum Einsatz kommt. Dieser
”
Fehler wurde zur Version 1.0a243 grob behoben44 .
7. Fazit
Diese Arbeit beschrieb zuerst, welche Anforderungen an das zu entwickelnde Programm gestellt wurden und mit Hilfe welcher Technologien diese Anforderungen umzusetzen waren. Desweiteren wurden
die Überlegungen zur Konzipierung der Software und das Ergebnis
der Konkretisierung des Konzepts knapp dargestellt. Näher eingegangen wurde danach auf die Probleme, die bei der Programmierung des
MIDlets auftraten und wie diese, wenn denn möglich, gelöst wurden.
Nicht genau dargelegt wurden die vielen einzelnen Schritte der Entwicklung und Programmierung. Ebenso fehlt eine genaue technische
Dokumentation der Software bzw. der verschiedenen Version, die der
Reihe nach entstanden. Derartige Ausführungen konnte der Rahmen
dieser Arbeit (leider) nicht gestatten, es sei hier auf die ergänzende
Dokumentation verwiesen45 .
Das fertige Programm46 genügt trotz einiger Probleme bei der Entwicklung letztendlich allen beschriebenen Anforderungen und bietet
die gesamte geforderte Funktionalität. Alle Testläufe mit verschiedenen Emulatoren und auf diversen Mobiltelefonen, wie dem Nokia 3510i
und Nokia 6610, verliefen erfolgreich. Das Programm war sogar auf einem Handheld der Firma Treo unter dem Betriebssystem Palm OS
3.5.2 funktionsfähig. In diesem Sinne kann diese Arbeit als vollständig
und erfolgreich abgeschlossen bezeichnet werden, auch wenn an vielen Stellen noch Optimierungen und Erweiterungen nötig sein mögen.
Diese fallen jedoch nicht in den Rahmen dieser Facharbeit.
41
QuickSort: Ein rekursiver (sich selbst aufrufender) Sortieralgorithmus, der die Elemente einer
Menge dadurch sortiert, dass sie in immer kleinere Teilmengen delegiert und anschließend (sortiert) wieder zu einer Menge zusammengefasst werden.
42
vgl. Hoepfner, Jens: QS-Protokoll“. Protokoll der Qualitätssicherung zu Version 1.0a1. Velbert,
”
2004. [6]
43
vgl. Hoepfner, Jens: QS-Protokoll“. Protokoll der Qualitätssicherung zu Version 1.0a2. Velbert,
”
2004. [7]
44
s. auch Datei CHANGELOG“ auf der CD.
”
45
Zu finden auf der CD im Anhang C.4.
46
Ebenfalls zu finden auf der CD.
14
Literatur
[1] Nokia Corporation (2003): Nokia Developer Platforms“.
”
URL: http://www.forum.nokia.com/main/1,6566,040,00.html?fsrParam=2-3-/main.html&fileID=4144
[Stand:
4.2.2004]
(Datei: Literatur/Device matrix 111903.pdf)
[2] Nokia
Corporation
(27.11.2002):
Java™MIDP
Ap”
plication
Developer’s
Guide
for
Nokia
Devices“.
URL:
http://www.forum.nokia.com/main[Stand:
4.2.2004]
(Datei:
/1,6566,21 10,00.html#java
Literatur/Java MIDP App Dev Guide v1 0.pdf)
[3] Sun
Microsystems,
Inc.
(Herausgabedatum
unbekannt):
J2ME CLDC and K virtual machine: Fre”
quently Asked Questions“. URL: http://java.sun.com/products/cldc/faqs.html
[Stand:
6.3.2004]
(Datei:
Literatur/J2ME CLDC and K virtual machine - FAQ.html)
[4] Sun Microsystems, Inc. (2000): Mobile Information Device Pro”
file (MIDP) Specification“. URL: http://jcp.org/aboutJava/communityprocess/final/jsr037/index.html [Stand: 26.1.2004]
(Verzeichnis: Literatur/MIDP 1 0 a/)
[5] Ullenboom, Christian: Java ist auch eine Insel. Programmieren
für die Java 2-Plattform in der Version 1.4. 3. Aufl. Bonn: Galileo
Computing, 2003 (URL: http://www.galileocomputing.de/openbook/javainsel3/
[Stand:
31.1.2004],
Verzeichnis:
Literatur/javainsel3/)
[6] Hoepfner, Jens: QS-Protokoll“. Protokoll der Qualitätssicherung
”
zu Version 1.0a1. Velbert, 2004
[7] Hoepfner, Jens: QS-Protokoll“. Protokoll der Qualitätssicherung
”
zu Version 1.0a2. Velbert, 2004
[8] Sun Microsystems, Inc. (2001): MIDP APIs for Wire”
less
Applications“.
URL:
http://java.sun.com/products/midp/midp-wirelessapps-wp.pdf [Stand: 6.3.2004] (Datei:
Literatur/midp-wirelessapps-wp.pdf)
[9] Sun Microsystems, Inc. (2000): Applications for Mobile In”
formation Devices“. URL: http://java.sun.com/products/midp/midpwp.pdf (Datei: Literatur/midpwp.pdf)
15
[10] Knudsen, Jonathan (7.6.2002):
Understanding MIDlet
”
Memory“.
URL:
http://developers.sun.com/techtopics/mobility/midp/ttips/memory/
[Stand:
6.3.2004]
(Datei:
Literatur/Understanding MIDlet Memory.html)
[11] Nokia
Corporation
(9.6.2002):
Debugging
Wireless
”
J2ME™/MIDP Applications: An Introduction“. URL: http://www.forum.nokia.com/main/1,6566,21 10,00.html#java [Stand:
4.2.2004] (Datei: Literatur/DeBugging Wireless J2ME.pdf)
[12] Nokia Corporation (24.6.2002):
Efficient MIDP Pro”
gramming“.
URL:
http://www.forum.nokia.com/main[Stand:
29.1.2004]
(Datei:
/1,6566,21 10,00.html#java
Literatur/Efficient MIDP Programming.pdf)
[13] Nokia Corporation (18.11.2002):
Brief Introduction to
”
Networked MIDlets“. URL: http://www.forum.nokia.com/main/1,6566,21 10,00.html#java [Stand: 30.1.2004] (Datei:
Literatur/Brief Introduction to Networked MIDlets v1 0.pdf)
16
A. Erklärung über die selbstständige
Anfertigung der Arbeit
Ich versichere, dass ich die Facharbeit selbstständig angefertigt und
keine anderen als die angegebenen Hilsmittel benutzt habe. Alle Stellen, die im Wortlaut oder dem Sinn nach anderen Werken entnommen
sind, habe ich in jedem einzelnen Fall unter genauer Angabe der Quellen deutlich als Entlehnung kenntlich gemacht.
Datum
Unterschrift (Johannes Brakensiek)
B. Erläuterungen
In dem Formblatt zu dieser Arbeit wurde gefordert, dass eine Seite 40
Zeilen, 60 Anschläge pro Zeile und ein Zeilenabstand von 1,5 haben
müsse. Mir war es jedoch nicht möglich eine Einstellung zu finden, die
allen Bedingungen gerecht wird. Ich hab deswegen eine Einstellung
mit 40 Zeilen pro Seite, ca. 60 Anschlägen pro Zeile und statt dem
Zeilenabstand von 1,5 eine größere Schrift (14pt) mit standardisiertem
Zeilenabstand gewählt.
B.1. Schrift
Titel von Literatur (wenn nicht in Anführungsstrichen angegeben) und
andere besonders hervorzuhebende Textstellen sind kursiv, Klassennamen, Code- oder Datenteile in Maschinenschrift geschrieben.
B.2. Zitate und Literaturverzeichnis
Da nahezu sämtliche Quellen aus dem Internet stammen, habe ich
an den entsprechenden Stellen zusätzlich zur URL jeweils noch den
Dateinamen bzw. das Verzeichnis mit angegeben, unter welchem die
Quelle auf der beiliegenden CD zu finden ist.
Bei erstem Erwähnen einer Quelle habe ich die notwendigen Informationen mit in der Fußnote angegeben und führe gleichzeitig eine
Zahl in eckigen Klammern ([ ]) ein, welche sich auf die entsprechende Stelle im Literaturverzeichnis bezieht. In Weiterem habe ich dann
nur noch den Quellentitel und die eingeführte Ziffer in der Fußnote
angegeben.
Wenn die Quelle nicht einer Struktur mit Seitenzahlen folgte, wurde
stattdessen der Abschnitt oder der Dateiname (im Unterverzeichnis)
angegeben.
Obwohl ich in diesem Schriftstück nur aus den ersten sieben der 13
angegeben Quellen zitiere bzw. auf diese verweise, habe ich die sechs
weiteren der Korrektheit halber trotzdem aufgeführt, da sie während
des Schreibens des Quelltextes (teilweise recht häufig) als Nachschlagewerke dienten.
B.3. Quelltext
Bei Lesen der letzten zwei Drittel der Arbeit ist es u.U. sinnvoll, den
Programm-Quelltext – welcher auf der beiliegenden CD zu finden ist
– ebenfalls vorliegend zu haben, um den Ausführungen besser folgen
zu können.
B.4. Fortsetzung der Entwicklung
Da von Seiten einiger Schüler ein relativ großes Interesse an dem
Programm Klautor“ bekundet wurde, soll die Entwicklung des Pro”
gramms auch nach Beendigung dieser Arbeit unter den Bedingungen
der GNU General Public License“ fortgeführt werden. Weitere Er”
gebnisse der Entwicklung samt Downloadmöglichkeit der ProgrammDateien werden unter der Internet-Adresse http://klautor.quackes.de
veröffentlich werden.
C. Anhang
C.1. Übersicht über die Klassenstruktur
C.2. Protokoll der Qualitätssicherung zu Version
1.0a1
C.3. Protokoll der Qualitätssicherung zu Version
1.0a2
C.4. CD mit weiterer Dokumentation, Quelltext und
ausführbaren Anwendungen