Die Ermittlung der Blutalkohol-Konzentration (BAK) ist ein Thema, das schon sehr viele Menschen beschäftigt hat. Schon 1932 hat Widmark eine Formel aufgestellt, die eine Berechnung der maximalen BAK ermöglicht. Da eine Berechnung der BAK aber oft gerade dann gefragt ist, wenn kein Computer in der Nähe ist, ist der mobile Promille-Rechner für das Mobiltelefon eine echte Alternative.

Berechnung der Blutalkohol-Konzentration mit der Widmark-Formel

Die Beziehung zwischen der aufgenommenen Alkoholmenge und der BAK zu einem beliebigen Zeitpunkt ist von den Faktoren Gewicht, Geschlecht und Zeitpunkt der getrunkenen Alkoholmenge abhängig. Diese Beziehung wird in der Widmark-Formel dargestellt.

1. Widmark-Formel
2. c = A / (p * r)
3. c = Alkoholkonzentration in Promille
4. A = Aufgenommene Alkoholmenge in Gramm
5. p = Körpergewicht in Kilogramm
6. r = Reduktionsfaktor (0,7 bei Männern und 0,6 bei Frauen)

Da Alkohol wasserlöslich ist, kann er sich nur mit dem Wasseranteil des Körpers vermischen. Der Reduktionsfaktor reduziert das Körpergewicht zu diesem Zweck auf die Wassermenge, die laut Widmark bei Männern 70 Prozent und bei Frauen 60 Prozent beträgt. Die effektive Alkoholmenge wird mit der Alkoholmengenformel berechnet.

1. Alkoholmengenformel
2. A = m * Vol% * s * rp
3. A = Aufgenommene Alkoholmenge in Gramm
4. m = Getrunkene Menge in Liter
5. s = Spezifisches Gewicht von Alkohol (0,79)
6. rp = Resorptionsdefizit (0,9)

Beim Resorptionsdefizit handelt es sich um eine Konstante, die angibt wie viel Alkohol von der getrunkenen Alkoholmenge wirklich aufgenommen wurde, da Alkohol nach der Aufnahme teilweise wieder ausgeschieden wird, ohne den Körper zu belasten.
Im Schnitt baut der Körper 0,1 Promille pro Stunde ab. Da der Abbau nicht sofort beginnt, muss noch eine Karenz von bis zu zwei Stunden berücksichtigt werden. Mit diesen Angaben ist es nun möglich, eine Anwendung zu realisieren, die es ermöglicht, jederzeit die aktuelle Blutalkohol-Konzentration auf Basis der Widmark-Formel zu errechnen.

Manie und Machbarkeit

Diese Berechnungsgrundlage könnte nun als WAP-Applikation realisiert werden und mit dem Handy von unterwegs jederzeit aufgerufen werden. Doch die bekannten Nachteile von WAP, die aus dem Hype einen Flop haben werden lassen, können mit einer J2ME-Anwendung auf einfache Weise gelöst werden. Da zusätzlich zur Oberfläche auch die Logik und die Datenbank auf dem Handy realisiert werden, gibt es keine Verbindungskosten, keine langsame Einwahl oder niedrige Übertragungsgeschwindigkeiten. Alles in allem belaufen sich die Betriebskosten unabhängig von der Nutzungsdauer also auf 0,0 .

Von der Idee zum MIDlet

Ein MIDlet besteht aus mindestens zwei Dateien, dem Java Application Descriptor (Jad-Datei) und den Java- Klassen, die entweder in einer Jar-Datei oder in den Class-Dateien enthalten sind. In der Jar-Datei können zusätzlich zu den Java-Klassen auch Bilder und sonstige Bestandteile des Programms abgelegt werden.
Die Entwicklung eines MIDlets unterscheidet sich von der Entwicklung eines Applets oder einer Applikation nur in dem geänderten API und in dem leicht abgewandelten Entwicklungsprozess. Der typische Entwicklungsprozess gliedert sich in die folgenden Schritte:

• Umsetzung der Idee in Java mit dem speziellen J2ME API
• Kompilieren der Klassen
• Preverifying
• (Optional) Packen der Klassen in eine Jar-Datei
• Testen der Anwendung
• (Optional) Code-Protection
• Ausführen der Anwendung

