iOSでのBluetooth通信入門 :CoreBluetooth プログラミングガイド 解説 :ローカルデバイスをペリフェラルとしてセットアップするためのベストプラクティス

bluetooth-ios_001

目次 > ローカルデバイスをペリフェラルとしてセットアップするためのベストプラクティス

 Apple「CoreBluetoothプログラミングガイド」+独自解説


Core Bluetoothフレームワークは、セントラル側のさまざまなトランザクションだけでなく、ペリフェラルとしての役割を実装するためにも有用です。この章では、これを的確に行うためのガイドラインやベストプラクティスを紹介します。

アドバタイズに関する検討事項

ローカルデバイスにペリフェラルとしての役割を実装する上で、データのアドバタイズ機能は重要な要素です。以下の各節で、適切に実装するための考慮事項を説明します。

アドバタイズするデータの制限事項を考慮する

ペリフェラルのデータをアドバタイズするためには、当該データの辞書を渡して、 CBPeripheralManagerクラスのstartAdvertising:メソッドを実行します(“サービスをアドバタイ ズする” (27 ページ)を参照)。辞書を生成する際、何をいくつアドバタイズできるか、に関して制限があることを考慮してください。 アドバタイズパケットには一般に、ペリフェラルに関するさまざまな情報を収容できますが、アドバタイズするのはデバイスのローカル名とサービスのUUIDだけです。したがって、アドバタイズ辞書のキーとして、CBAdvertisementDataLocalNameKeyとCBAdvertisementDataServiceUUIDsKeyの2つだけを指定します。他のキーを指定すればエラーになります。 さらに、アドバタイズの容量にも制限があります。アプリケーションがフォアグラウンド状態であれば、2つのアドバタイズデータキーを組み合わせて、当初は28バイト分までのアドバタイズデータを指定できます。これで不足する場合、走査に対する応答で、ローカル名に用いる10バイトを追加できます。この領域に入りきらないサービスUUIDは、特別な「オーバーフロー」領域に追加します。これを検出するためには、明示的に当該UUIDを指定して走査しなければなりません。一方、バックグラウンド状態の場合、ローカル名はアドバタイズの対象外であり、サービスUUIDはすべてオーバーフロー領域に入ります。 注意: この長さには、ヘッダ情報の2バイト(新しいデータ型ごとに必要)を含みません。 アドバタイズデータや応答データの具体的な形式は、Bluetooth 4.0仕様のVolume 3、Part C、 Section 11に定義されています。 この制限内に収まるよう、主サービスのUUIDのみアドバタイズするようにしてください。

必要のないデータはアドバタイズしない

ペリフェラルのデータをアドバタイズするにはローカルデバイスの電波(および電池)を使うことになるので、他のデバイスに接続してほしいときのみ、アドバタイズを出すようにしてください。いったん接続すれば、アドバタイズパケットがなくても、データを直接調査し、やり取りできます。したがって、電波の使用を最小限に抑え、処理性能を改善し、電池の寿命を延ばすためにも、必要なくなったらアドバタイズを止めてください。これがBLEトランザクション本来の使い方です。アドバタイズを止めるには、CBPeripheralManagerクラスのstopAdvertisingメソッドを使います。

 [myPeripheralManager stopAdvertising];

アドバタイズを出すか否かユーザが判断できるようにする

アドバタイズを出すべきか否か、ユーザにしか判断できないことも少なくありません。たとえば、近くに他のBLE機器がないと分かっている場合、アドバタイズしても無意味です。これをアプリケーションが判断するのは難しいので、ユーザが判断できるよう、適当なユーザインターフェイスを設けるとよいでしょう。

特性を設定する

可変の特性に対しては、プロパティ、値、操作権限を設定することになります。これによって、セントラルがどのようにアクセスし、特性値をやり取りするか、が決まります。特性のプロパティや操作権限は、アプリケーションの必要性に応じて設定してください。以下、次の2通りを想定して、いくつかガイダンスを示します。

● セントラルによる特性値の通知申し込みを受け付ける場合 ● 重要な特性値について、ペアリングしたセントラルからのアクセス以外を拒否する場合

通知の申し込みに対応できるよう特性を設定する

“頻繁に変化する特性については、値の変化を通知するよう申し込む” で説明したように、頻繁に変化する(リモートペリフェラルのサービスの)特性値については、通知機能を用いるよう推奨します。できるだけ、特性値の変化を通知するよう、セントラルが申し込めるようにしてください。 可変の特性を生成する際、通知の申し込みに対応できるようにするためには、特性のプロパティとして定数CBCharacteristicPropertyNotifyを指定します。

 myCharacteristic = [[CBMutableCharacteristic alloc]

initWithType:myCharacteristicUUID

properties:CBCharacteristicPropertyRead | CBCharacteristicPropertyNotify

value:nil permissions:CBAttributePermissionsReadable];

この例に示した特性値は読み取り可能であり、セントラルからの通知申し込みにも対応できます。

重要なデータについて、ペアリングした機器からのアクセスのみを許可する

用途によっては、特性値のやり取りに際して、セキュリティを考慮しなければならないかも知れません。たとえばソーシャルメディアサービスを考えてみましょう。このサービスでは、会員の名前や電子メールアドレスなど、個人情報を特性として扱うかも知れません。そして、電子メールアドレスについては、信頼性を確認したデバイスからのアクセスしか許可しない、という要件も考えられます。 これを実現するためには、特性のプロパティと操作権限を適切に設定する必要があるでしょう。そのコード例を示します。

 emailCharacteristic = [[CBMutableCharacteristic alloc]

nitWithType:emailCharacteristicUUID

properties:CBCharacteristicPropertyRead

| CBCharacteristicPropertyNotifyEncryptionRequired

value:nil permissions:CBAttributePermissionsReadEncryptionRequired];

この例では、信頼できるデバイスにしか読み取りや通知を許可しないよう、特性を設定しました。リモートのセントラルは、接続後、特性値を読み取ろうと(または通知を申し込もうと)します。するとCore Bluetoothは、ローカルのペリフェラルとペアリング手続きをして、信頼性を確認しようと試みます。 セントラルとペリフェラルがどちらもiOSデバイスであれば、両方に、この手続きを行う旨の画面が 現れます。セントラルの画面に現れているコードを、ペリフェラルのテキストフィールドに正しく入力すれば、手続きは完了です。 ペリフェラルはこのセントラルが信頼できるものと判断し、暗号化を施した特性値へのアクセスを許可します。

 


※ このコンテンツはアップル社の提供する「CoreBluetoothプログラミングガイド」というPDFをwebの形式に変換したものをベースとしています。ページ中に含まれる図やテキストは「CoreBluetoothプログラミングガイド」からの引用が多く含まれます。PDFの形式ではなくウェブの形式で閲覧したい方への利便性を高めることや、「CoreBluetoothプログラミングガイド」だけではわかりにくいという箇所の捕捉を行うことが当コンテンツの主旨です。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です