Die Lizenz zum Handy-Zugriff

JSR 75 aka PDA Profile

Lars Röwekamp und Sebastian Szczygiel

Die meisten mobilen Endgeräte stehen heute den klassischen PDAs in Bezug auf Funktionalität und Usability in kaum noch etwas nach. Das Verwalten eines Adressbuchs oder eines Kalenders ist ebenso normal wie das Anlegen einer To-do-Liste. Und auch ein komplexes Dateisystem mit mehreren hundert Megabyte ist dank moderner Speicherkarten nichts Außergewöhnliches mehr. Umso unsinniger scheint die Tatsache, dass auf diese Daten mit den normalen Bordmitteln der MIDP-Spezifikation derzeit nicht zugegriffen werden kann. Abhilfe schafft erst der im Juni letzten Jahres verabschiedete JSR 75 – PDA Optional Packages for the J2ME Platform.

Stellen Sie sich einmal folgende Situation vor: In wochenlanger Arbeit haben Sie die ultimative, Java-basierte Multimedia-Anwendung für Ihren PC geschrieben – natürlich plattform-unabhängig, wie es sich in guten Entwicklerkreisen gehört. Mit Ihrer Anwendung können Sie Bilder, Sounds und sogar Filme bearbeiten. Eine Email-Funktion zum Versenden fehlt ebenfalls nicht. Doch leider, leider hat die Anwendung einen kleinen Haken. Sie ist nicht in der Lage, auf Ressourcen außerhalb der Applikation zuzugreifen. Oder anders ausgedrückt: Ihre Anwendung kann zwar Bilder, Sound und Filme bearbeiten, diese aber weder aus dem Dateisystem des PCs laden noch dort ablegen. Und auch der Zugriff auf Ihre E-Mail-Adressen ist nicht möglich.

Was für eine PC-Anwendung – Gott sei Dank – völlig abwegig klingen mag, ist auf mobilen Endgeräten unter Verwendung von MIDP 1.x/2.0 leider die Regel. Zwar gibt es das eine oder andere herstellerspezifische API, das Abhilfe schaffen kann, nur sind diese eben hochgradig proprietär und bieten meist nur einen Bruchteil derjenigen Funktionen, die man sich für den Zugriff auf Handy-interne Informationen wünschen würde.

Der lange Weg

Natürlich haben auch die Protagonisten der mobilen Java-APIs, wie z.B. PalmSource, IBM, Nokia, Siemens oder Sony, dieses Manko frühzeitig erkannt und bereits Mitte 2000 damit begonnen, eine entsprechende Lösung für das Problem des fehlenden Ressourcenzugriffs zu spezifizieren. JSR 75 oder JSR 75: PDA Optional Packages for the J2ME Plattform heißt das Zauberwort, welches in Zukunft den Schlüssel zum Erfolg darstellen soll. Ursprünglich eher auf klassische PDAs und deren Fähigkeiten ausgerichtet, soll der JSR 75 mithilfe von zwei unabhängigen, optionalen Packages die J2ME Conected Limited Device Configuration (CLDC) derart erweitern, dass sowohl ein Zugriff auf das Dateisystem von mobilen Endgeräten ermöglicht wird als auch auf deren Personal Information Management (PIM) System:

  • FileConnection API (FC): Das FC API ermöglicht den lesenden und schreibenden Zugriff auf das Dateisystem des mobilen Endgerätes. Primäres Ziel ist dabei die Unterstützung von Wechseldatenträgern wie CF- oder SD-Karten.
  • Personal Information Management API (PIM): Das PIM API unterstützt den Zugriff und die Bearbeitung von PIM-Daten auf dem mobilen Endgerät. Neben Adressbuch- und Kalenderfunktionen werden auch To-do-Listen berücksichtigt.

Bei beiden APIs handelt es sich um so genannte Vendor Supplied Libraries, was letztendlich bedeutet, dass sie herstellerspezifisch sind und daher nicht einfach mit einer J2ME-Applikation im Bundle auf ein mobiles Device übertragen werden können. Der Grund hierfür ist nahe liegend. Die APIs bilden einen Wrapper zwischen der neutralen J2ME-Anwendungswelt und der herstellerspezifischen Implementierung des File and Personal Information Management System.

