Archive for October, 2018

JABWT (JSR-82) Teil 4: Grundlagen für Erkennung von Diensten und Geräten

Monday, October 29th, 2018

Wie kann man ein Bluetoothgerät zur Laufzeit finden? Das Bluetoothprotokoll unterschiedet zwischen Erkennung von Diensten (Services) und Geräten (Devices). Um eine gezielte Suche zu ermöglichen, wird jedes Bluetoothgerät mit folgenden Informationen gekennzeichnet:

  • major service class (”Positioning”, “Telephony” oder “Networking”)
  • major device class (Grobe Klassifizierung des Geräts z.B. “Peripheral” oder “Audio/Video”)
  • minor device class (Genauere Spezifikation der “major device class” z.B. “Keyboard”)

Da ein Gerät mehrere Dienste anbieten kann, sind mehrere “major service class” Einträge möglich.

Es gibt zwei Typen der Gerätesuche (”Inquiry”): “General/Unlimited Inquiry” und “Limited Dedicated Inquiry”. Die “Limited Dedicated Inquiry” liefert als Suchergebnis nur Geräte, die nur für eine begrenze Zeitdauer gefunden werden können (z.B. PDAs). Ein Bluetooth-Gerät kann sich also in drei verschiedenen Modi befinden: “general”, “limited” oder “not discoverable”.

Im nächsten Teil stelle ich den DiscoveryAgent und den DiscoveryListener vor, mit denen im JABWT die Suche nach Geräten und Diensten ausgeführt wird.

P.S.: Etwas ärgerlich finde ich, dass die offiziellen Bluetooth Spezifikationen nur mit einem sog. Adopter Account runtergeladen werden können. Und den bekommt man nur wenn man das “Bluetooth Trademark Licence Agreement” unterzeichnet(!).

[kurzer Einschub] Natel Nuancen: Bluetooth vs. Internet auf dem W800

Thursday, October 25th, 2018

Momentan programmiere ich an einer kleinen J2ME-Applikation names “Hikr”. Was “Hikr” (übrigens ein sehr trendiger Web 2.0 Name) genau ist, erzähle ich später mal. Jedenfalls stelle ich wieder frappierende Unterschiede zwischen Emulator des Wireless Toolkits und dem realem Gerät (in meinem Fall ein Sony Ericsson W800i) fest. So kann das W800i keine Internetverbindung öffnen, solange eine Bluetoothverbindung besteht. Im Emulator funktioniert das jedoch tadellos.

JABWT (JSR-82) Teil 3: RFCOMM Beispiel

Wednesday, October 17th, 2018

Das nachfolgende Codebeispiel zeigt sehr vereinfacht einen Zugriff auf einen GPS Empfänger.

Zunächst wird über die Connector Klasse ein StreamConnection Objekt geholt, mit Hilfe dessen ein InputStream geöffnet wird. Über diesen Stream schickt der GPS Empfänger laufend NMEA-Messages, die die aktuelle Position angeben. Unser Beispielcode interpretiert die ersten ankommenden 256 Bytes als String. Das ist ausreichend um mindestens 1 NMEA-Message komplett zu empfangen. Anschliessend wird die Verbindung im finally Block geschlossen.

  1. import java.io.IOException;
  2. import java.io.InputStream;
  3. import javax.microedition.io.Connector;
  4. import javax.microedition.io.StreamConnection;
  5.  
  6. StreamConnection conn   = null;
  7. InputStream is          = null;
  8. String message          = null;
  9. try {
  10.         conn = (StreamConnection) Connector.open (“btspp://008049323FAE:1”,
  11.                                                   Connector.READ);
  12.         is = conn.openInputStream();
  13.         byte buffer[] = new byte[256];
  14.         is.read(buffer);
  15.         message = new String(buffer);
  16.  
  17. } catch (IOException io) {
  18.         // handle exception
  19. } finally {
  20.         if (conn != null) {
  21.                 try {
  22.                         conn.close();
  23.                 } catch (IOException ignored) {}
  24.         }
  25.  
  26.         if (is != null) {
  27.                 try {
  28.                         is.close();
  29.                 } catch (IOException ignored) {}
  30.         }
  31. }

Dieser Code ist natürlich in dieser einfachen Form noch nicht “produktionstauglich”. Z.B. würde man den Bluetooth Zugriff in einem separaten Thread oder besser in einem TimerTask auslagern. Zudem ist im Beispiel die Bluetoothadresse noch hartcodiert. Wie man die Adresse zur Laufzeit findet, seht ihr im nächsten Teil

;)

JABWT (JSR-82) Teil 2: RFCOMM

Tuesday, October 9th, 2018

RFCOMM emuliert eine serielle Schnittstelle zwischen zwei Bluetoothgeräten und ist deswegen die “einfachste” API in der JABWT Welt. Für die Verwendung des Protokolls wurden keine neuen Klassen definiert. Stattdessen wird das General Connection Framework (GCF) aus der CLDC-Spezifikation verwendet. Das GCF abstrahiert Verbindungen in einer hierarchischen Struktur (Connection, StreamConnection, HttpConnection, usw.).

Für das Aufbauen von unterschiedlichen Verbindungen ist die Connector Klasse zuständig. Sie gibt je nach übergebener URL das passende Connection Object zurück (z.B. HttpConnection bei URL mit dem Schema “http:“). Für eine RFCOMM-Verbindung lautet das Schema “btspp”.

Beispiel für eine Clientverbindung: btspp://008049323FAE:1
schema:bluetooth address:server channel

Der Server Channel identifiziert eindeutig einen Bluetoothdienst und ist vergleichbar mit einer TCP/IP Portnummer. Zusätzlich können mit der URL auch Parameter übergeben werden. Für eine Clientverbindung sind folgende Parameter möglich:

  • authenticate (true oder false) Gibt an, ob das Remotedevice authentifiziert werden muss.
  • master (true oder false) Gibt an, dass das Gerät “Master” der Verbindung sein muss.
  • encrypt (true oder false) Gibt an, dass die Bluetoothverbindung verschlüsselt sein muss.

Beispiel mit Parameter:
btspp://008049323FAE:1;master=true;authenticate=true

So, genug für heute. Im nächsten Teil gibts Beispiel-Code

:)