Facharbeit
Transcrição
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