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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

(イメージ動画再⽣)

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

20バイトはこのくらい • UUID(123e4567-e89b-12d3-a456-426655440000) → 16バイト • Unixtime(1549449412) → 4バイト WebとBLEの違いその１：数バイトを意識する世界

Slide 21

Slide 21 text

20バイトじゃ  ⾜りない WebとBLEの違いその１：数バイトを意識する世界

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

(補⾜)他の⼿段 • パケット⻑(MTU)拡張 - 詳しくないけど⼤変そう - https://speakerdeck.com/coe/iosduan-mo- jian-de-detawosong-ru-blede WebとBLEの違いその１：数バイトを意識する世界

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

#1 情報の持ち⽅  情報はWebサーバーで持ち、  デバイスはシンプルに BLEアプリ設計ノウハウ

Slide 34

Slide 34 text

ロックに名前を持たせたい名前をつけてロックを  判別できるようにしたい＃1 情報の持ち⽅ BLEアプリ設計ノウハウ

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

Webサーバーの特徴 • ほぼどこでも通信できる • いつでもアップデートできる • 開発効率はデバイスより⾼い BLEアプリ設計ノウハウ＃1 情報の持ち⽅

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Webサーバーと同期したら、  デバイスの遠くからでも取れる BLEアプリ設計ノウハウ BLE Wi-Fi  3G/LTE デバイスアプリ Webサーバー 2 1 3 ＃2 同期は遅延を考慮

Slide 44

Slide 44 text

Webサーバーと同期した後、  ⼿動で解施錠されたら？ 4 3 BLE Wi-Fi  3G/LTE デバイスアプリ Webサーバー 2 1 BLEアプリ設計ノウハウ＃2 同期は遅延を考慮

Slide 45

Slide 45 text

デバイスとWebサーバーで不整合が起きる  (同期が遅延しているとも⾔える) BLEアプリ設計ノウハウ 4 3 BLE Wi-Fi  3G/LTE デバイスアプリ Webサーバー 2 1 ＃2 同期は遅延を考慮

Slide 46

Slide 46 text

同期の遅延が許容できない場合  Webサーバーと同期しないほうが良い BLE Wi-Fi  3G/LTE デバイスアプリ Webサーバー 2 1 BLEアプリ設計ノウハウ＃2 同期は遅延を考慮

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

#3 結果整合性   同期に失敗した時は  結果整合性を考慮する BLEアプリ設計ノウハウ

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

BLEアプリ設計ノウハウ＃3 結果整合性同期のシーケンス BLE Wi-Fi  3G/LTE デバイスアプリ Webサーバー 2 1 3

Slide 51

Slide 51 text

BLEアプリ設計ノウハウ＃3 結果整合性デバイスの設定に成功しても同期に失敗したら? BLE Wi-Fi  3G/LTE デバイスアプリ Webサーバー 2 1 3

Slide 52

Slide 52 text

BLEアプリ設計ノウハウ＃3 結果整合性元の設定に戻せる保証はない 4. 設定巻き戻し BLE Wi-Fi  3G/LTE デバイスアプリ Webサーバー 2 1 3

Slide 53

Slide 53 text

BLEアプリ設計ノウハウ＃3 結果整合性デバイスとWebサーバーで不整合が起きる 4. 設定巻き戻し BLE Wi-Fi  3G/LTE デバイスアプリ Webサーバー 2 1 3

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

設計イメージ 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アプリ設計ノウハウ #4〜#6 前提設計

Slide 62

Slide 62 text

• 何のシステムかを表現 • ユースケース(DDD的にはアプリケーション層)もドメイン層と  ⾔うことにしてますドメイン層 BLEアプリ設計ノウハウ #4〜#6 前提設計

Slide 63

Slide 63 text

ドメインじゃない層 • 何のシステムか以外を分離 • 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 BLEアプリ設計ノウハウ #4〜#6 前提設計

Slide 64

Slide 64 text

BLEアプリ設計ノウハウ #4 通信先はドメイン層の関⼼事   デバイス・Webサーバーは持つ情報も  通信プロトコルの性格も違うので  ドメイン層で区別して扱う

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

プロパティによって取得する通信先が違うデバイスのみ Webサーバーのみデバイス・  Webサーバー両⽅ BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事

Slide 67

Slide 67 text

Web・BLEは性格が異なるため、違うタイミングでnullが⼊るデバイスのみ  Bluetoothがオフ、  デバイスから遠いとnull Webサーバーのみ  オフラインだとnull デバイス・  Webサーバー両⽅ BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事

Slide 68

Slide 68 text

Web・BLEは性格が異なるため、  様々なタイミングでnullが⼊ってしまう nullが⼊るパターンが多くてコントロールできない BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事デバイスのみ  Bluetoothがオフ、  デバイスから遠いとnull Webサーバーのみ  オフラインだとnull デバイス・  Webサーバー両⽅

Slide 69

Slide 69 text

通信先によってモデルクラスを分ける Webサーバー向きデバイス向き BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

通信先を抽象化したドメイン層のクラスも  Webサーバー・デバイスで別にする BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事 Webサーバー向きデバイス向き

Slide 72

Slide 72 text

ドメインで通信先を意識したコードの例 BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事 ΦʔτϩοΫͷΦϯΦϑΛઃఆΛ͢Δ ϩοΫͷઃఆΛ͢ΔϢʔεέʔε

Slide 73

Slide 73 text

BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事 Webαʔόʔ(͔ϩʔΧϧΩϟογϡ)͔ΒϩοΫΛอଘऔಘ σόΠεͱͷ΍ΓͱΓ

Slide 74

Slide 74 text

BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事 Webαʔόʔ(͔ϩʔΧϧΩϟογϡ)͔ΒϩοΫΛऔಘ

Slide 75

Slide 75 text

BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事 σόΠεͷઃఆΛมߋ

Slide 76

Slide 76 text

BLEアプリ設計ノウハウ＃4 通信先はドメイン層の関⼼事 Webαʔόʔ(ͱϩʔΧϧΩϟογϡ)ʹσόΠεͷઃఆΛ൓ө

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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は専⽤アプリを作る

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

Qrio Lock でMVVMを採⽤した理由 • MVCはイマドキ(2017/10頃)じゃない的な判断、、 • プレゼンテーションロジックをテストできる BLEアプリ設計ノウハウ＃6 UIは簡素に設計

Slide 83

Slide 83 text

• リターン - UIからプレゼンテーションロジックを分離できる - プレゼンテーションロジックをテストできる • コスト - MVVMの実装コスト - MVVMのベストプラクティスを探るコスト BLEアプリ設計ノウハウ＃6 UIは簡素に設計 MVVMのリターンとコストを考える

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

さいごに

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

Thank you