7,80. Deutschland. Österreich 9,00 Schweiz 15,80 sfr Luxemburg 9,20. Core Bluetooth ab. Einführung in die BLE-Entwicklung mit ios

Transkript

1 Oktober 2013 München Deutschland 7,80 Österreich 9,00 Schweiz 15,80 sfr Luxemburg 9,20 Volume 12 MOBILE TECHNOLOGY Expo: Oktober 2013 Ausgabe 3/2013 KSH R O W R E W PO INTERNATIONAL PHP CONFERENCE 2013 #MVFUPPUI -& t J04 t "OESPJE t #MBDL#FSSZ t 3BTQCFSSZ 1J LI U J. 8 1 S I SPECIAL B OPS FOR FREE Große Infografik: CI mit Git 34 Core Bluetooth ab ios 6 Einführung in die BLE-Entwicklung mit ios istockphoto.com/oktalstudio Java in ios und Android Media-Partner: Präsentiert von: Veranstalter: Mobile Entwicklung mit dem Application Developer Framework BlackBerry Live 2013: BlackBerry wieder in der Offensive App Store Optimization: Alternative App Stores und das Freemium-Modell Odyssee: Mit Sencha Touch und Apache Cordova zur mobilen Applikation Raspberry Pi: Spaß mit Embedded Monetarisierung: zanox SDK für ios und Android Sieben Zwerge: Die beliebtesten Einplatinencomputer im Überblick

2 012 ios Bluetooth LE und ios 6 Einführung in die BLE-Entwicklung mit ios Erste Schritte mit Core Bluetooth ab ios 6 istockphoto.com/oktalstudio Mobile Technology

3 Bluetooth LE und ios 6 ios 013 Core Bluetooth hat für typische Anwendungsfälle aus den Bereichen Healthcare, Heimvernetzung, Entertainment, Security und Sport/ Fitness Einzug in ios 5 gehalten. Selbst Themen wie abstandsabhängige Kommunikation zwischen Geräten werden mit dem relativ neuen Standard adressiert. In diesem Zuge entwickelt sich Bluetooth LE zu einer echten Alternative zu NFC und wird selbst für Szenarien wie mobiles Bezahlen oder die Spieleindustrie interessant. von Wolfgang Frank und Samuel Mellert Mobile Technology