Einzig der Punkt Preverifying ist neu hinzugekommen und sollte den Entwickler nicht abschrecken. Das Preverifying ist nötig, da in der CLDC-Spezifikation des J2ME-Verification-Konzepts vorgeschrieben wird, dass jede Klasse vor der Installation geprüft werden muss.

Am Anfang steht der Sourcecode

Die Pakete des J2ME APIs entsprechen weitestgehend den wichtigsten Paketen, die schon aus der Java 2- Standard-Edition bekannt sind. Wesentliche Unterschiede gibt es nur bei der grafischen Bedienoberfläche und der IO-Funktionalität. Das Reflection API wurde in der Micro Edition von Java 2 komplett ausgespart, da die Geräte damit nur unnötig belastet wären.
Um den Promille-Rechner zu implementieren, sind eine ganze Reihe von Funktionen nötig. Als Erstes muss der Anwender seine persönlichen Daten eingeben, hierzu gehören Geschlecht, Gewicht und der Name des Anwenders. Um das Programm schon für andere Berechnungsgrundlagen vorzubereiten, ist es denkbar auch noch die Größe einzugeben. Sind diese Daten gespeichert, muss das Trinkverhalten nachvollzogen werden können. Menge, Zeitpunkt und Vol% der Getränke sollten möglichst genau eingegeben werden können, um eine präzise Berechnung der BAK zu ermöglichen. Last but not least eine Funktion, um die Blutalkohol-Konzentration zu einem bestimmten Zeitpunkt zu errechnen. Der komplette Ablauf ist in Abpictureung 1 skizziert, nicht berücksichtigt sind hierbei Abbruchfunktionen und das Beenden des Programms. Die vielen kleinen Formulare in Abpictureung 1 sind eine Designentscheidung. Es ist genauso gut möglich, mehrere Eingaben in einem Formular abzuhandeln, statt von Eingabefeld zu Eingabefeld zu springen. Doch die Erfahrung mit WAP zeigt, dass es meistens bedienerfreundlicher ist, nur ein Eingabefeld pro Formular zu zeigen und den Anwender dann Schritt für Schritt durch das Formular zu führen.

Die MIDlet-Elemente

Javax.microedition.midlet. ist die Klasse, in der die Methoden zum Starten, Beenden und Unterbrechen des Programms definiert sind. Von dieser Klasse erbt das zentrale Objekt, in dem die komplette Navigation durch die Anwendung definiert und gleichzeitig die Schnittstelle zur Persistenz realisiert ist. Alle persistenten Daten werden im so genannten Record-Management-System gespeichert. Dieses System ist in dem Package javax.microedition.rms untergebracht, dass eine Hand voll Klassen bereitstellt um Records auf dem Datenträger zu speichern und jederzeit wieder abzurufen.
Im RMS werden sowohl die persönlichen Daten als auch die getrunkene Alkoholmenge gespeichert. So ist es ohne Probleme möglich, die Anwendung zwischenzeitlich zu verlassen, z.B. um eine SMS zu verschicken, ohne dass vorher eingegebene Daten verloren gehen.

Das GUI

Die komplette Applikation besteht aus vielen Dialogen, die sich größtenteils nur im Detail unterscheiden. Es werden daher nur einige beschrieben, die stellvertretend für die anderen stehen, da eine Beschreibung der kompletten Benutzeroberfläche zu umfangreich ist. Jede Klasse, in der ein Dialog realisiert ist, erbt von einer Klasse aus dem Paket javax.microedition.lcdui. Verwendet werden unter anderem List.class, TextBox.class, Canvas.class und Form.class.
Die Klasse Profile1Form.class erbt von TextBox.class und dient zur Eingabe des Namens. Der Dialog wird zum Anlegen und zum Ändern des Profils verwendet. Auf dem Siemens SL45i wird diese Klasse wie in Abpictureung 2 dargestellt. Die Realisierung dieser Klasse ist in Listing 1 zu sehen. Listing 1

