BLEアプリ設計パターン / ble_app_pattern

BLEアプリ設計パターン
• セッションのゴール
- BLEを使ったアプリを開発する⾯⽩さが伝わる
- BLEを使ったアプリを設計するときに役⽴つノウハウを知ってもらう
• 話さないこと
- BLEの詳しい仕様
- AndroidのBLEが⼤変、、みたいな話 
(なぜか接続ができないみたいな) @8yabusa
DroidKaigi2019

View Slide

BLEアプリ 
設計パターン
@8yabusa
DroidKaigi 2019

View Slide

⾃⼰紹介
• 8yabusa(Tomohiko Sato)
• (~2017/09)ドワンゴで⾳楽系サービス開発など
• (~現在)Qrio.incリードエンジニア
- QrioLockアプリ開発など

View Slide

対象者
• BLE(Bluetooth Low Energy)に興味がある⼈
• BLEを使ったアプリの設計に興味がある⼈

View Slide

話したいこと
• BLEってどんなプロトコルなのか
• QrioLockの事例で考えるBLEアプリ設計のノウハウ

View Slide

(イメージ動画再⽣)

View Slide

• スマホで解施錠
• オートロック
• ハンズフリー解錠
• カギのシェア
• 解施錠履歴の確認や通知

View Slide

スマホとロックの通信に 
BLE(Bluetooth Low Energy)を使⽤

View Slide

BLEって？
• Bluetooth v4.0から⼊った 
省電⼒(Low Energy)なBluetooth規格
• それまでのBluetooth規格(=クラシック
Bluetooth)と違い、少量のデータを低頻度で 
やりとりするのに適切
• データ量が多いものや、やりとりが⾼頻度の
データはクラシックBluetoothが適切 
(例: ⾳声)
BLE

View Slide

なぜBLE？
Wi-Fiとかの⽅が便利なのでは？

View Slide

BLE
• BLEだと１年
• Wi-Fiだと(たぶん)1ヶ⽉
なぜBLE？
1.省電⼒

View Slide

BLE
• BLEの⼀部である 
ビーコンのこと
• ハンズフリー解錠に 
使える
なぜBLE？
2.近接検知

View Slide

Web経由もサポート
• QrioHubという拡張セットがある
• ロックの近くのコンセントに挿して使う
• 遠隔解施錠とかできるようになる
https
BLE
Qrio Hub
なぜBLE？

View Slide

BLEって 
どんなプロトコルなのか

View Slide

WebとBLEの違い
BLEってどんなプロトコルなのか

View Slide

Webの世界
Retroﬁt サイコー
BLEってどんなプロトコルなのか WebとBLEの違い

View Slide

BLEの世界
その１

View Slide

数バイトを意識する世界
WebとBLEの違いその１

View Slide

通信パケットは
20バイト
WebとBLEの違いその１：数バイトを意識する世界

View Slide

20バイトはこのくらい
• UUID(123e4567-e89b-12d3-a456-426655440000) → 16バイト
• Unixtime(1549449412) → 4バイト

View Slide

20バイトじゃ 
⾜りない

View Slide

リクエストが20バイトを超えたら
1バイト 19バイト
リクエスト
パケットパケットパケット
WebとBLEの違い
19バイトに分割、先頭１バイトに順番情報を付けて 
送信、受け取る側で順番情報を⾒てくっつける
その１：数バイトを意識する世界

View Slide

(補⾜)他の⼿段
• パケット⻑(MTU)拡張
- 詳しくないけど⼤変そう
- https://speakerdeck.com/coe/iosduan-mo-
jian-de-detawosong-ru-blede

View Slide

BLEの世界
その２

View Slide

⾃前でセキュリティを 
担保する可能性がある世界
WebとBLEの違いその2

View Slide

BLEが提供するセキュリティは制限付き
• BLEは最初の鍵交換に制限がある。 
例えば以下のようなもの
- デバイスのディスプレイに表⽰されたPINコードを 
スマホで⼊⼒し、数字から鍵を⽣成
• 普通にBLEで鍵交換すると傍受されてしまうため
• QrioLockにディスプレイは無い 
→BLEのセキュリティには乗っかれない
WebとBLEの違いその2：⾃前でセキュリティを担保する

View Slide

BLE単体では成し得ない 
⾃前のセキュリティが必要
• あらかじめ共通情報をWebサーバーと 
デバイスで持つなど
• 僕はセキュリティの設計をしてないですが、 
実装するのに「暗号技術⼊⾨」が 
役に⽴ちました
WebとBLEの違いその2：⾃前でセキュリティを担保する

View Slide

BLEの世界まとめ
• Webに⽐べてとてもプリミティブな世界
• 数バイトを気にする
• セキュリティを⾃前で担保する可能性