4 014 ios Bluetooth LE und ios 6 Das in ios 5 eingeführte Core-Bluetooth- Framework deckt die meisten Aspekte der Bluetooth-4.0-Low-Energy-(LE-)Spezifikation ab. Konnte man mit ios 5 nur auf Bluetooth-LE-Geräte zugreifen, die Daten bereitstellen, so wurde mit ios 6 das API erweitert, damit sich ios-geräte selbst als Datenlieferant anbieten können. Leider unterstützen nur die neueren ios-geräte und Macs die Bluetooth- LE-(BLE-)Spezifikation. Dazu gehören das iphone 4S, iphone 5, der Mac Mini, das neue ipad, MacBook Air und MacBook Pro. Seit ios 6 gibt es auch eine BLE- Unterstützung des iphone-simulators, die allerdings in der Praxis aufgrund der verschiedenen BLE Dongles recht problematisch ausfällt. Apple wird den Support des Simulators voraussichtlich in nächsten ios-versionen wieder einstellen. Alternativ zu echten ios-devices gibt es auch diverse Bluetooth-LE-Development-Kits, die Sensordaten wie Gyroscope, Temperatur, Accelerometer und Ähnliches anbieten. Am Bekanntesten ist momentan vermutlich das Sensor-Tag von Texas Instruments, das man für nur 25 US-Dollar erwerben kann. Das Tüfteln mit diesen externen Sensoren macht wirklich viel Spaß und beflügelt manch eine Idee im Kontext des Internet of Things und der Machine Listing 1: BizCardServer.m #import "BizCardServer.h" #import <CoreBluetooth/CoreBluetooth.h> #define NOTIFY_MTU BizCardServer () (nonatomic, strong) CBPeripheralManager (nonatomic, strong) CBMutableService (nonatomic, strong) CBMutableCharacteristic (strong, nonatomic) NSData (nonatomic, readwrite) NSInteger Listing 2: BizCardServer.m: init // First create the peripheral manager to act as server (manager) for data -(id)init if (self = [super init]) _peripheralmanager = [[CBPeripheralManager alloc] initwithdelegate:self queue:dispatch_queue_create("ble_queue", nil)]; return self; to Machine -Vernetzung. Es liegt durchaus nahe, dass BLE ebenfalls die Grundlage für die viel spekulierte iwatch bilden wird. Im Gegensatz zu WLAN oder dem klassischen Bluetooth ist Bluetooth LE nicht besonders gut geeignet, um große Datenmengen wie Bilder, Videos oder Dokumente zu übertragen, da sich nur geringe Transferraten realisieren lassen. Die Stärken von BLE liegen in der geringeren Sendeleistung so kann ein BLE-Gerät, ausgestattet mit einer kleinen Knopfbatterie, leicht über mehrere Monate betrieben werden. Das wäre mit herkömmlichem Bluetooth oder WLAN undenkbar. Weiter ist es möglich, BLE-Geräte ad hoc miteinander zu verbinden, ohne mühselige Pairing-Orgien durchzuführen. Ein explizites Pairing ist nur für verschlüsselte Übertragungen notwendig. Bluetooth LE verlangt keine Konformität zu MFI (Made for iphone), sondern man kann auch ohne Zertifizierung eigene Peripherals erstellen, bzw. verwenden. Die wichtigsten Frameworkklassen Schauen wir uns die wichtigsten Klassen aus dem Core- Bluetooth-(CB-)Framework genauer an. Grundsätzlich wird zwischen Central und Peripheral unterschieden. Das gesamte Framework dreht sich um diese beiden Komponenten und regelt anhand von Delegate Callbacks den Austausch von Informationen und Daten zwischen ihnen. Eine Analogie findet man in Client-/ Serverarchitekturen, bzw. im Provider-/Subscriber- Muster. Das Central übernimmt dabei die Rolle des Clients/Subscriber, der Daten abfragt bzw. benötigt. Das Peripheral enthält Daten, die angeboten werden, und spielt somit die Rolle eines Servers/Provider. Wie bereits erwähnt, kann ab ios 6 ein Gerät sowohl Central als auch Peripheral sein, jedoch leider nicht beides zur selben Zeit! Die Central-Komponente wird durch die CBCentralManager-Klasse und die Peripheral- Komponente durch die CBPeripheralManager-Klasse repräsentiert. CBCentralManager-Objekte werden verwendet, um entdeckte oder verbundene Peripherals, die durch CBPeripheral-Objekte repräsentiert werden, zu verwalten. Der CBCentralManager dient insbesondere dazu, nach Peripherals zu scannen, diese zu entdecken und sich mit ihnen zu verbinden. Anders herum wird auf der Seite eines Peripherals durch ein CBCentral- Objekt der Client repräsentiert, der sich mit dem Peripheral verbunden hat. Man kann sich das so vorstellen, dass ein Peripheral nach außen hin über Broadcasts bekannt gibt, Daten anzubieten. In diesem Angebot können so genannte Services enthalten sein. Auf der Gegenseite scannt ein Central die Umgebung nach vorhandenen Services. Sobald ein gesuchter Service gefunden wird, kann der Central eine Verbindung zum Peripheral aufbauen. Ist diese Verbindung erfolgreich aufgebaut, können die beiden Geräte Daten untereinander austauschen. Die Daten für den Austausch sind in Services organisiert, die wiederum aus verschiedenen so genannten Characteristics bestehen. Eine Characteristic ist im Grunde ein definierter Attributtyp, der einen logischen Mobile Technology

