Neues von der Diplomarbeit

Nachdem ich im letzten Artikel berichtet hatte, daß sich das letzte große Problem erledigt hatte, konnte ich mich beruhigt wieder daran machen, das Programm weiter zu implementieren. Wir erinnern uns: Dadurch, daß ich jetzt JNI zur Sound-Aufnahme und -Wiedergabe verwenden werde, muß ich eine andere Java-VM verwenden. Habe ich vorher eine stark abgespeckte und sehr schlanke CLDC/MIDP-Variante verwendet, so mußte ich die dort schon realisierten Elemente nun für die CDC/PP-Version portieren.
Das betraf glücklicherweise nur sehr wenige Teile. Als erstes war das die Startmethode. So werden mit CLDC sogenannte Midlets programmiert, kleine Java-Applikatiönchen ähnlich im Browser ablaufenden Applets. Dies sind beides sozusagen die vordefinierten “Rahmen”, die schon einige Methoden mitbringen. Bei CDC werden allerdings vollwertige Java-Programme entwickelt, wodurch sich die Startprozedur geringfügig unterscheidet.


Hier das Startmenü

Als zweites betraf die Portierung die Grafik. Bei CLDC gibt es, ich habe es schonmal beschrieben, eine High-Level-Methode (Formulare bestehend aus Text-Boxen, Labels, Text-Areas, Checkboxen und Buttons) sowie eine Low-Level-Methode (Pixelgenau geometrische Objekte und Text auf das Display zeichnen. CDC unterstützt die Grafik-API AWT (Abstract Window Toolkit) von Java als High-Level-Variante sowie ebenso eine Low-Level-Variante wie bei CLDC. Das bedeutet, ich mußte nur die Formulare umbauen und konnte den schon entwickelten Part für den Hauptschirm komplett übernehmen, worüber ich sehr erleichtert war. Im Folgenden das Formular für das Benutzerprofil.

Als letztes mußte ich die Kommunikationsklassen leicht anpassen, da CDC beziehungsweise das vollwertige Java andere Methoden- und Klassenbezeichnungen verwendet. Die Funktionalität ist ansonsten aber sehr ähnlich, so daß ich hier auch keine großen Mühen hatte.

Nachdem die Portierung abgeschlossen war, konnte ich mich um die Weiterentwicklung kümmern. Wir erinnern uns: Das Programm soll einen Besucher durch eine Ausstellung führen. Dazu müssen Vorschläge für Exponate inklusive deren Kurzbeschreibung ebenso präsentiert werden können wie die erläuternden Medien für die Exponate selber, wobei es sich um Texte, Grafiken und auditiven Content handelt. Videos sind in meiner Arbeit (glücklicherweise) erst einmal nicht vorgesehen – wäre aber sicher auch ein netter Bonus zum Schluss. 😉

Der damalige Stand des Programms war, daß die Präsentation der Vorschläge schon funktionierte, allerdings nur als Titel. Für die Kurzbeschreibung, also einen ausführlichen Text, fehlte noch die Implementation. An sich hört es sich nicht weiter kompliziert an, einen Text auf dem Bildschirm angemessen anzuzeigen. Theoretisch ist das auch der Fall, wenn High-Level-APIs verwendet werden. Da ich aber für den Hauptschirm Low-Level jedes Element selbst pixelgenau auf den Schirm zeichnen muss, bin ich auch dafür zuständig, daß von (X1,Y1) bis (X2,Y2) ein Fenster eingezeichnet, von (X1,Y1) bis (X3,Y3) eine Titelzeile, in selbige der Titel des Fensters und im Contentbereich, dessen Grenzen ich errechnen muß, der Text eingezeichnet wird.

Letzteres hört sich trivial an, aber das ist es wieder nicht. 😉 Der Text liegt als langer String vor, aber das Fenster ist ja nicht beliebig breit, sondern hat nach rechts eine Grenze. Würde der String so eingezeichnet wie er vorliegt, ergäbe das eine lange Zeile, die irgendwann nach rechts aus dem Bildschirm läuft. Also mußte ich einen Umbruch programmieren. Dazu wiederum mußte ich den String an den Stellen, an denen ein Umbruch erfolgen darf, aufsplitten in ein Array – der Einfachheit halber an jeder Position, an der ein Leerzeichen vorkommt. Daraufhin mußte ich einen Algorithmus bauen, der sich um den Umbruch selbst kümmert. Das habe ich dann immerhin in relativ kurzer Zeit auch geschafft. Im Folgenden ein Bild vom Hauptfenster und darin ein sehr kurzer Text, der den Umbruch demonstriert. Es klappt ansonsten auch mit längeren Texten. 😉 Außerdem werden die schwarzen Kästchen noch mit Icons ausgetauscht.

Ein sehr einfacher Algorithmus für den Umbruch: Füge solange Wörter aus dem Array einer Zeile hinzu und ermittle laufend die Länge des Textes, bis die Zeile länger ist als das Fenster breit. Lass das letzte Wort fallen und zeichne die Zeile. Danach kümmer Dich um die nächste Zeile usw., so lange bis keine Zeile mehr hinzugefügt werden kann, weil kein Platz mehr vorhanden. Gib im letzteren Fall einen Button zum blättern.

Diese Funktion brauche ich natürlich auch für die Anzeige von jeglichem längeren textuellen Content, weswegen ich mit dem Algorithmus die Anzeige der textuellen Erklärungen für die Exponate mit erschlagen habe. 🙂 Danach machte mich an das Einladen und Anzeigen von Bildern. Auch nicht so einfach, denn Bilder sind oft genug größer als der zur Verfügung stehende Platz. Das hat zur Folge, daß ich mich auch noch um das Skalieren der Bilder auf Fensterbreite kümmern mußte, sofern sie größer sind als die Fensterbreite. Irgendwann war aber auch das geschafft. 🙂 Im Folgenden ein Bild, das in der Breite größer ist als das Fenster und das deswegen in der Breite auf die Fensterbreite skaliert wird. Die Höhe wird im Verhältnis natürlich mitskaliert. Da das Display des PDAs recht klein ist, werde ich wohl noch eine Funktion einbauen, mit der auf Klick auf das Bild selbiges vergrößert oder gar in Originalgröße präsentiert wird.

Außerdem habe ich das zweite Kapitel meiner Diplomarbeit in Rohfassung zu Ende geschrieben. Dieses liegt nun bei meinem Betreuer zur Korrektur. 🙂 Aktuell sitze ich am dritten Kapitel von insgesamt sieben.

Keine Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird niemals weitergegeben.Erforderliche Felder sind mit einem * markiert.