View Slide

BLEどうですか？

View Slide

Qrio Lock の事例で考える 
BLEアプリ設計ノウハウ

View Slide

デバイス・Webサーバーの 
情報に関するノウハウ
#1 情報の持ち⽅
#2 同期の遅延を考慮
#3 結果整合性
アプリ設計に関する 
ノウハウ
#4 通信先はドメイン層の関⼼事
#5 BLE通信は専⽤アプリを作る 
#6 UIは簡素に設計する

View Slide

通信経路の構成
デバイスアプリ Webサーバー
BLEアプリ設計ノウハウ #1〜#3
BLE
Wi-Fi 
3G/LTE

View Slide

#1 情報の持ち⽅ 
情報はWebサーバーで持ち、 
デバイスはシンプルに

View Slide

ロックに名前を
持たせたい
名前をつけてロックを 
判別できるようにしたい
＃1 情報の持ち⽅

View Slide

「ロックの名前」をデバイスとWebサーバー
どちらが持つべきか？
BLEアプリ設計ノウハウ＃1 情報の持ち⽅

View Slide

デバイスの特徴
• 近くじゃないと通信できない。 
BLEなので数m程度。
• なるべくシンプルにしたい
- アップデートが⼤変 
(ユーザーがアプリからアップデートする)
- 故障する可能性(交換可能にしたい)
- 開発効率低い(C⾔語)
- メモリの制約

View Slide

Webサーバーの特徴
• ほぼどこでも通信できる
• いつでもアップデートできる
• 開発効率はデバイスより⾼い

View Slide

「ロックの名前」を
デバイスとWebサーバーのどちらが持つべき？
• Webサーバーに持たせる
- デバイスはシンプルにしたい
- Webならどこでも取得更新ができる
＃1 情報の持ち⽅
Q

View Slide

情報はWebサーバーで持ち、デバイスはシンプルに
⼀般化
「ロックの名前」を
デバイスとWebサーバーのどちらが持つべき？
Q
• Webサーバーに持たせる
- デバイスはシンプルにしたい
- Webならどこでも取得更新ができる

View Slide

#2 同期は遅延を考慮 
スマホが中継する同期は常に出来るわけでは
ない。なので、デバイス・Webサーバーの 
同期は遅延を考慮する

View Slide

ロックの解施錠状態が 
知りたい
• 次に開けるべきか閉めるべきかも 
⾃ずと決まる
＃2 同期は遅延を考慮

View Slide

デバイスから取る
BLE
Wi-Fi 
3G/LTE
2
1
BLEアプリ設計ノウハウ＃2 同期は遅延を考慮

View Slide

Webサーバーと同期したら、 
デバイスの遠くからでも取れる
BLE
Wi-Fi 
3G/LTE
2
1
3

View Slide

Webサーバーと同期した後、 
⼿動で解施錠されたら？
4
3
BLE
Wi-Fi 
3G/LTE
2
1

View Slide

デバイスとWebサーバーで不整合が起きる 
(同期が遅延しているとも⾔える)
4
3
BLE
Wi-Fi 
3G/LTE
2
1

View Slide

同期の遅延が許容できない場合 
Webサーバーと同期しないほうが良い
BLE
Wi-Fi 
3G/LTE
2
1

View Slide

同期は遅延を考慮する
•デバイスとWebサーバー間の同期をスマホが中継する場合、 
同期の遅延を許容する
•同期の遅延が許容できない場合は以下を検討する
1. そもそもWebサーバーと同期しない
2. 頻繁に同期できる通信経路を設ける
1. デバイス⾃体がWi-Fi/LTE通信できるようにする
2. QrioHubのようなゲートウェイデバイスを⽤意する

View Slide

#3 結果整合性  
同期に失敗した時は 
結果整合性を考慮する

View Slide

BLEアプリ設計ノウハウ＃3 結果整合性
オートロックの
設定をしたい
• デバイスとWebサーバーで設定を 
同期した場合を考えてみる
• 同期した場合 
どこからでも閲覧できるのがメリット

View Slide

同期のシーケンス
BLE
Wi-Fi 
3G/LTE
2
1
3

View Slide

デバイスの設定に成功しても
同期に失敗したら?
BLE
Wi-Fi 
3G/LTE
2
1
3

View Slide

元の設定に戻せる保証はない
4. 設定巻き戻し
BLE
Wi-Fi 
3G/LTE
2
1
3

View Slide

デバイスとWebサーバーで不整合が起きる
4. 設定巻き戻し
BLE
Wi-Fi 
3G/LTE
2
1
3

View Slide

デバイスとWebサーバーの 
同期に失敗したら
• 完全な整合性は(たぶん)無理
• 時間が経てば整合性がとれるようにする(結果整合性)

View Slide