5 Bluetooth LE und ios 6 ios 015 Wert enthält. Zahlreiche Services und Characteristics sind mittlerweile standardisiert, sodass auch herstellerunabhängig beispielsweise ein Heartrate-Monitor durch einen gleichen Service oder zumindest gleiche Characteristics seine Daten anbietet. Auf der Central- Seite wird ein Service durch eine CBService-Klasse repräsentiert. Jeder dieser Services enthält eine Liste von Characteristics, jeweils repräsentiert durch eine CBCharacteristics-Klasse. Auf gleiche Weise werden Services und Characteristics auf Seiten des Peripherals durch ihre erzeugbaren, bzw. veränderbaren Pendants, CBMutableService und CBMutableCharacteristic umgesetzt. Sowohl ein Service als auch eine Characteristic müssen eindeutig durch eine UUID identifizierbar sein. Das Core-Bluetooth-Framework stellt hierfür die Hilfsklasse CBUUID bereit. In Abbildung 1 wird der Zusammenhang der Kernkomponenten nochmals illustriert. Im Folgenden werden anhand eines einfachen Beispiels die grundlegenden Mechanismen von Core Bluetooth in der Anwendung vorgestellt. Dazu erstellen wir ein Peripheral, das einen Service anbietet, sowie ein Central, das sich ab einer bestimmten räumlichen Nähe zum Peripheral verbindet und die bereitgestellten Daten abruft. Idealerweise probiert man das Beispiel mit zwei BLE-fähigen ios-geräten aus. In diesem Beispiel kapseln wir die Client-, bzw. Serverfunktionalität in zwei eigene Klassen (BizCardServer => Peripheral und Biz- CardClient => Central). Ein eigenes Peripheral bauen Die im Folgenden aufgeführten Schritte sind notwendig, um ein Peripheral zu erstellen: Einen CBPeripheralManager erzeugen und starten Einen CBMutableService mit CBMutableCharacteristic erzeugen Service bekanntgeben (advertise) Mit der Central verbinden und Daten austauschen Im Xcode-Projekt muss als Allererstes das CoreBluetooth.framework unter LINKED FRAMEWORK AND LIBRARIES eingebunden werden In unserem BizCardServer (Listing 1) importieren wir die Core-Bluetooth-Framework-Header (<CoreBluetooth/CoreBluetooth.h>). Damit wir auf die Callbacks in der Rolle als Peripheral reagieren können, müssen wir das entsprechende CBPeripheralManagerDelegate- Protokoll implementieren. Zusätzlich legen wir Properties für den Peripheral-Manager, den zu erstellenden Service und die beinhaltende Characteristic an. Ebenso benötigen wir für das Beispiel ein datatosend-property, das die anzubietenden Daten in einem NSData Object hält, sowie eine senddataindex als Hilfszähler, um auch Datenmengen versenden zu können, die nicht in einem einzigen Chunk übertragen werden können, sondern auf mehrere Datenpakete aufgeteilt werden müssen. Abb. 1: Die wichtigsten Kernkomponenten in Core Bluetooth In der init-methode initialisieren wir den Peripheral- Manager. Das erste Argument setzt das delegate (in unserem Fall self). Im zweiten Argument kann eine Queue angegeben werden, falls zum Beispiel der Peripheral- Manager nicht im Main Thread laufen soll. Wir erzeugen in unserem Beispiel eine eigene BLE_Queue-Queue mittels Grand Central Dispatch und übergeben diese als Argument (Listing 2). Sobald der Peripheral-Manager initialisiert wurde, müssen wir seinen Zustand überprüfen (Listing 3). Dies ist notwendig, um sicherzustellen, dass unsere App auch tatsächlich auf einem Bluetooth-LE-fähigen Gerät läuft. Dazu implementieren wir die Delegate-Methode peripheralmanagerdidupdatestate:. Hier können wir auch ggf. passende Infomeldungen an den User weitergeben, Listing 3: BizCardServer.m: Status BLE prüfen // Check if Bluetooth LE is available and setup service - (void)peripheralmanagerdidupdatestate:(cbperipheralmanager *)peripheral switch (peripheral.state) case CBPeripheralManagerStatePoweredOn: [self setupservice]; break; default: NSLog(@"Peripheral Manager did update state"); UIAlertView *alert = [[UIAlertView alloc] Info" message:@"bluetooth LE is not available or activated" delegate:nil cancelbuttontitle:@"ok" otherbuttontitles:nil, nil]; [alert show]; break; Mobile Technology

6 016 ios Bluetooth LE und ios 6 falls Bluetooth im System nicht aktiviert wurde oder nicht verfügbar ist. Im Falle des Status CBPeripheralManagerState- PoweredOn wissen wir, dass BLE verfügbar ist, und wir können unseren anzubietenden Service erzeugen ([self setupservice], Listing 4). Die weiteren validen States findet man in der Core-Bluetooth-Framework-Referenzdokumentation. Jeder Service und jede Characteristic wird durch eine 16- bzw. 128-Bit-UUID identifiziert. Im Falle von eigenen Anwendungen muss man eine 128-Bit-UUID verwenden und sollte dafür sorgen, dass es keine Kollisionen mit anderen UUIDs von anderen Services bzw. Characteristics gibt. Die 16-Bit-UUIDs werden durch die Bluetooth-SIG vergeben. Als Hilfe kann man im OSX-Terminal einfach das Kommando uuidgen aufrufen, um eigene eindeutige Identifier zu erzeugen. Listing 4: BizCardServer.m: Service und Characteristic erzeugen // Construct a new service and publish it - (void)setupservice // Create characteristic self.cardcharacteristic = [[CBMutableCharacteristic alloc] nitwithtype:[cbuuid UUIDWithString:kCardCharacteristicUUID] properties:cbcharacteristicpropertynotiy value:nil permissions:cbattributepermissionsreadable]; // Create service and add characteristic self.cardservice = [[CBMutableService alloc] initwithtype: [CBUUID UUIDWithString:kCardServiceUUID] primary:yes]; // Set the characteristic for service self.cardservice.characteristics // Publish service [self.peripheralmanager addservice:self.cardservice]; Listing 5: BizCardService.h: UUIDs für Service und Characteristic #ifndef BizCardService_h #define BizCardService_h #define #define #endif In unserem Fall benötigen wir zwei UUIDs: eine für den Service und eine für die Characteristic (Listing 5). In Listing 4 sieht man die Erzeugung eines Service. Als Erstes wird jedoch eine Characteristic erzeugt und die CBUUID, die unserer selbst generierten UUID entspricht, als ersten Parameter der initwithtype:proper ties:value:permissions-methode übergeben. Als drittes Argument wird nil übergeben, was so viel bedeutet, wie dass sich der Wert für diese Characteristic dynamisch ergibt und nicht schon statisch feststeht. Das entspricht dem generellen Vorgehen beim Erzeugen von dynamischen Daten. Falls der Wert jedoch sowieso immer konstant bleibt, spricht natürlich auch nichts dagegen, diesen hier fest anzugeben. Der zweite Parameter der init-methode bestimmt, in welcher Form der Wert verwendet werden soll. Ein paar der wichtigsten Möglichkeiten sind im Folgenden aufgelistet: CBCharacteristicPropertyBroadcast: Erlaubt den Broadcast eines Characteristic-Werts durch Verwendung des characteristic configuration descriptor. CBCharacteristicPropertyRead: Erlaubt das Lesen des Characteristic-Werts. CBCharacteristicPropertyWriteWithoutResponse: Ermöglicht das Schreiben des Characteristic-Werts, jedoch ohne Antwort. CBCharacteristicPropertyWrite: Ermöglicht das Schreiben des Characteristic-Werts. CBCharacteristicPropertyNotify: Ermöglicht die Benachrichtigung bei Änderungen des Characteristic- Werts ohne Antwort. Des Weiteren sind Konstanten, bzw. Parameter für Verschlüsselung und Signierung von Characteristic- Wertänderungen verfügbar. Für diese weiterführenden Themen findet man die Details in der Core-Bluetooth- Developer-Dokumentation. Das letzte Argument der init-methode sind die Lese-, Schreibe- und Verschlüsselungsrestriktionen für Attribute. Mögliche Werte sind: CBAttributePermissionsReadable CBAttributePermissionsWriteable CBAttributePermissionsReadEncryptionRequired CBAttributePermissionsWriteEncryptionRequired Nachdem die Characteristic erzeugt wurde, wird der Service erstellt. Auch dieser erhält eine CBUUID, die wir zuvor selbst generiert haben. Diesem Service fügen wir eine Liste der Characteristics hinzu, um die hierarchische Struktur aufzubauen (Abb. 2). Am Ende der Methode sagen wir dem Peripheral-Manager, dass dieser Service dem Peripheral hinzugefügt werden soll. Durch das Hinzufügen des Service zum Peripheral- Manager wird der nächste Delegate Callback peripher almanager:didaddservice:error ausgelöst. Oft wird an dieser Stelle das Bekanntmachen (Advertising) des Service gestartet. In unserem Beispiel wollen wir das expli- Mobile Technology