1. import javax.microedition.lcdui.*;
3. public class Profile1Form extends TextBox implements CommandListener
4. {
6. Promi midlet;
7. Command okCommand = new Command ("OK", Command.OK, 0);
8. Command exitCommand = new Command ("Schließen", Command.OK, 0);
10. public Profile1Form (Promi midlet)
11. {
12. super ("Profilname", "", 30, TextField.ANY);
13. this.midlet = midlet;
14. addCommand (okCommand);
15. addCommand (exitCommand);
16. setCommandListener (this);
17. }
19. public void commandAction(Command command, Displayable displayable)
20. {
21. if (command == okCommand)
22. {
23. String name;
24. name = ((Profile1Form)displayable).getString ();
25. midlet.viewProfile2Form (name);
26. }
27. if (command == exitCommand)
28. {
29. midlet.viewMainForm ();
30. }
31. }
32. }

Profile1Form erbt von TextBox eine Klasse, die es dem Anwender ermöglicht, einen Text einzugeben und zu bearbeiten. Eine TextBox hat einen Titel und eine festgelegte Textlänge, die der eingegebene Text nicht überschreiten darf. Zusätzlich ist es möglich, die TextBox noch mit Einschränkungen zu belegen sowie die Eingabe auf Nummern zu beschränken, eine eMail-Adresse zu verlangen oder die Eingabe eines Passwortes zu ermöglichen. In dem Fall wird die Eingabe dann nicht auf dem Display angezeigt.
Zusätzlich zum Eingabefeld werden noch die Kommandos OK und Schließen hinzugefügt. Die Implementierung des CommandListeners mit der Methode commandAction verarbeitet dann die Events der beiden Kommandos. Da sich die Formulare gegenseitig nicht kennen, wird das MIDlet-Objekt verwendet um die Navigation abzupictureen. Drückt der Anwender den OK-Button, wird der eingegebene Name ermittelt und an das MIDlet-Objekt weitergegeben. Der Aufruf des nächsten Formulars erfolgt dann aus der aufgerufenen Methode viewProfile2Form heraus (Listing 2).

Listing 2

1. public void viewProfile2Form (String name)
2. {
3. if (name.length () < 3)
4. {
5. NotificationForm notificationForm;
6. notificationForm = new NotificationForm (this,
7. "Bitte mindestens 3 Zeichen als Profilnamen wählen");
8. Display.getDisplay(this).setCurrent(notificationForm);
9. } else {
10. aktProfile.setName (name);
11. lastForm = DICT_NEWPROFILE2;
12. if (aktProfile.getGeschlecht())
13. {
14. profile2Form.setSelectedIndex(0, true);
15. } else {
16. profile2Form.setSelectedIndex(1, true);
17. }
18. Display.getDisplay(this).setCurrent(profile2Form);
19. }
20. }

Die Methode viewProfile2Form prüft die Eingaben und zeigt dann das Profile2Form an, in dem das Geschlecht ausgewählt wird. Da die viewProfile2Form-Methode sowohl zur Navigation durch den Wizard für das Anlegen eines neuen Benutzers als auch zum Editieren eines bestehenden Benutzers verwendet wird, muss vor der Darstellung noch das vorselektierte Geschlecht ermittelt werden.
Die Klasse Profile2Form ist eine typische Auswahlliste. Dieser Dialog ermöglicht es, ein Geschlecht auszuwählen und mit OK den nächsten Dialog des Wizards aufzurufen. Auf dem Palm V wird der Dialog wie in Abpictureung 3 dargestellt.

Listing 3

1. import javax.microedition.lcdui.*;
3. public class Profile2Form extends List implements CommandListener
4. {
5. Promi midlet;
6. Command exitCommand = new Command ("Schließen",1,0);
7. Command okCommand = new Command ("OK",1,0);
9. public Profile2Form (Promi midlet)
10. {
11. super ("Geschlecht", List.IMPLICIT);
12. this.midlet = midlet;
13. append ("Männlich",null);
14. append ("Weiblich",null);
15. addCommand (exitCommand);
16. addCommand (okCommand);
17. removeCommand (List.SELECT_COMMAND);
18. setCommandListener ( this );
19. }
21. public String getGeschlecht ()
22. {
23. return getString(getSelectedIndex());
24. }
26. public void commandAction(Command command, Displayable displayable)
27. {
28. if (command == okCommand)
29. {
30. String geschlecht;
31. geschlecht = ((Profile2Form)displayable).getGeschlecht();
32. midlet.viewProfile3Form (geschlecht);
33. }
34. if (command == exitCommand)
35. {
36. midlet.viewMainForm ();
37. }
38. }
39. }