結果整合性を取るだけで 
いろんな選択肢がある
• どのような選択肢があるかは時間の都合でカットしました
- ʮBluetoothΘ͔ΜͶ͐Αͳ͊ʂϋϜଠ࿠ʂʯΛࢀর͍ͩ͘͞ 
https://speakerdeck.com/tomohikosato/bluetooth-hamutaro-
d7f061c5-d5fb-438c-b1d3-062d63b11614

View Slide

結果整合性を扱うにあたって 
APIのべき等性が重要
• べき等なAPIとは、何度呼んでも結果が変わらない 
APIのこと
• BLEアプリ開発では、結果整合性をとるために同期処理や
リトライ処理が発⽣しがち
- 同じリクエストを何度呼んでも⼤丈夫にしておく
- 基本的にべき等なAPIが良いが、 
結果整合性を扱うなら更に重要

View Slide

べき等なAPIの例
1. 設定を更新する
- 叩くたび設定が逆になる {autolock_toggle: true}
- 何回叩いても同じ設定になる {autolock: true}
2. ログをアップロードする
- 同じログをPOSTすると重複して作られる
- ログにIDを付けて識別し、同じログをPOSTしても 
重複して作られないようにする

View Slide

デバイス・Webサーバーの情報に関する 
ノウハウまとめ
BLEアプリ設計ノウハウ #1〜#3まとめ
1. 情報はWebサーバーで持ち、デバイスはシンプルに
2. 同期の遅延を考慮する
- 同期しないことを検討したり、 
常に同期できる別の通信経路を検討する
3. 同期に失敗したら結果整合性を考慮する
- 結果整合性を扱うにあたってAPIのべき等性が⼤事

View Slide

デバイス・Webサーバーの 
情報に関するノウハウ
#1 情報の持ち⽅
#2 同期の遅延を考慮
#3 結果整合性
アプリ設計に関する 
ノウハウ
#5 BLE通信は専⽤アプリを作る 
#6 UIは簡素に設計する

View Slide

前提:アプリの設計
BLEアプリ設計ノウハウ #4〜#6 前提設計
Qrio Lock はクリーンアーキテクチャみたいな設計
(正確な定義に則っているかは⾃信ありません)

View Slide

設計イメージ
Presentation Infra
Domain
Model
Entity
ValueObject
DomainService
Repository
UI
Service/
Background
Task
Broadcast
Receiver/
AppDelegate
Dao
WebAPI
Preference
UseCase
Model Impl
DomainServiceImpl
RepositoryImpl
use
use
use
depends
BLE

View Slide

• 何のシステムかを表現
• ユースケース(DDD的にはアプリ
ケーション層)もドメイン層と 
⾔うことにしてます
ドメイン層

View Slide

ドメインじゃない層
• 何のシステムか以外を分離
• UIでどのように表現するか、 
Android SDKからどのように
呼ばれるか(Presentation層)
• データをどのように保存取得
するか(Infra層)
Presentation Domain
Model
Entity
ValueObject
DomainService
Repository
UI
Service/
Background
Task
Broadcast
Receiver/
AppDelegate
UseCase
use
use
depends
Presentation Infra
Domain
Model
Entity
ValueObject
DomainService
Repository
UI
Service/
Background
Task
Broadcast
Receiver/
AppDelegate
Dao
WebAPI
Preference
UseCase
Model Impl
DomainServiceImpl
RepositoryImpl
use
use
use
depends
BLE

View Slide

 
デバイス・Webサーバーは持つ情報も 
通信プロトコルの性格も違うので 
ドメイン層で区別して扱う

View Slide

ドメイン層のモデルクラスを考えてみる
BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事

View Slide

プロパティによって取得する通信先が違う
デバイスのみ
Webサーバーのみ
デバイス・ 
Webサーバー両⽅

View Slide

Web・BLEは性格が異なるため、
違うタイミングでnullが⼊る
デバイスのみ 
Bluetoothがオフ、 
デバイスから遠いとnull
Webサーバーのみ 
オフラインだとnull
デバイス・ 

View Slide

Web・BLEは性格が異なるため、 
様々なタイミングでnullが⼊ってしまう
nullが⼊るパターンが多くてコントロールできない
デバイスのみ 
Bluetoothがオフ、 
デバイスから遠いとnull
Webサーバーのみ 
オフラインだとnull
デバイス・ 

View Slide

通信先によってモデルクラスを分ける
Webサーバー向き
デバイス向き

View Slide

通信先がドメインの関⼼事となっている
会話で頻繁にWebサーバー・デバイスが出てくる
「ロック設定画⾯はデバイスと通信するっけ？」

View Slide

通信先を抽象化したドメイン層のクラスも 
Webサーバー・デバイスで別にする
Webサーバー向き
デバイス向き