7 Bluetooth LE und ios 6 ios 017 zit durch eine Nutzeraktion starten können und haben dazu eine eigene Methode startadvertisingbizcardservice und stopadvertisingbizcardservice erzeugt, die unsere BizCardServer-Klasse auch im Header File publik macht (in Listing 6 nicht explizit gezeigt). Das Advertising erfolgt durch periodische Broadcasts des Peripherals. Um die initiale Erkennung zu beschleunigen, aber auch gleichzeitig die Batterie zu schonen, werden nach dem Starten des Advertisings die Pakete in kurzen Zeitabständen versendet und nach einiger Zeit werden diese Intervalle automatisch vergrößert. Das gleiche Vorgehen trifft auf das Scanning nach Devices durch das Central zu. Befindet sich die App im Vordergrund, erfolgt das Advertising des Peripherals sowie das Scanning auf Central-Seite mit höherer Intensität, als wenn sich die App im Hintergrund befindet. Man sollte also beachten, dass sich die Zeiträume für das Entdecken und Verbinden von BLE- Geräten im Background verlängern. Core Bluetooth verfügt über ein Caching der Characteristics (nicht der Werte), um das Entdecken und Analysieren der Services zu beschleunigen. Das Advertise-Paket, das maximal 31 Bytes an Daten/Informationen enthalten kann, liefert neben der Service-UUID auch eine Information zur Signalstärke (RSSI), die verwendet werden kann, um die Distanz zwischen den Geräten zu bestimmen. Es handelt sich dabei um einen ungenauen Wert, der lediglich helfen kann, zwischen nah, mittelweit und ganz weit zu unterscheiden, wobei die Grenzen je nach Geräten und Wetterlage und Umgebungsparametern (z. B. Luftfeuchtigkeit, Temperatur, elektromagnetische Störquellen) schwanken können. Nachdem der Peripheral-Manager begonnen hat, den Service bekannt zu machen (Advertising), empfängt er über seine Delegate-Methoden die Nachricht peripheral- Manager:didStartAdvertising:. Sobald sich ein Central mit dem Peripheral verbunden hat, bekommt man den centraldidconnect-callback des CBPeripheralManagerDelegate. Üblicherweise gefolgt von Read Requests für den Wert einer Characteristic, die durch den Callback didreceivereadrequest signalisiert werden. Der CBPeripheralManager antwortet in der Regel mit respondtorequest auf die Anfragen und liefert somit die gewünschten Daten, bis der Central die Verbindung beendet, was durch einen Aufruf des centraldiddisconnect aus dem Delegate-Protokoll auf Seiten des Peripherals sichtbar wird. Eine andere, oftmals bessere Möglichkeit, ist es, den sog. Subscription/Notify-Mechanismus zu verwenden, bei dem ein Central über angebotene Daten und deren Änderungen automatisch benachrichtigt wird. Hat sich ein Central für einen Service, bzw. für eine Characteristic subscribed (siehe BizCardClient), wird dies über einen Callback der peripheralmanager:cent ral:didsubscribetocharacteristic: Delegate-Methode bekannt gemacht. An dieser Stelle kann dann der dynamische Inhalt erstellt und per updatevalue:forcha Abb. 2: Struktur von Services und Characteristics Listing 6: BizCardServer.m: Advertise starten // When service is added start advertising it via Bluetooth LE - (void)peripheralmanager:(cbperipheralmanager *)peripheral didaddservice:(cbservice *)service error:(nserror *)error if (error == nil) NSLog(@"Service Setup (not advertised yet!)"); else NSLog(@"Error adding service: %@", [error localizeddescription]); // Public method - (void)startadvertisingbizcardservice // Start advertising service [self.peripheralmanager CBAdvertisementDataServiceUUIDsKey UUIDWithString:kCardServiceUUID] ] ]; // Public method - (void)stopadvertisingbizcardservice // Stop advertising service [self.peripheralmanager stopadvertising]; Mobile Technology