List ist, wie der Name schon sagt, eine Liste. Sie ermöglicht die Auswahl eines Eintrags, der mit dem Kommando List Select ausgewählt werden kann. Beim impliziten Listentyp ist das nicht nötig, daher wird das Kommando mit der Methode removeCommand entfernt. Wie bei der TextBox werden die Events in der Methode commandAction des zugewiesenen CommandListeners verarbeitet. Hat der Anwender die Auswahl mit OK bestätigt, wird die Auswahl an das MIDlet-Objekt gegeben und der nächste Dialog des Wizards aufgerufen. Nach der Eingabe des Namens folgt noch die Eingabe des Gewichts und der Größe; am Ende werden die eingegebenen Daten nochmals angezeigt und gespeichert.

Thread-Unterstützung

Rechenintensive Aufgaben und umfangreiche Speicherzugriffe verlangen den momentan verfügbaren Geräten schon eine ganze Menge ab. Auch Siemens hat das erkannt und erhöht beim Start der Java-VM sogar noch die Taktung des Prozessors um die Performance zu erhöhen. Trotz allem gibt es Situationen, in denen das Handy dazu schon mal ein paar Sekunden benötigt - das Speichern eines Profils ist eine solche Situation. Während es im Siemens-Emulator keine Verzögerungen gibt, benötigt das echte SL45i ca. drei bis vier Sekunden um die Daten auf der MultMediaCard zu speichern. Um solche Wartezeiten zu überbrücken, gibt es unter Windows, Linux usw. die von jeher bewährte Sanduhr. Was spricht also dagegen, auch auf dem Handy eine solche Sanduhr anzuzeigen.
In dem API des J2ME-Standards ist im Paket javax.microedition.lcdui die Klasse Canvas realisiert, die es ermöglicht, auf dem kompletten Display des Handys pixelgenau zu zeichnen. Es gibt zusätzlich noch gerätespezifische Erweiterungen zum Zeichnen von Sprites und Ähnlichem von Siemens und Nokia. Die Verwendung dieser Möglichkeiten ist aber mit Vorsicht zu genießen, da die Anwendung dann auf den Hersteller oder sogar ein spezielles Gerät reduziert wird (Listing 4).

Listing 4

1. import javax.microedition.lcdui.*;
3. public class WaitForm extends Canvas implements CommandListener
4. {
5. Promi midlet;
6. Image[] wait;
7. int count = 0;
8. int anz = 9;
9. WaitThread waitThread;
11. public WaitForm (Promi midlet)
12. {
13. this.midlet = midlet;
14. wait = new Image[anz];
15. try {
16. for (int i=1; i <= anz; i++)
17. wait[i-1] = Image.createImage("/images/sand"+i+".png");
18. } catch (IOException e) {}
19. }
21. public void setThread (WaitThread waitThread)
22. {
23. this.waitThread = waitThread;
24. setPriority(Thread.MAX_PRIORITY)
25. waitThread.appStart = false;
26. waitThread.setPriority (Thread.MAX_PRIORITY);
27. }
29. public void paint (Graphics g)
30. {
31. if (waitThread.appStart == false)
32. {
33. waitThread.appStart = true;
34. waitThread.start ();
35. }
36. if (isShown() && waitThread.appStart)
37. {
38. g.setGrayScale (255);
39. g.fillRect (0,0,getWidth(), getHeight());
40. g.setGrayScale (0);
41. g.drawImage (wait[count],10,0,0);
42. g.setFont (Font.getFont (Font.FACE_SYSTEM,.STYLE_PLAIN,.SIZE_MEDIUM));
43. g.drawString ("please wait",5,65,0);
44. count = (count + 1) % anz;
45. try {Thread.sleep (250);} catch (Exception e){}
46. repaint ();
47. }
48. }
49. }