View Slide

ドメインで通信先を意識したコードの例
ΦʔτϩοΫͷΦϯΦϑΛઃఆΛ͢Δ
ϩοΫͷઃఆΛ͢ΔϢʔεέʔε

View Slide

Webαʔόʔ(͔ϩʔΧϧΩϟογϡ)͔ΒϩοΫΛอଘऔಘ
σόΠεͱͷ΍ΓͱΓ

View Slide

Webαʔόʔ(͔ϩʔΧϧΩϟογϡ)͔ΒϩοΫΛऔಘ

View Slide

σόΠεͷઃఆΛมߋ

View Slide

Webαʔόʔ(ͱϩʔΧϧΩϟογϡ)ʹσόΠεͷઃఆΛ൓ө

View Slide

#5 BLE通信は専⽤アプリを作る  
デバイスの動作確認をしたいケースが 
多いため、BLE通信部分は 
別モジュールにして専⽤アプリを作る

View Slide

Presentation Infra
Domain
Model
Entity
ValueObject
DomainService
Repository
UI
Service/
Background
Task
Broadcast
Receiver/
AppDelegate
Dao
WebAPI
Preference
UseCase
Model Impl
DomainServiceImpl
RepositoryImpl
use
use
use
depends
BLE
別モジュール
BLEアプリ設計ノウハウ＃5 BLEは専⽤アプリを作る

View Slide

BLE通信部分は別モジュールにして
専⽤アプリを作る
BLEアプリ設計ノウハウ＃5 BLEは専⽤アプリを作る
• デバイスの動作確認をしたいケースが多いため
- デバイス開発チームの動作確認
- バグの原因の切り分け(デバイスか、それ以外か)
- ⼯場でのデバイスの動作確認

View Slide

#6 UIは簡素に設計 
簡素なUIが多いので、 
MVP/MVVMといったパターンが 
冗⻑になる画⾯が多いかもしれない

View Slide

• Qrio Lockの場合、機器の登録や設定画⾯が多い
• IoT系アプリは機器の登録や設定など、 
簡素なUIが多くなりがち
• (もちろんサービス次第です)
BLEアプリ設計ノウハウ＃6 UIは簡素に設計
IoTのUIは簡素

View Slide

Qrio Lock でMVVMを採⽤した理由
• MVCはイマドキ(2017/10頃)じゃない的な判断、、
• プレゼンテーションロジックをテストできる

View Slide

• リターン
- UIからプレゼンテーションロジックを分離
できる
- プレゼンテーションロジックをテストでき
る
• コスト
- MVVMの実装コスト
- MVVMのベストプラクティスを探るコスト
MVVMのリターンとコストを考える

View Slide

MVVMのリターンとコストを考える
؆ૉͳUIͩͱ 
ϝϦοτ͕ബ͍
؆ૉͳUIͰ΋ 
ίετ͸͔͔Δ
• リターン
- UIからプレゼンテーションロジックを分離
できる
- プレゼンテーションロジックをテストでき
る
• コスト
- MVVMの実装コスト
- MVVMのベストプラクティスを探るコスト

View Slide

• MVVMのようなView周りの複雑さを解消する設計は 
あまり機能しなかった
• MVVMをやるなら複雑な画⾯に対してのみ適⽤するのが良い(?)
• BLEアプリではUIよりも複雑になりそうな箇所がある。そちらを重点的に設計
- #4で話したような、通信先をドメインで扱う設計とか
- エラーハンドリングとか(通信先が増える分、エラーのパターンが増える)
UIは簡素に設計

View Slide

アプリ設計に関するノウハウ
• ドメインで通信先(デバイス・Webサーバー)を意識する
• BLE通信部分は別モジュールに切り出して専⽤アプリを作る
• 簡素なUIが多いので、MVP/MVVMといったパターンが 
冗⻑になる画⾯が多いかもしれない
BLEアプリ設計ノウハウ #4〜#6 まとめ

View Slide

さいごに

View Slide

試⾏錯誤でやってます
• あくまでQrioLockアプリ開発を通して学んだ 
個⼈の⾒解です
• 代案などあればぜひ教えてください！
• カットした内容はまたどこかで話したい

View Slide

BLEアプリ開発のおもしろさ
• 類例が少ないので「そもそも」を考える機会が多い
- デバイスとWebサーバーで情報を同期すべきか、とか
- ドメインで通信を意識するべきかどうか、とか
• アプリ開発以外の⽂脈に類例が⾒つかったりする
- 結果整合性とか

View Slide

Thank you

View Slide

BLEアプリ設計パターン / ble_app_pattern

BLEアプリ設計パターン / ble_app_pattern

8yabusa

More Decks by 8yabusa

Other Decks in Programming

Featured

Transcript