8 018 ios Bluetooth LE und ios 6 Listing 7: BizCardServer.m: Daten senden // Recognize when the central unsubscribes - (void)peripheralmanager:(cbperipheralmanager *)peripheral central:(cbcentral *)central didunsubscribefromcharacteristic:(cbcharacteristic *)characteristic NSLog(@"Central unsubscribed from characteristic"); // Catch when someone subscribes to our characteristic, then start sending // them data - (void)peripheralmanager:(cbperipheralmanager *)peripheral central:(cbcentral *)central didsubscribetocharacteristic:(cbcharacteristic *)characteristic if ([characteristic.uuid isequal:[cbuuid UUIDWithString:kCardCharacteristicUUID]]) NSLog(@"Central subscribed to kcardcharacteristicuuid"); // Create some sampel data --> could be provided dynamically! self.datatosend = [@"'firstname' : 'Peter', 'lastname' : 'Pan','organization' : 'New kids on the block', 'location' : 'Neverland','contact' : 'pp@neverland.org'" datausingencoding:nsutf8stringencoding]; // Reset index self.senddataindex = 0; // Start sending data [self senddata]; // Sends the next amount of data to the connected central - (void)senddata // First up, check if we're meant to be sending an EOM static BOOL sendingeom = NO; if (sendingeom) // send EOM if ([self.peripheralmanager updatevalue: [@"EOM" datausingencoding:nsutf8stringencoding] forcharacteristic:self.cardcharacteristic onsubscribedcentrals:nil]) // Mark it as sent sendingeom = NO; NSLog(@"Sent: EOM"); else // It didn't send, so we'll exit and wait for // peripheralmanagerisreadytoupdatesubscribers to call senddata again // We're not sending an EOM, so we're sending data // Data left to send? if (self.senddataindex >= self.datatosend.length) // No data left. Do nothing // There's data left, so send until the callback fails, or we're done. BOOL didsend = YES; // Make the next chunk while (didsend) // How big should chunk be NSInteger amounttosend = self.datatosend.length - self.senddataindex; // Can't be longer than 20 bytes if (amounttosend > NOTIFY_MTU) amounttosend = NOTIFY_MTU; // Copy out the data we want NSData *chunk = [NSData datawithbytes: self.datatosend.bytes+self.senddataindex length:amounttosend]; // Send next chunk of data if ( [self.peripheralmanager updatevalue: chunk forcharacteristic:self.cardcharacteristic onsubscribedcentrals:nil] ) NSString *stringfromdata = [[NSString alloc] initwithdata: chunk encoding:nsutf8stringencoding]; NSLog(@"Sent: %@", stringfromdata); // Update our index self.senddataindex += amounttosend; // Was it the last one? if (self.senddataindex >= self.datatosend.length) // It was - send an EOM // Set this so if the send fails, we'll send it next time sendingeom = YES; // Send EOM if ([self.peripheralmanager updatevalue: [@"EOM" datausingencoding:nsutf8stringencoding] forcharacteristic:self.cardcharacteristic onsubscribedcentrals:nil]) // we're all done sendingeom = NO; NSLog(@"Sent: EOM"); else else // Didn't work - drop out and wait for the callback // This callback comes in when the PeripheralManager is ready to send the next // chunk of data. This is to ensure that packets will arrive in the order they are sent. - (void)peripheralmanagerisreadytoupdatesubscribers: (CBPeripheralManager *)peripheral // Start sending again [self senddata]; Mobile Technology