Zwei Threads auszuführen, ist in Java eine leichte Übung. Der WaitThread wird von der Klasse WaitForm ausgeführt, die wiederum die Sanduhr anzeigt. Es werden neun aufeinander folgende Bilder zu einer Animation zusammengefügt. Jedes Bild wird gezeichnet und 250 Millisekunden lang angezeigt, bis die eigentliche Aufgabe im Hintergrund abgearbeitet ist. Natürlich wird die VM durch diese Arbeit zusätzlich belastet, aber in Tests konnte ich keine nennenswerten Unterschiede erkennen. Sowohl mit Sanduhr als auch ohne waren die Wartezeiten größtenteils identisch.

Speichern der Daten im RMS

Da die unterschiedlichen Geräte nicht alle über eine einheitliche Schnittstelle auf ihr Dateisystem zugreifen, stehen im Package javax.microedition.rms einige abstrakte Klassen zur Verfügung. Hiermit wird der Zugriff auf den Datenträger für die unterschiedlichen Geräte vereinheitlicht. Alle zu speichernden Daten werden im RecordStore gespeichert und können mit Hilfe eines RecordEnumeration-Objekts wieder geladen werden. Der Promille-Rechner speichert unterschiedliche Datensatztypen. Für jeden Benutzer wird das Profil gespeichert und für jedes Getränk eines Benutzers wird ein Datensatz gespeichert. Das Speichern eines Datensatzes für ein Getränk geschieht in der Klasse Alkohol. Hierbei ist zu beachten, dass der zu speichernde String UTF kodiert wird (Listing 5).

Listing 5

1. import javax.microedition.rms.*;
2. import java.util.*;
3. import java.io.*;
5. public class Alkohol extends WaitThread
6. {
8. private String trenner = "#~#";
9. private int promille;
10. private String getraenk;
11. private int menge;
12. private String mengenString;
13. private Date trinkZeit;
17. public byte[] getBytes () throws IOException
18. {
19. String alkMenge = "" + (menge * promille * 79);
20. String sBuffer = alkMenge + trenner + trinkZeit.getTime() + trenner + promille +
21. trenner + getraenk + trenner + menge + trenner + mengenString;
22. ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
23. DataOutputStream dataOutputStream = new DataOutputStream (byteArrayOutputStream);
24. dataOutputStream.writeUTF (sBuffer);
25. byte[] buffer = byteArrayOutputStream.toByteArray ();
26. return buffer;
27. }
29. public void save () throws RecordStoreException, IOException
30. {
31. RecordStore recordStore;
32. recordStore = RecordStore.openRecordStore ("profile_" + profile.getId(),true);
33. byte[] buffer;
34. buffer = getBytes ();
35. recordStore.addRecord(buffer,0,buffer.length);
36. recordStore.closeRecordStore ();
37. }
39. }

Kompilieren des MIDlets

Kompilieren eines Midlets unterscheidet sich nur geringfügig vom Übersetzen einer gewöhnlichen Java- Anwendung. Da das API des JDK nicht gültig ist, wird dem Java-Compiler die Jar-Datei des gültigen API übergeben:

1. c:> javac -bootclasspath c:\Pfad\zu\den\MIDP\Klassen Klasse.class

Nachdem eine Klasse fertig übersetzt wurde, ist sie noch nicht fertig zum Gebrauch. Bevor die Klasse auf das Handy kopiert werden kann, muss noch das Preverify-Kommando ausgeführt werden. Dieses Kommando bereitet die Klasse für die Verwendung auf dem J2ME-Gerät vor, ohne die Klasse in der Funktionalität zu verändern - weder der Name noch der programmierte Inhalt werden verändert. Wird eine Klasse auf dem Handy verwendet, die nicht diesen Prozess durchlaufen hat, kann die Klasse entweder nicht gefunden werden oder es erscheint die Meldung ALERT: Error verifying the class NameDerKlasse.
In der Regel besteht eine Anwendung aus mehreren Klassen, die dann zu einer Jar-Datei zusammengefasst werden können. Das Kommando jar kann wie gewohnt auf die fertigen Klassen losgelassen werden:

