3.1 Erläuterung der Funktionalität
Die Beispielapplikation „n3po“ setzt CLDC 1.0 und MIDP 2.0 voraus und nutzt die optionalen Pakete Wireless Messaging API, Mobile Media API, die Bluetooth-API JABWT sowie das FileConnection optional Package. (more…)
Nokia unterstützt Entwickler mit einer Vielzahl an SDKs, Emulatoren und Tools1, für J2ME bietet Nokia die Nokia Developer’s Suite 2.2 for J2ME2 an. Sie unterstützt die Entwicklung von Anwendungen für Series 40 und Series 60 (more…)
Der J2ME-Entwickler kann mittlerweile auf eine Vielzahl von IDEs zurückgreifen, hier eine Ãœbersicht über die wichtigsten Entwicklungsumgebungen. (more…)
Das Java Wireless Toolkit ( WTK ) von Sun stellt die Grundlage für die meisten SDKs anderer Hersteller dar. Diese passen das Wireless Toolkit an ihre Anforderungen an, ersetzen die Standardklassen durch die eigene, herstellerspezifische (more…)
J2ME Anwendungen können natürlich nicht direkt auf dem Endgerät, auf dem die Applikation später laufen soll, entwickelt werden. Die Entwicklung einer J2ME-Applikation findet auf dem Desktop-Rechner statt. Um die (more…)
Bevor ein Client zu einem Server auf einem entfernten Gerät verbinden kann, muss der Server zuvor den eigenen Service intern registrieren, damit er vom Client abgerufen werden kann. Ein Service kann auf folgendem Weg in die SDDB (more…)
Für paketorientierte L2CAP-Verbindungen werden die Klassen L2CAPConnection und L2CAPConnectionNotifier benötigt, die Vorgehensweise ist ähnlich wie bei RFCOMM-Verbindungen. Für einen Server wird zunächst ein Notifier-Objekt vom (more…)
Bei RFCOMM handelt es sich, wie im vorangegangenen Kapitel beschrieben, um ein serielles Ãœbertragungsprotokoll. Bluetooth nutzt das bekannte Konzept von Sessions und Connections. Zwischen zwei Bluetooth-Geräten kann genau eine (more…)
Nachdem die Geräte in der Umgebung erkannt wurden, müssen die einzelnen Geräte nach den von ihnen angebotenen Services durchsucht werden. Die Funktionalität der Service Discovery wird in der Bluetooth-API durch die Klassen DiscoveryAgent, DiscoveryListener, ServiceRecord, DataElement und UUID abgebildet. (more…)
Um andere Geräte in der Umgebung aufzufinden kann durch LocalDevice.getDiscoveryAgent() ein DiscoveryAgent instantiiert werden, der die Methoden startInquiry() und retrieveDevices() besitzt. (more…)
Die Klassen RemoteDevice, LocalDevice und DeviceClass bilden in der Java-Bluetooth-Spezifikation zusammen das Generic Access Profile (GAP) und bieten Informationen über das eigene Gerät ( LocalDevice ) sowie über den Kommunikationspartner ( RemoteDevice ) und die Geräteklasse ( DeviceClass ). (more…)
Mit dem optionalen Paket der Bluetooth API ( JABWT ) wird MIDP um die Funktionen erweitert, mit anderen Bluetooth-Geräten zu kommunizieren und dabei als Sender und Empfänger aufzutreten. Grundvoraussetzung sind ein (more…)
Suns MIDP-API beschränkt sich als Basisplattform leider auf den kleinsten gemeinsamen Nenner der Geräte. Es bietet keine Unterstützung für Handy-spezifische Features wie Zugriff auf SMS, Klingeltöne, Anrufe, Telefonnummern und so weiter. (more…)
Basierend auf dem Generic Connection Framework bietet die Wireless Messaging API ( WMA ) Zugriff auf Funktionen zur drahtlosen Kommunikation via Nachrichten, zum Beispiel via Short Message Service ( SMS ) ,Cell Broadcast Service ( CBS ) oder Multimedia Message Service ( MMS ). (more…)
Im Laufe der letzten zwei Jahre fanden Endgeräte, welche Multimedia-Inhalte darstellen und abspielen können, beim Endkunden immer größeren Anklang. Polyphone, also mehrstimmige Klingeltöne gehören seit geraumer Zeit zum (more…)
Der Funktionsumfang der API wird durch weitere, optionale Pakete ergänzt, deren Hardwareanforderungen zu denen von CLDC und MIDP hinzuzuaddieren sind. Die optionalen Pakete versuchen, die Lücke zu nativen Anwendungen zu schließen, indem sie eine bessere Ausnutzung der Möglichkeiten des Endgeräts bieten. (more…)
In mobilen Geräten findet sich eine Vielzahl an unterschiedlichen Speicherkonzepten. Einige besitzen beispielsweise ein Dateisystem mit Verzeichnissen und Dateien, während andere ihre Daten in einzelnen Datenbanken sichern, die (more…)
Hier wird durch den Aufruf der Methoden, die in den Basisklassen vordefiniert sind, auf eine Eingabe über Tastatur reagiert. Beim Drücken einer Taste wird die keyPressed() Methode aufgerufen, wenn die Taste wieder losgelassen wird erfolgt der (more…)
Die im vorangegangenen Kapitel erwähnt, unterscheidet sich die Verarbeitung der Benutzereingaben bei High Level API und Low Level API. (more…)
Die Verwendung der High Level UI hat unter anderem den Vorteil, dass sich der Programmierer nicht um unterschiedliche Displaygrößen und deren Farbdarstellung auf den unzähligen, verschiedenen Endgeräten kümmern (more…)
Wie bereits angesprochen besitzt die Low Level UI ein wesentlich niedrigeres Abstraktionsniveau als die High Level UI. Der Programmierer gewinnt durch die Verwendung der Low Level UI die Kontrolle über das exakte Aussehen der (more…)
Das High Level UI enthält vordefinierte Elemente, die typischerweise in mobilen Anwendungen benutzt werden und sich auf allen Geräten darstellen lassen. Das konkrete Look&Feel und das Bedienkonzept hängen dabei vom verwendeten (more…)
Benutzerschnittstellen von Kleingeräten fallen sehr unterschiedlich aus: Je nach Größe ( und Anschaffungspreis ) des Geräts variieren die Displaygrößen, Displayauflösugen und die darstellbare Farbtiefe der Displays. (more…)
Eine Anwendung für das MIDP heißt, angelehnt an die im Browser lauffähigen Applets – MIDlet. Ein MIDlet besteht aus einer, von der abstrakten Klasse javax.microedition.midlet.MIDlet abgeleiteten, Java-Klasse. Die Application Managment (more…)
Um mit der Weiterentwicklung der Hardware Schritt zu halten wurde MIDP 2.0 eingeführt. MIDP 2.0 erschien Ende 2002 als Final Release und wird seit Ende 2003 mit den Endgeräten einiger Hersteller ausgeliefert – MIDP 2.0 wird aber derzeit noch nicht von allen Herstellern unterstützt. (more…)
Mobile Programmierung und Softwareentwicklung in Java 2 ME.
Die Inhalte dieser Seiten stammen aus meiner Java 2 ME Diplomarbeit mit dem Titel “Kommunikation und Austausch von Multimediadaten in spontanen Bluetooth-Netzwerken mit der Java 2 Micro Edition”
Eine Configuration wird mit Hilfe von Profilen für bestimmte Geräte-Familien spezialisiert und erweitert. MIDP für Handys ist das erste und wichtigste Profil das Sun zur Verfügung stellt. (more…)
Mit der rasanten Weiterentwicklung im Bereich der mobilen Hardware nimmt sowohl die Rechenleistung als auch die Speicherausstattung der Endgeräte zu. Dementsprechend wurde die Nachfolgeversion CLDC 1.1 mit zusätzlichen Fähigkeiten ausgestattet. (more…)
Die CLDC arbeitet mit der stark eingeschränkten Kilobyte Virtual Maschine (KVM), die sich mit sehr wenig Speicher begnügt. Als minimale Voraussetzung für CLDC 1.0 gibt Sun 128 KB ROM und nur 32 KB RAM an. (more…)
Was unterscheidet Personal Java und J2ME?
Wie bereits angesprochen ist die Java 2 Micro Edition gegenüber der Java 2 Standard Edition abgespeckt worden, um den Anforderungen der mobilen Endgeräte besser gerecht zu werden. (more…)