9 Bluetooth LE und ios 6 ios 019 racteristic:onsubscribedcentrals: versendet werden. Sollte die Größe der Daten 20 Bytes überschreiten (NO- TIFY_MTU), können diese nicht mit einem Mal übertragen werden und der Datenstrom muss in Häppchen ( Chunk ) übertragen werden. In unserem Beispiel wird ein EOM als Signal für das Ende einer Nachricht gesendet (Listing 7). Das Zerteilen der Nachricht entspricht weitestgehend dem BTLE-Beispielprojekt von Apple, wobei es hier natürlich auch schönere Wege gibt, um diesen Mechanismus zu realisieren. Die Interaktion zwischen Central und Peripheral sowie der Datenaustausch können auch mit entsprechenden BackgroundModes in der info.plist im Hintergrund durchgeführt werden. Apple empfiehlt jedoch, die Apps so zu gestalten, dass das Scannen und Verbinden über ein Start/Stop-Konzept für einen Nutzer aktiv und sichtbar umgesetzt wird, da ansonsten durch die Hintergrundtätigkeiten der Anwendung der Energie- und Datenbedarf des Geräts schnell sehr hoch ausfallen kann, was wiederum zu einer schlechten User Experience führt. Ein Central bauen Nachdem wir mit unserem Peripheral als Server Daten anbieten, müssen wir noch ein Central als Client erstellen, der diese Daten konsumiert. Dazu implementieren Die Interaktion zwischen Central und Peripheral sowie der Datenaustausch können auch im Hintergrund ausgeführt werden. wir in unserem Central (gekapselt durch BizCardClient) das CBCentralManagerDelegate- sowie das CB- PeripheralDelegate-Protokoll, um die entsprechenden Callbacks für das Set-up des Centrals, den Verbindungsaufbau und die Interaktion mit dem Peripheral zu erhalten. Als Properties merken wir uns einen CBCentralManager sowie das verbundene CBPeripheral und ebenfalls ein NSMutableData-Property, das die empfangenen Daten aufnimmt. Analog zum Peripheral zuvor wird in der init-methode der Central-Manager erzeugt, self als Delegate gesetzt und eine GCD-Queue angegeben, in der das Central ablaufen soll, da ansonsten bei nil die Main Queue verwendet wird. Sobald der Central- Manager initialisiert ist, kann sein Status überprüft werden, um ebenso sicherzustellen, dass das Gerät BLE Anzeige Wissen, wie s geht.

10 020 ios Bluetooth LE und ios 6 unterstützt. Wie beim Peripheral erfolgt dies durch die Implementierung einer Delegate-Methode centralmanagerdidupdatestatus: (Listing 8). Oft wird hier bereits der Scan nach Peripherals gestartet. In unserem Beispiel haben wir diesen Schritt, um den Scan zu starten, Listing 8: BizCardClient.m: Initialisierung des Centrals #import "BizCardClient.h" #import <CoreBluetooth/CoreBluetooth.h> #define kupperproximityrssilimit -15 #define klowerproximityrssilimit BizCardClient () <CBCentralManagerDelegate, (nonatomic, strong) CBCentralManager (nonatomic, strong) CBPeripheral (nonatomic, strong) BizCardClient // First create the central manager to act as client (manager) for data -(id)init if (self = [super init]) _centralmanager = [[CBCentralManager alloc] initwithdelegate:self queue:dispatch_queue_create("ble_queue", nil)]; _data = [[NSMutableData alloc] init]; return self; - (void)centralmanagerdidupdatestate:(cbcentralmanager *)central switch (central.state) case CBCentralManagerStatePoweredOn: //[self scan]; // We'll make the scanning startable by the user NSLog(@"Central Manager ready to scan for services"); break; default: NSLog(@"Central Manager did change state"); break; - (void)scan [self.centralmanager [CBUUID UUIDWithString:kCardServiceUUID] ] options:@cbcentralmanagerscanoptionallowduplicateskey ]; in eine eigene public-methode verlagert, um den Scan durch den User direkt start- und stopbar zu machen. Die scanforperipheralswithservices:options-methode wird verwendet, um das Scanning nach Advertisements des Peripherals zu starten. Als Argument kann eine Liste der spezifischen Services (UUIDs) mitgegeben werden, um die Suche einzuschränken. Wenn ein Peripheral entdeckt wird, erfolgt ein Aufruf des Delegates central:diddiscoverperipheral:advertism entdata:rssi: mit den Advertisement-Daten und dem RSSI-Signalstärkewert (Received Signal Strength Indicator). Letzterer kann verwendet werden, um sich nur mit einem Gerät zu verbinden, das sich in einem gewünschten Abstand befindet (Listing 9). Hat man ein passendes Peripheral gefunden, wird eine Verbindung über die Central-Manager-Methode connectperipheral:options: hergestellt. Mit dem Optionsparameter kann gesteuert werden, ob das Connect und Disconnect mit einem Peripheral zu weiteren Notifications/Alerts führen soll. Dieser Connect-Aufruf mündet in einen Delegate Callback didconnectperipheral:. Ist eine Verbindung zu dem Peripheral hergestellt, wird dieses mittels discoverservices: mit optionaler Liste der Service-UUIDs als Parameter gefragt, die zum Peripheral gehörenden Services zu finden (Listing 9). Analog zum Entdecken des Peripherals wird ein gefundener Service durch einen asynchronen Delegate Callback peripheral:diddiscoverservice: und eine gefundene Characteristic durch den Delegate Callback peripheral: diddiscovercharacteristics: signalisiert. In letzterem Fall sieht man im Beispielcode (Listing 10), dass die von uns gewünschte (und vom Peripheral bereitgestellte) Characteristic durch setnotifyvalue:forcharacteristic: subscribed wird. Dadurch erfolgt bei Änderungen des Werts auf Seiten des Peripherals in unserem Central ein Callback der Delegate-Methode peripheral:didupdatenotification- StateForCharacteristic:error: sowie ein Aufruf von peri pheral:didupdatevalueforcharacteristic:error:, der die empfangenen Chunks für die subscribed Characteristic entgegennimmt und in unserem Beispiel zu einem gesamten NSData-Objekt zusammenfügt, bis das EOM als Terminierungssignal empfangen wird (Listing 11). Im Beispiel trennen wir danach auch die Verbindung zum Peripheral mittels cancelperipheralconnection: und unsubscriben uns von der Characteristic. Damit haben wir auch schon alle Schritte durchgeführt, um Daten zwischen zwei BLE-Geräten abhängig von der Distanz zueinander auszutauschen. Wie man sieht... Wie man sieht, macht es das Core-Bluetooth-Framework einem Entwickler sehr einfach, die Funktionalität in eigene Apps zu integrieren und auch verschiedenste bereits vorhandene BLE-Endgeräte anzubinden, oder vielleicht sogar auch als Bastler mit z. B. Raspberry Pi und Bluetooth LE Dongle eigene externe Sensoren und Steuer-/Regelmechanismen zu entwerfen. Die zahl- Mobile Technology

