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.
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 1Datei-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'...}...
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 2Datei-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'...}...
fileConnection = (FileConnection)Connector.open(url)if (!fileConnection.exists()) {fileConnection.create()}
Listing 3Directory 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://///.../ 