Anders als in der nichtmobilen Welt, ist die Umsetzung und Veröffentlichung einer API-Spezifikation auf einem realen, mobilen Device mit nicht unerheblichen Kosten verbunden. Dies gilt insbesondere dann, wenn noch mit Änderungen an der Spezifikation zu rechnen ist. Daher verwundert es nicht, dass sich die meisten Hersteller zunächst diskret zurückgehalten haben und erst im Sommer letzten Jahres – pünktlich zur Veröffentlichung des JSR 75 Final Release, d.h. knapp vier Jahre nach dessen Start – die ersten JSR 75-konformen Endgeräte angekündigt wurden. Mittlerweile gibt es die ersten Geräte zu kaufen und eine Reihe weiterer Ankündigungen verschiedenster Hersteller stehen im Raum.

Im folgenden Verlauf des Artikels sollen die beiden optionalen Packages des JSR im Detail vorgestellt werden.

FileConnection API

Wie bereits weiter oben beschrieben, soll das FileConnection API den Zugriff auf das File-System eines mobilen Devices ermöglichen. Neben dem Zugriff auf lokale Laufwerke steht dabei laut Spezifikation vor allem auch derjenige auf gemountete Laufwerke – also Wechseldatenträger – im Fokus. Neben SmartMedia, CompactFlash und Secure Digital Cards sieht die Spezifikation zusätzlich die Unterstützung von MultiMediaCards und Memory Sticks vor, womit der größte Teil der relevanten Datenträgern abgedeckt sein sollte.

Eine der wesentlichen Grundideen des FC API liegt in der Nutzung des bereits aus der CLDC bekannten Generic Connection Frameworks (GCF) [Enrique C. Ortiz: The Generic Connection Framework]. Zwar ist der Zugriff auf das Dateisystem mittels GCF theoretisch auch ohne FC API Optional Package möglich, das FC API bietet aber im Vergleich zur „Old-School“-Variante einen standardisierten Weg an und erlaubt darüber hinaus eine ganze Reihe zusätzlicher Funktionen.

Bei der ersten Variante können mithilfe von InputConnection, OutputConnection und StreamConnection lesende, schreibende oder aber beidseitige Zugriffe auf Dateien hergestellt werden. Voraussetzung hierfür ist, dass das jeweilige Device den Protokolltyp file: unterstützt. Listing 1 zeigt exemplarisch Quellcode, der versucht, lesend auf eine Datei namens JavaMagazin.txt zuzugreifen.

Listing 1
Datei-Zugriff - "Old School"-Variante
----------------------------------------------------------------
...
import javax.mircoedition.io.Connector; 
import javax.mircoedition.io.InputConnection; 
import javax.mircoedition.io.IOException; 

String fileUrl = "file:///JavaMagazin.txt";
InputConnection inConnection = null;

try {
  inConnection = (InputConnection)Conector.open(fileUrl, Connector.READ_ONLY);
} catch (IOException) {
  // handle 'file not found'
  ...
}
...

Ein wenig anders sieht es aus, wenn das genutzte Device das FC Optional Package [Eric Giguere: An Overview of the FC OP] unterstützt. In diesem Fall liefert die Angabe des Protokolltyps file: automatisch eine FileConnection zurück, welche sich von der StreamConnection ableitet. Bereits hier gibt es den ersten Unterschied zur reinen GFC-Variante. Sollte eine angegebene URL auf dem System nicht vorhanden sein, liefert das FC API trotzdem bewusst eine FileConnection zurück, anstatt – wie von dem GFC gewohnt – eine IOException zu werfen. Der Grund hierfür liegt auf der Hand. Da das FC API die Manipulation von Dateien und Verzeichnissen erlaubt, wird über diesen Weg ein Mittel geliefert, um eben diese neu anlegen zu können.

Um vorab zu testen, ob ein System das optionale FC API unterstützt, kann die entsprechende Fähigkeit mithilfe einer System-Property namens microedition.io.file.FileConnection.version abgefragt werden, welche derzeit den Wert 1.0 besitzen muss. Listing 2 zeigt den gleichen Dateizugriff wie in Listing 1 unter Verwendung das FC API und ergänzt um den Test der oben angegebenen System-Property.