11 Bluetooth LE und ios 6 ios 021 Listing 9: BizCardClient.m: Initialisierung des Centrals - (void)centralmanager:(cbcentralmanager *)central diddiscoverperipheral:(cbperipheral *)peripheral advertisementdata:(nsdictionary *)advertisementdata RSSI:(NSNumber *)RSSI // Reject any where the value is above reasonable range // Reject if the signal strength is too low to be close enough (Close is // around -22dB) if (RSSI.integerValue > kupperproximityrssilimit RSSI.integerValue < klowerproximityrssilimit) NSLog(@"Too far or too close RSSI: %@", RSSI); // Stops scanning for peripheral if close enough [self.centralmanager stopscan]; if (self.connectedperipheral!= peripheral) self.connectedperipheral = peripheral; NSLog(@"Connecting to peripheral %@", peripheral); NSLog(@"Advertisement Data %@ : %@", [advertisementdata objectforkey:cbadvertisementdatalocalnamekey], [advertisementdata objectforkey:cbadvertisementdataserviceuuidskey]); NSLog(@"RSSI: %@", RSSI); // Connects to the discovered peripheral [self.centralmanager connectperipheral:peripheral options:nil]; - (void)centralmanager:(cbcentralmanager *)central didconnectperipheral:(cbperipheral *)peripheral NSLog(@"didConnectPeripheral"); // Clears the data [self.data setlength:0]; // Set peripheral delegate peripheral.delegate = self; // Asks peripheral to discover service [peripheral discoverservices:@[ [CBUUID UUIDWithString:kCardServiceUUID] ]]; - (void)centralmanager:(cbcentralmanager *)central didfailtoconnectperipheral:(cbperipheral *)peripheral error:(nserror *)error if (error) NSLog(@"Error connecting to peripheral: %@", [error localizeddescription]); [self cleanup]; - (void)centralmanager:(cbcentralmanager *)central diddisconnectperipheral:(cbperipheral *)peripheral error:(nserror *)error if (error) NSLog(@"Error disconnecting peripheral: %@", [error localizeddescription]); [self cleanup]; self.connectedperipheral = nil; // Disconnected ==> start scanning again //[self scan]; Listing 10: BizCardClient.m: Services und Characteristics entdecken - (void)peripheral:(cbperipheral *)peripheral diddiscoverservices:(nserror *)error if (error) NSLog(@"Error discovering service: %@", [error localizeddescription]); [self cleanup]; for (CBService *service in peripheral.services) NSLog(@"Service found with UUID: %@", service.uuid); // Discovers the characteristics for a given service if ([service.uuid isequal:[cbuuid UUIDWithString:kCardServiceUUID]]) [peripheral discovercharacteristics:@[[cbuuid UUIDWithString:kCardCharacteristicUUID]] forservice:service]; - (void)peripheral:(cbperipheral *)peripheral diddiscovercharacteristicsforservice:(cbservice *)service error:(nserror *)error if (error) NSLog(@"Error discovering characteristic: %@", [error localizeddescription]); [self cleanup]; if ([service.uuid isequal:[cbuuid UUIDWithString:kCardServiceUUID]]) for (CBCharacteristic *characteristic in service.characteristics) if ([characteristic.uuid isequal:[cbuuid UUIDWithString:kCardCharacteristicUUID]]) // Subscribe to characteristic [peripheral setnotifyvalue:yes forcharacteristic:characteristic]; Mobile Technology

