Privatcafé

Während der Hype um ‘Wireless Java’ so schöne Akronyme wie J2ME, KVM, MIDP und CLDC hervorgebracht hat, ist eine andere Java-Version auf aktuellen mobilen Endgeräten bereits benutzbar. PersonalJava bringt einen großen Teil der Bibliotheken von Java 1.1.8 wie java.awt, java.net, java.rmi und java.sql mit. So ist diese Version heute auf modernen PDAs und Smartphones in der Lage, Programme auszuführen, die vor Jahren noch die gängigen Internet-Browser ausgebremst haben. Leider behandelt Sun ausgerechnet diese Java-Version etwas stiefmütterlich, seit auf der JavaONE 1999 der Slogan ‘one size doesn’t fit all’ die Geburt der Java2-Familie einläutete.

PersonalJava erblickte das erste Mal vor drei Jahren das Licht der Welt. Damals wollte Sun das Java-Konzept auf die eingebetteten Systeme übertragen. Als Ergebnis dieser Bemühungen entstanden EmbeddedJava, JavaCard und PersonalJava. Die von Java her bekannte Klassenbibliothek wurde in zwei Teile zerlegt. Das ‘Mandatory Package’ musste jeder Lizenznehmer implementieren. Zu diesem gehören die APIs java.applet, java.awt und java.net. Hingegen sind java.rmi und java.sql Teil des ‘Optional Package’. Es bleibt den Herstellern überlassen, ob und wie sie diese APIs für ihre Geräte implementierten.

Auf java.sun.com/products/personaljava/ finden sich zwar die üblichen Verdächtigen wie API-Dokumentation und Laufzeitumgebung, aber angepasste Beispielprogramme sind eher spärlich gesät. Der Grund dafür ist wohl der bis vor kurzem anhaltende Run auf die Java2 Microedition (J2ME), die an dieser Stelle [1] schon zu ihrem Recht kam.

Portierung ohne großen Aufwand

Zwei kleine Beispielprogramme demonstrieren die Möglichkeiten dieser Java-Version. Das erste zeigt, wie einfach sich manche Anwendungen, die noch aus Java 1.1.x-Zeiten stammen, auf PersonalJava portieren lassen. Hier geht es um das Programm DocReader zum Lesen und Anzeigen des verbreiteten PalmDOC-Formats. Dieses erfreut sich unter Palm-Besitzern nicht zuletzt deshalb großer Beliebtheit, weil für viele Rechnerplattformen kostenlose Konvertierer vorhanden sind, die das Format erzeugen können.

Mit geeigneten Konvertierungsprogrammen für Mac oder Windows (siehe ‘PersonalJava im Web’), sind so zum Beispiel die E-Texte des Projekt-Gutenberg auf dem iPAQ oder dem Communicator zu lesen. Trotz einheitlicher Programmiersprache muss man auf Gerätespezifisches achten. Bei den hier gezeigten Beispielen sind dies nur die Display-Auflösung und die Anordnung der GUI-Elemente. Um sicher zu gehen, dass wirklich nur Aufrufe der Java1.1.x-API vorkommen, empfiehlt es sich entweder, auf den JavaChecker von Sun oder einfach auf ein älteres Java-SDK zurückzugreifen. Unter java.sun.com/products/jdk/1.1/ bietet Sun nach wie vor die Version 1.1.8 für Windows und Solaris an. Nennt man darüber hinaus eine ‘Multi-VM IDE’ sein eigen, etwa Borlands JBuilder Professional, kann man die Programme direkt aus der vertrauten Umgebung heraus auf ihre Kompatibilität testen und erstellen. Dazu reicht es, als ‘Ziel-JDK’ in den Projekteigenschaften diese ältere JVM anzugeben.

Nachdem der Quellcode für den DocReader den ersten Compilerlauf mit dem installierten JDK 1.1.8 überstanden hatte, waren lediglich die Fenstergröße und -positionierung der Anwendung in der Klasse DocReaderView zu modifizieren. Wie für das ‘große’ Java üblich, lassen sich die Bildschirmabmessungen mit der in Zeile 30 aufgerufenen Methode getScreenSize() ermitteln. Um das Anwendungsfester zentriert und hochkant auf dem Bildschirm auszugeben, wurde es ursprünglich mit