Listing 2
Datei-Zugriff - FC-API-Variante
----------------------------------------------------------------
...
import javax.mircoedition.io.Connector; 
import javax.mircoedition.io.FileConnection; 
import javax.mircoedition.io.IOException; 


String versionId =
  System.getProperty("microedition.io.file.FileConnection.version");
String fileUrl = "file:///JavaMagazin.txt" ;
FileConnection fileConnection = null ;

if ("1.0".equals(versionId) {
  try {
    fileConnection = (FileConnection)Connector.open(url);
    if (!fileConnection.exists()) {
      fileConnection.create();
    }
    ...
  } catch (IOException) {
    // handle 'io issues'    
    ...
  } catch (SecurityException ex) {
    // handle 'security issue'    
    ...
  }
} else {
   // handle 'no FC Optional Package support' 
   ...
}
...

Wo aber liegt nun der eigentliche Vorteil der FileConnection gegenüber ihrem klassischen Pendant? Ein wesentlicher Vorteil ist in der stark vereinfachten Art und Weise gegeben, mit der sowohl Dateien als auch Verzeichnisse gelesen und manipuliert werden können. Ein erstes Beispiel hierfür findet sich bereits in Listing 2. Mithilfe der Quellcode-Passage

fileConnection = (FileConnection)Connector.open(url)
if (!fileConnection.exists()) {
   fileConnection.create()
}

wird getestet, ob die zu öffnende Datei auf dem System vorhanden ist. Ist dies nicht der Fall, wird sie einfach durch den Befehl create() neu erstellt. Ein weiteres Beispiel zeigt das Listing 3, mit dessen Hilfe ein Dateibrowser realisiert werden kann. Ausgehend von dem Verzeichnis myPic auf dem Speichermedium CF Card werden in dem Beispiel alle Verzeichnis- und Dateinamen ermittelt und zur weiteren Bearbeitung bereitgestellt.

Listing 3
Directory Browse
----------------------------------------------------------------
...
import javax.mircoedition.io.Connector; 
import javax.mircoedition.io.FileConnection; 
import javax.mircoedition.io.IOException; 


String fileUrl = "file:///CFCard/myPics";
FileConnection fileConnection = null;
Enumeration fileNameList = null; 
String fileName = null; 

try {
  fileConnection = (FileConnection)Connector.open(url);
  if (fileConnection.isDirectory()) {
     fileNameList = fileConnection.list();    
     while (fileNameList.hasMoreElements()) {
       fileName = (String)fileNameList.nextElement();
       ...           
     }
  } else {
     // handle 'file is not a directory'    
     ...    
  }
} catch (IOException ex) {
    // handle 'io issues'    
    ...
} catch (SecurityException ex) {
    // handle 'no permission to read'    
    ...
}
...
Der Weg ist das Ziel

Wie bereits weiter oben beschrieben und durch das obige Beispiel noch einmal verdeutlicht, kann nicht nur auf das lokale Dateisystem eines mobilen Devices zugegriffen werden, sondern auch auf verschiedene Wechselmedien. Ermöglicht wird dies durch den GCF-Protokollansatz. Zum Öffnen einer Connetion wird der statischen Methode open() der Connector-Klasse lediglich eine URL im „richtigen Format“ übergeben und schon liefert der Connector die gewünschte Art der Connetion zurück. Was aber bedeutet der Ausdruck „richtiges Format“ im Zusammenhang mit einer FileConnection. Zunächst einmal gilt, dass die URL folgender Syntax entsprechen muss file:/// und somit den Angaben in Abschnitt 3.10 des RFC 1738 (1738.txt RFC 1738: Uniform Resource Locators) entspricht. In der obigen URL-Syntax ist der voll qualifizierte Domain-Name des Systems und eine Pfadangabe auf diesem System gemäß dem Schema ///.../. Eine FileConnection definiert somit stets das erste Verzeichnis als Root. Die Werte hierfür sind geräteabhängig. Garantiert wird lediglich, dass jeder Name pro Gerät nur einmal vorkommen darf.

Geschrieben von
Lars Röwekamp und Sebastian Szczygiel
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.