12 022 ios Bluetooth LE und ios 6 reichen Kaskaden über die diversen Delegate-Aufrufe durchzuführen, macht den Code leider nicht sehr übersichtlich, aber hier gibt es bereits erste Frameworks, die versuchen, durch Block-APIs zu verbessern. Die Bluetooth-LE-Technologie und Core Bluetooth als Framework stehen gemessen an den Möglichkeiten sicher noch ganz am Anfang und haben ein enormes Potenzial für weitere fantasievolle Anwendungsfälle. Unserer Meinung nach handelt es sich dabei um ein Zukunftsthema, dass man als ios-entwickler auf jeden Fall auf dem Radar behalten sollte. Wolfgang Frank ist Geschäftsführer der arconsis IT-Solutions GmbH aus Karlsruhe. Er beschäftigt sich seit mehreren Jahren hauptsächlich mit der Android- und ios-entwicklung. Als Agile Coach und Softwarearchitekt für komplexe Enterprise-Systeme unterstützt er Kunden beim Bau von Mobile Gateways zur Anbindung an die mobile Welt. Er schreibt für diverse Magazine Fachartikel und hält regelmäßig Vorträge auf Fachkonferenzen wie der MobileTech Con. Samuel Mellert ist seit 2012 bei der arconsis IT-Solutions GmbH im Bereich Mobile Software Development in der ios-entwicklung tätig. Davor hat er bereits fünf Jahre Berufserfahrung in der Erstellung verteilter skalierbarer Web Services bei einem großen deutschen Internetunternehmen gesammelt. Samuel ist unter anderem als Coach für ios-trainings und -Workshops tätig. Links & Literatur [1] invasivecode-blog: [2] Apple-Core-Bluetooth-Referenz: [3] WWDC 2012 Video Core Bluetooth 101 Session 703 [4] WWDC 2012 Video Advanced Core Bluetooth Session 705 [5] WWDC 2013 Video Core Bluetooth Session 703 [6] WWDC 2013 Video Nearby Networking with Multipeer Connectivity Session 708 [7] WWDC 2013 Video What s New in Core Location Session 307 [8] Beispielcode des Artikels: Listing 11: BizCardClient.m: Empfang von Daten an der Central // This callback lets us know more data has arrived via notification // on the characteristic - (void)peripheral:(cbperipheral *)peripheral didupdatevaluefor Characteristic:(CBCharacteristic *)characteristic error:(nserror *)error if (error) NSLog(@"Error discovering characteristics: %@", [error localizeddescription]); [self cleanup]; NSString *stringfromdata = [[NSString alloc] initwithdata:characteristic. value encoding:nsutf8stringencoding]; // Have we got everything we need? if ([stringfromdata isequaltostring:@"eom"]) // We have, so show the data NSString *receiveddata = [[NSString alloc] initwithdata:self.data encoding:nsutf8stringencoding]; NSLog(@"Received Data so far: %@", receiveddata); // Cancel our subscription to the characteristic [peripheral setnotifyvalue:no forcharacteristic:characteristic]; // and disconnect from the peripehral [self.centralmanager cancelperipheralconnection:peripheral]; dispatch_async(dispatch_get_main_queue(), ^ UIAlertView *alert = [[UIAlertView alloc] initwithtitle:@"received" message:@"data arrived" delegate:nil cancelbuttontitle:@"ok" otherbuttontitles:nil]; [alert show]; ); // Otherwise, just add the data on to what we already have [self.data appenddata:characteristic.value]; // Log it NSLog(@"Received: %@", stringfromdata); // The peripheral letting us know whether our subscribe/unsubscribe // happened or not - (void)peripheral:(cbperipheral *)peripheral didupdatenotificationstatefor Characteristic:(CBCharacteristic *)characteristic error:(nserror *)error if (error) NSLog(@"Error changing notification state: %@", error.localizeddescription); // Exit if it's not the transfer characteristic if (![characteristic.uuid isequal:[cbuuid UUIDWithString:kCardCharacteristicUUID]]) // Notification has started if (characteristic.isnotifying) NSLog(@"Notification began on %@", characteristic); // Notification has stopped else // so disconnect from the peripheral NSLog(@"Notification stopped on %@. Disconnecting", characteristic); [self.centralmanager cancelperipheralconnection:peripheral]; Mobile Technology