1. c:> jar cvf promille.jar Klasse1.class Klasse2.class Klasse3.class ....

Eine Jar-Datei allein reicht noch nicht aus, um eine Anwendung ausführen zu können. Nachdem die Jar-Datei fertig ist, muss noch eine Jad-Datei erzeugt werden. Hierzu wird ein Tool verwendet oder die Datei in einem Editor erzeugt. In einer Jad-Datei werden die auszuführende Klasse, die URL der Jar-Datei und einige andere Parameter festgelegt, die für einen korrekten Umgang mit der Jar-Datei nötig sind.

Der Application-Descriptor muss die Erweiterung .jad haben und die folgenden Attribute beinhalten:
MIDlet-Version: Midlet-Version
MIDlet-Vendor: Entwickler des Midlets
MIDlet-Name: Name des Midlets
MIDlet-jar-URL: Die URL unter der die Jar-Datei heruntergeladen werden kann
MIDlet-Jar-Size: Die Anzahl der Bytes der Jar-Datei
MIDlet-1: Dieses Attribut besitzt die Parameter Name, Icon und Klasse

Zusätzlich können noch die folgenden Attribute angegeben werden:
MIDlet-Description: Beschreibung des MIDlets
MIDlet-Icon: Das Icon des Midlets
MIDlet-Info-URL: URL unter der weitere Infos zu dem MIDlet erhältlich sind.
MIDlet-Data-Size: Die minimale Anzahl der Bytes auf dem Datenträger, die von dem Midlet benötigt werden.

Alle anwendungsspezifischen Attribute dürfen nicht mit MDlet- beginnen.

Testen, testen und nochmals testen

In den seltensten Fällen hat man alle Geräte zur Hand, auf denen die Anwendung später ausgeführt werden sollen. Trotz allem ist das Testen einer der wichtigsten Punkte im Softwareentwicklungsprozess - glücklicherweise gibt es die unterschiedlichsten Emulatoren von den Geräteherstellern und von Sun. So gibt es z.B. Emulatoren von Siemens, Nokia, Motorola und Palm, die es ermöglichen die Anwendung auszuführen, ohne entsprechende Hardware anschaffen zu müssen.
Der Test eines MIDlets mit dem Siemens-Emulator ist denkbar einfach. Nach der Installation befindet sich im Installationspfad ein Ordner, in dem sich die Inhalte der Multimedia-Karte des realen Handys befinden. Somit auch die MIDlets, die unter \mmc\java\jam abgelegt werden. In diesem Verzeichnis wird ein neuer Ordner angelegt und sowohl die Jar-Datei als auch die Jad-Datei darin abgelegt. Dabei sollte darauf geachtet werden, keine Umlaute oder Sonderzeichen in dem Verzeichnisnamen zu verwenden, da die Java-VM des Siemens SL45i hiermit noch Probleme hat.

Java Bytecode Protection

Bis auf die Kommentare kann aus den Klassen in der Jar-Datei praktisch der komplette Sourcecode reproduziert werden. Dies zu verhindern ist mit dem Freeware Tool RetroGuard, dass unter der GPL vertrieben wird, möglich. Der Obfuscation-Prozess entfernt alle unnötigen Informationen aus den Klassen. Weiterhin werden Namen von Klassen, Methoden und Variablen in bedeutungslose und möglichst kurze Bezeichner geändert, ohne die Anwendung nach außen zu verändern - hierdurch wird der dekompilierte Java-Code sehr schwer lesbar. Netter Nebeneffekt ist, dass die Klassen sehr viel kleiner werden und Jar-Dateien bis zu 50 Prozent weniger Speicher verbrauchen. Gerade bei stark eingeschränkten Ressourcen wie z.B. in dem Siemens SL45i oder dem Nokia 7650, die nur zwischen 125kB und 150kB Speicher für eine Java-Anwendung bereitstellen, ist ein geringer Speicherverbrauch sehr wichtig.
Bevor RetroGuard ausgeführt wird, muss noch ein Skript für das MIDlet erzeugt werden. In dieser Konfiguration wird dem Tool mitgeteilt, welche Teile der Klassen nicht geändert werden sollen. Normalerweise ist dies die Methode main(String argv[] ) einer Applikation oder die Methoden start(), stop(), destroy(), init() eines Applets. Bei einem MIDlet sind es die Methoden startApp(), pauseApp() und destroyApp() der MIDlet- Klasse. Das komplette Skript für RetroGuard sieht folgendermaßen aus:

1. #
2. # Scriptname: promi.rgs
3. # Script for RetroGuard bytecode obfuscator.
4. # JAR-Datei: promi.jar
5. #
6. .class Promi
7. .method Promi/startApp ()V
8. .method Promi/destroyApp (Z)V
9. .method Promi/pauseApp ()V

Um dieses Skript auszuführen, wird das folgende Kommando in eine DosBox eingegeben:

1. java -classpath API.jar;retroguard.jar RetroGuard promi.jar promiRG.jar promi.rgs

Nachdem das Kommando ausgeführt wurde, ist in der Datei promiRG.jar der Promille-Rechner mit den geschützten Klassen. Da RetroGuard den Preverify-Prozess rückgängig gemacht hat, ist es nötig, die Jar-Datei zu entpacken und nochmals Preverify auf alle Klassen auszuführen. Beim Entpacken fallen gleich die geänderten Klassennamen auf. Typische Klassennamen sind jetzt a.class, b.class, c.class. Genau das Gleiche ist intern auch mit den Methoden und Attributen der Klassen geschehen, ohne dass der Programmablauf verändert wurde. Einzig die Datei Promi.class hat den Namen und die Methoden startApp(), pauseApp() und destroyApp() behalten, wie es in dem Skript promi.rgs beschrieben ist.
Wenn von Anfang an klar ist, dass die Klassen mit einem Obfuscation-Tool geschützt werden, kann das Preverify-Kommando vor dem Packen mit jar übersprungen werden, da die Änderungen vom Retroguard ignoriert werden. Die Datei promiRG.jar ist jetzt nur noch 39kB groß. Im Vergleich zu der 49,1kB großen Datei promi.jar ist das eine Ersparnis von etwas über 20 Prozent. Die relativ geringe Ersparnis ergibt sich durch die Bilddateien in der Jar-Datei, die nicht verändert werden. Trotzdem ist dies schon ein merklicher Unterschied, wenn die Anwendung per WAP über das Over The Air (OTA)-Protokoll heruntergeladen wird.

Fazit

Die technischen Voraussetzungen für die Programmierung moderner Handys in Java sind erfüllt. Bleibt abzuwarten, wann sich diese Technologie durchsetzt - ob Handys demnächst sogar die PDAs ersetzen oder MIDlets nur eine Modeerscheinung sind. Ich persönlich glaube, dass Handys und PDAs nebeneinander existieren werden. Genauso wie programmierbare Handys, wird es in Zukunft auch immer mehr PDAs mit eingebautem Mobiltelefon geben. MIDlets werden dann die Programme sein, die sowohl auf Handys als auch auf PDAs ausgeführt werden können. Auch die Rechenleistung der Geräte wird in Zukunft weiter verbessert, was eine Voraussetzung für immer anspruchsvollere Anwendungen ist; die Vorteile der MIDlets gegenüber WAP liegen klar auf der Hand. Trotzdem bin ich der Meinung, dass WAP von dieser Technologie profitieren wird, da sich WAP und J2ME gegenseitig unterstützen und dadurch eine breitere Akzeptanz gewährleisten.

P.S.: Don't Drink And Drive.

Links und Literatur

• [1] Persistente Datenspeicherung in der J2ME: Javamagazin 12.2001
• [2] Tatzeit BAK: http://www.bads.de/tatzeit-bak.htm
• [3] Palm: www.palm.com
• [4] Sun Wireless Toolkit: java.sun.com/products/j2mewtoolkit/
• [5] Sun Mobil Developer: wireless.java.sun.com
• [6] Forum Nokia: www.forum-nokia.com
• [7] Siemens Mobil: www.siemens-mobile.com
• [8] RetroGuard: www.retrologic.com