setLocation((screenSize.width - 450)/2,
	 (screenSize.height - 500)/2);

positioniert. Dies hat jedoch bei kleinen Bildschirmen keinen Sinn. Diesen Aufruf ersetzt jetzt die Zeile 37 (siehe Listing 1). Damit DocReader das gesamte Display nutzen kann, verwendet das Programm in Zeile 34 eine flexible Größenangabe. An diesem Beispiel zeigt sich, wie sinnvoll Layout-Manager sein können. Das hier verwendete BorderLayout nutzt den vorgefundenen Platz für die Darstellung der einzelnen Widgets immer optimal aus. Leider zahlt man dafür den Preis, dass Java-Anwendungen keinem GUI-Design-Guide mehr entsprechen. Bliebe als Letztes, die Größe und Art der verwendeten Schrift zu bestimmen. Auch dafür könnte man sich sicherlich einen schlauen Algorithmus ausdenken, der die Schriftgröße anhand der Bildschirmgröße wählt. Doch gerade dabei kommt es auf den eigenen Geschmack und die persönliche ‘Sehschärfe’ an.

1   public class DocReaderView extends Frame implements Observer {
2   public DocReaderView(DocReaderCtrl controller) {
3     setLayout(new BorderLayout());
4
5   // erzeugt die Menübuttons
6   Panel buttonPanel = new Panel(new GridLayout(1, 6));
7   openButton = createAddButton("Open", controller, buttonPanel);
8   searchButton = createAddButton("Search", controller, buttonPanel);
9   bmkButton = createAddButton("Bookmarks", controller, buttonPanel);
10  topButton = createAddButton("Top", controller, buttonPanel);
11  bottomButton = createAddButton("Bottom", controller, buttonPanel);
12  quitButton = createAddButton("Quit", controller, buttonPanel);
13  add(buttonPanel, BorderLayout.NORTH);
14
15  // erzeugt die TextArea und registriert den KeyListener
16  textArea = new TextWidget();
17  textArea.addKeyListener(controller);
18  add(textArea, BorderLayout.CENTER);
19
20  // erzeugt das Statuslabel
21  statusLine = new Label(" Written by Christopher Y. Wong, 
22               ported by Ramon Wartala");
23  add(statusLine, BorderLayout.SOUTH);
24  // ein Scrollbar für den Text
25  scrollbar = new Scrollbar(Scrollbar.VERTICAL);
26  scrollbar.addAdjustmentListener(controller);
27  add(scrollbar, BorderLayout.EAST);
28
29  // Ermittlung der Display-Auflösung
30  Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
31  setTitle("Doc Reader for Nokia9210");
32    
33  // setzen der Fenstergröße
34  setSize(screenSize.width,screenSize.height);
35    
36  //setzen der Fensterposition
37  setLocation(0,0);
38  addComponentListener(controller);
39
40  viewBounds = new ViewBounds(textArea);
41}

XML-Parser für Kleingeräte

Das zweite Beispiel realisiert eine etwas grafiklastigere Anwendung. Im Zusammenspiel mit dem kXML-Paket von Stefan Haustein, das unter anderem im Enhydra-Projekt zum Einsatz kommt, soll eine einfache Anwendung erstellt werden. Ausgehend von einem selbst definierten XML-Format berechnet und zeichnet sie eine simple Tortengrafik. Zum Analysieren des XML-Formats wären JAXP oder Apaches Xerces sicherlich überdimensioniert. Mit dem in kXML implementierten Event-Ansatz lassen sich aber schnell und einfach eigene XML-Parser erstellen. Zum einfacheren Verständnis prüft die eigentliche Parsing-Methode getChartItems() der Java-Klasse xmlChartParser die ausgelesenen Werte nicht auf Plausibilität. Das einzulesende XML-Format enthält Informationen über die Beschriftung, den Wert und die Farbe eines Tortenstücks. Man kann dieses Dateiformat mit einem einfachen Texteditor auch auf dem Gerät selber modifizieren. Der vollständige Quellcode ist auf dem iX-Listingsserver erhältlich.

<?xml version="1.0" encoding='iso-8859-1'?>
<simple_chart title="Piechart 1">
  <chart_item>
    <label>10.000</label>
    <value>10.0</value>
    <color scheme="RGB">255,0,0</color>
  </chart_item>
  <chart_item>
    <label>70.000</label>
    <value>70.0</value>
    <color scheme="RGB">0,255,0</color>
  </chart_item>
  <chart_item>
    <label>20.000</label>
    <value>20.0</value>
    <color scheme="RGB">0,0,255</color>
  </chart_item>
</simple_chart>

Wie bei eingebetteten Systemen üblich, findet die Hauptentwicklungsarbeit auf einem leistungsfähigen System und das Testen innerhalb von Emulatoren statt. Dem folgt die Installation auf dem Zielgerät.

Nokia verteilt gegen eine kostenlose Registrierung unter forum.nokia.com/main.html ein SDK für Windows NT/2000, das neben der üblichen Dokumentation einen speziellen Emulator mitbringt, der dem eigentlichen Smartphone zum Verwechseln ähnlich sieht. Die Installation eigener Java-Programme setzt ein wenig Aufwand voraus, da Nokia das von Epoc her bekannte Installationsformat SIS vorgesehen hat. Mit dem AIFBuilder (AIF steht in der Epoc-Welt für Application Information File) können diese Packages jedoch relativ komfortabel zusammengesetzt werden. Folgende Informationen und Dateien sind dafür erforderlich:

• Pkg-Datei, die das Ziel und die einzelnen Komponenten des zu installierenden Programms enthält. Für das Beispielprogramm xmlPieChart kann diese Datei wie folgt aussehen:
  #{"xmlPieChart"},(0x10001123),1,0,0\TYPE=SISAPP
"xmlPieChart.aif"-"!:\system\apps\xmlPieChart\xmlPieChart.aif"
"xmlPieChart.txt"-"!:\system\apps\xmlPieChart\xmlPieChart.txt"
"xmlPieChart.app"-"!:\system\apps\xmlPieChart\xmlPieChart.app"
"xmlPieChart.jar"-"!:\system\apps\xmlPieChart\xmlPieChart.jar"
Die erste Zeile nimmt den Namen der Applikation und deren ID auf. Die folgenden geben die benötigten Dateien und das Zielverzeichnis der Installation an. Das Ausrufungszeichen wird bei der Installation durch das Ziel’laufwerk’ ersetzt (Hauptspeicher oder MultiMediaCard).
  
• Die Datei xmlPieChart.txt erhält die für den Aufruf der Applikation nötigen Kommandozeilen-Parameter. Befinden sich alle Klassen- und Ressourcen-Dateien in einem JAR-Archiv, kann man die dort enthaltene Start-Klasse so aufrufen:
  -cp xmlPieChart.jar xmlPieChart
  
• Jede Applikation benötigt zwei Icons mit 64x60 beziehungsweise 25x20 Pixeln, um innerhalb des Extra-Menüs sowohl in der Listen- als auch in der Symbol-Ansicht zu erscheinen. Für deren Erstellung kann man zwar den AIFBuilder verwenden, komfortabler geht es jedoch mit einem gängigen Grafikprogramm und einem geeigneten Konverter, der das MBM-Format (Multi-Bitmap) versteht.

Sind alle Dateien erzeugt, baut das Kommandozeilenprogramm makesis die endgültige Installationsdatei:

makesis.exe -v xmlPieChart.pkg xmlPieChart.SIS

Mit Hilfe der PC-Suite lässt sich die entstandene SIS-Datei nun auf dem Communicator installieren.

Hürden auf dem Smartphone

Viele Vorankündigen zum Nokia 9210 gingen noch davon aus, dass man dort Applets innerhalb des Browsers ausführen könnte. Dass diese Funktion im endgültigen Produkt nicht existiert, liegt vermutlich an der geringen Speicherausstattung. Leider fehlt auch ein einfacher Appletviewer. Für ein weiteres ‘Versäumnis’ kann man allerdings keine wirkliche Entschuldigung finden. Um die in der SDK-Dokumentation beschriebenen Crystal-AWT-Erweiterungen nutzen zu können, fehlen auf dem Communicator die nötigen Java-Klassen. Dafür müsste sich die Datei CAWT.jar in System\Java\ext auf dem Gerät befinden. Ohne sie lassen sich native Erweiterungen wie die Communicator-typischen ‘Display-Buttons’ am rechten Rand des Bildschirms oder der virtuelle Cursor nicht implementieren. Ein weiteres Problem stellt die Ausgabe der Streams System.out und System.err dar. Da die JVM nach der Beendigung einer Java-Anwendung nicht auf ein Konsolen-Fenster zurückkehrt, sind textbasierte Anwendungen ebenso wenig möglich wie die Fehlersuche per print-Aufruf. Glücklicherweise lässt sich diese Funktion mit Hilfe der SDK-CD nachrüsten. In <Installationsverzeichnis>\NokiaJava\erj\tools\redirect befindet sich die Installationsdatei Redirect.SIS. Nach erfolgreicher Installation und Start auf dem 9210 werden alle Ausgabeströme der eigenen Java-Anwendung auf dieses Fenster umgeleitet.

Auch für Compaqs iPAQ gibt es eine PersonalJava-konforme VM. Leider findet man nur wenig Dokumentation zu der Jeode-Architektur von Insignia. So ist der neugierige Entwickler auf sich selbst gestellt oder muss Diskussionsforen nach Neuigkeiten abklappern (siehe ‘PersonalJava im Web’). Die JeodeRuntime bekommt man zwar nicht kostenlos, doch ist der Preis von circa 19 US-$ zu verschmerzen, wenn man wirklich ernsthafte Applikationen für diesen PDA erstellen möchte. Im Gegensatz zu Suns kostenloser Vorabversion einer StrongARM-JVM ist diese Software keine Betaversion und läuft auch als Plugin innerhalb von Microsofts Pocket Internet Explorer.

Verknüpfung für einfaches Starten

Etwas schwierig gestalten sich auf dem iPAQ Installation und Start komplexerer Programme, da die JVM nur via Kommandozeile benutzbar ist. Natürlich möchte man eigene Java-Applikationen wie jedes andere WindowsCE-Programm starten können. Dazu ist ein kleiner Trick notwendig, der nur über einen angeschlossenen PC und ein gestartetes ActiveSync funktioniert. Mit dem geöffneten Datei-Explorer erzeugt man auf dem PocketPC eine Programmverknüpfung. Diese lässt sich auf den Host-PC übertragen und mit einem einfachen Texteditor ändern. Eine solche editierte Verknüpfung könnte für die xmlPieChart-Applikation folgendermaßen aussehen:

56#\windows\evm.exe -cp \windows\lib\xmlPieChart.jar xmlPieChart

An dieser Zeile lässt sich nachvollziehen, in welchem Verzeichnis sich die JAR-Datei der Anwendung befinden muss. Kopiert man die geänderte Verknüpfung wieder auf den iPAQ, ist das Programm dort bequem mit einem Stiftdruck zu starten.

PersonalJava ermöglicht die Anbindung an bestehende Kommunikationsstandards und somit an Enterprise-Lösungen durch die Unterstützung der meisten Java-Bibliotheken. Allerdings um den Preis eines ziemlich großen Ressourcenhungers. Auf Nokias 9210 kann man dies ab und zu an der Meldung ‘Nicht genug Speicher’ feststellen. Um Anwendungen zu erstellen, die sich von ihrem C++-Pendant in der Bedienung nicht mehr unterscheiden, ist zumindest unter Symbians SDK einiges an Arbeit nötig.

Ramon Wartala
arbeitet bei der Firma TEMIS (Text Mining Solutions) Deutschland GmbH in Frankfurt und Paris.

Literatur

[1] Stefan Haustein, Michael Kroll, Ramon Wartala; Palm-Programmierung; Kaffee unter Palmen; Java-Programme für den PalmPilot entwickeln; iX 11/1999, S. 196

(ck)