Bluetooth-Anwendungen selbst gemacht

Eine Bluetooth-Anwendung verhält sich entweder wie ein Client oder wie ein Server, bietet also einen Dienst an oder nimmt einen Dienst wahr. In der Abbildung 2 sind die verschiedenen Rollen, die ein Gerät wahrnimmt, in einer Übersicht dargestellt.
Initialisierung: Jede Bluetooth-Anwendung, ob Client oder Server, muss als ersten Schritt den Bluetooth-Stack initialisieren.
Client: Ein Client nimmt einen Dienst eines Servers wahr. Dazu sucht er zunächst nach nahen Bluetooth-Geräten (Device Discovery). Anschließend ruft er die verfügbaren Dienste der einzelnen Geräte ab. Falls einer der Dienste gewünscht ist, kann eine Verbindung aufgebaut werden.

Server: Der Server stellt dem Client Dienste zur Verfügung. Die Dienste werden in der Datenbank SDDB (Service Discovery Database) lokal auf dem Gerät abgelegt. Der Server ist sichtbar für andere Bluetooth-Geräte und wartet auf Verbindungsanfragen. Werden angebotene Dienste nicht mehr gebraucht, entfernt sie der Server aus der Datenbank.
Ein Ablaufschema, welches mehr Detailinformationen enthält, zeigt die Abbildung 3. Beide Geräte bereiten zunächst den Bluetooth-Stack vor. Die Anwendung auf dem Server stellt einen Dienst bereit und wartet auf eingehende Verbindungsanfragen. Der Client sucht nach nahen Bluetooth-Geräten und ermittelt die angebotenen Dienste. Wenn ein passender Dienst gefunden wird, verbindet sich der Client mit dem Server.

Damit eine Server-Anwendung einen Dienst anbieten kann, lauscht sie auf spezielle Verbindungsanfragen. Serielle Datenverbindungen werden über das SPP (Serial Port Profile) abgewickelt. Die allgemeine Form einer URL (Verbindungen werden als URL realisiert) lautet:

btspp://hostname:[CN|UUID]; parameters

Die Parameter bedeuten im Einzelnen:

• btspp ist das URL-Schema für eine serielle Datenverbindung
• hostname ist entweder „localhost“ für eine Server-Verbindung oder eine Bluetooth-Adresse für eine Client-Verbindung
• CN ist die Kanalnummer und wird vom Client beim Verbindungsaufbau verwendet.
• UUID ist eine universelle eindeutige Kennung, deren Eindeutigkeit im Rahmen der Wahrscheinlichkeit garantiert wird
• parameters beschreiben den Dienst, enthalten Sicherheitseinstellungen.

Ein konkretes Beispiel für eine solche URL wäre damit:

btspp://localhost:3f564545 634eb5433a5b48ff04234bc2; authenticate=true;encrypt= true;name=serialVCP

Falls eine Verbindung von einem Client zu einem Server aufgebaut wird, verwendet man anstelle von „localhost“ eine Verbindung, die im „ServiceRecord“ enthalten ist. Im Quelltext in Abbildung 5 wird das Erstellen der Verbindung gezeigt. Wenn ein Client eine passende Gegenstelle gefunden hat, verbindet er sich mit dem Server wie in Abbildung 6 gezeigt.

Ein eigener Bereich der Bluetooth API beschäftigt sich ausschließlich mit dem Auffinden anderer Bluetooth-Geräte und dem Ermitteln der angebotenen Dienste. Die Klasse „DiscoveryAgent“ enthält hierfür drei Methoden:

• retrieveDevices() – ruft bereits bekannte Geräte ab
• startInquiry() – beginnt eine aktive Suche nach Bluetooth-Geräten in Reichweite
• cancelInquiry() – beendet den Suchlauf.

Beim Auffinden von Geräten werden automatisch folgende Methoden im Interface „DiscoveryListener“ aufgerufen:

• deviceDiscovered() – wird aufgerufen, sobald ein neues Gerät gefunden wird
• inquiryCompleted() – wird aufgerufen, sobald die Suche beendet ist.

Analog zum Auffinden von Geräten funktionieren die Methoden der Klasse „DiscoveryAgent“ zum Suchen nach bereitgestellten Diensten.

• searchServices() – startet die Suche nach Diensten
• cancelServiceSearch() – beendet den Suchlauf.

Auch hier gibt es ein Interface, dessen Methoden jeweils beim Auffinden eines Dienstes gestartet werden. Folgende Methoden des Interfaces „DiscoveryListener“ sind dabei zu implementieren:

• serviceDiscovered() – wird aufgerufen, wenn ein Dienst gefunden wird
• serviceSearchCompleted() – wird aufgerufen, sobald die Suche beendet ist.