Berechnung der Blutalkohol-Konzentration mit dem Mobiltelefon

Mobiler Promille-Rechner

Michael Jentsch

Die Entwickler mobiler Anwendungen sind nicht länger auf Windows CE- und PalmOS-PDAs angewiesen. Mit J2ME hat Sun einen Standard für eingebettete Systeme wie Handys und PDAs definiert; damit wird eine Programmierung dieser Geräte mit Java ermöglicht. Am Beispiel eines Promille-Rechners wird dieser Artikel die Entwicklung einer J2ME-Anwendung Schritt für Schritt erklären, wobei auch auf individuelle Probleme der Geräte eingegangen wird.

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.

Widmark-Formel
c = A / (p * r)
c = Alkoholkonzentration in Promille
A = Aufgenommene Alkoholmenge in Gramm
p = Körpergewicht in Kilogramm
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.

Alkoholmengenformel
A = m * Vol% * s * rp
A = Aufgenommene Alkoholmenge in Gramm
m = Getrunkene Menge in Liter
s = Spezifisches Gewicht von Alkohol (0,79)
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.

Abb. 1: Ablaufdiagramm

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.

Abb. 2: Profil1Form.class auf einem SL45i

Listing 1

import javax.microedition.lcdui.*;

public class Profile1Form extends TextBox implements CommandListener
{

Promi midlet;
Command okCommand = new Command ("OK", Command.OK, 0);
Command exitCommand = new Command ("Schließen", Command.OK, 0);

public Profile1Form (Promi midlet)
{
super ("Profilname", "", 30, TextField.ANY);
this.midlet = midlet;
addCommand (okCommand);
addCommand (exitCommand);
setCommandListener (this);
}

public void commandAction(Command command, Displayable displayable)
{
if (command == okCommand)
{
String name;
name = ((Profile1Form)displayable).getString ();
midlet.viewProfile2Form (name);
}
if (command == exitCommand)
{
midlet.viewMainForm ();
}
}
}

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

public void viewProfile2Form (String name)
{
if (name.length () 

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.

Abb. 3: Profil2Form.class auf einem PalmV

Listing 3

import javax.microedition.lcdui.*;

public class Profile2Form extends List implements CommandListener
{
Promi midlet;
Command exitCommand = new Command ("Schließen",1,0);
Command okCommand = new Command ("OK",1,0);

public Profile2Form (Promi midlet)
{
super ("Geschlecht", List.IMPLICIT);
this.midlet = midlet;
append ("Männlich",null);
append ("Weiblich",null);
addCommand (exitCommand);
addCommand (okCommand);
removeCommand (List.SELECT_COMMAND);
setCommandListener ( this );
}

public String getGeschlecht ()
{
return getString(getSelectedIndex());
}

public void commandAction(Command command, Displayable displayable)
{
if (command == okCommand)
{
String geschlecht;
geschlecht = ((Profile2Form)displayable).getGeschlecht();
midlet.viewProfile3Form (geschlecht);
}
if (command == exitCommand)
{
midlet.viewMainForm ();
}
}
}

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

import javax.microedition.lcdui.*;

public class WaitForm extends Canvas implements CommandListener
{
Promi midlet;
Image[] wait;
int count = 0;
int anz = 9;
WaitThread waitThread;

public WaitForm (Promi midlet)
{
this.midlet = midlet;
wait = new Image[anz];
try {
for (int i=1; i 

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

import javax.microedition.rms.*;
import java.util.*;
import java.io.*;

public class Alkohol extends WaitThread
{

private String trenner = "#~#";
private int promille;
private String getraenk;
private int menge;
private String mengenString;
private Date trinkZeit;



public byte[] getBytes () throws IOException
{
String alkMenge = "" + (menge * promille * 79);
String sBuffer = alkMenge + trenner + trinkZeit.getTime() + trenner + promille +
trenner + getraenk + trenner + menge + trenner + mengenString;
ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
DataOutputStream dataOutputStream = new DataOutputStream (byteArrayOutputStream);
dataOutputStream.writeUTF (sBuffer);
byte[] buffer = byteArrayOutputStream.toByteArray ();
return buffer;
}

public void save () throws RecordStoreException, IOException
{
RecordStore recordStore;
recordStore = RecordStore.openRecordStore ("profile_" + profile.getId(),true);
byte[] buffer;
buffer = getBytes ();
recordStore.addRecord(buffer,0,buffer.length);
recordStore.closeRecordStore ();
}

}

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:

c:> javac -bootclasspath c:PfadzudenMIDPKlassen 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:

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
mmcjavajam 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.

Manie und Machbarkeit

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:

#
# Scriptname: promi.rgs
# Script for RetroGuard bytecode obfuscator.
# JAR-Datei: promi.jar
#
.class Promi
.method Promi/startApp ()V
.method Promi/destroyApp (Z)V
.method Promi/pauseApp ()V

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

Alkoholmengenformel
A = m * Vol% * s * rp
A = Aufgenommene Alkoholmenge in Gramm
m = Getrunkene Menge in Liter
s = Spezifisches Gewicht von Alkohol (0,79)
rp = Resorptionsdefizit (0,9)

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.

Manie und Machbarkeit

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

Geschrieben von
Michael Jentsch
Kommentare

Schreibe einen Kommentar

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