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

DroidKaigi2019 での発表です
QrioLockアプリ開発の経験をベースにAndroidのBLE(Bluetooth Low Energy)を使ったアプリ開発のノウハウを話しました

Transcript

1. BLEアプリ設計パターン • セッションのゴール - BLEを使ったアプリを開発する⾯⽩さが伝わる - BLEを使ったアプリを設計するときに役⽴つノウハウを知ってもらう • 話さないこと - BLEの詳しい仕様 - AndroidのBLEが⼤変、、みたいな話
 (なぜか接続ができないみたいな) @8yabusa DroidKaigi2019
2. BLEアプリ
 設計パターン @8yabusa DroidKaigi 2019
3. ⾃⼰紹介 • 8yabusa(Tomohiko Sato) • (~2017/09)ドワンゴで⾳楽系サービス開発など • (~現在)Qrio.incリードエンジニア - QrioLockアプリ開発など
4. 対象者 • BLE(Bluetooth Low Energy)に興味がある⼈ • BLEを使ったアプリの設計に興味がある⼈
5. 話したいこと • BLEってどんなプロトコルなのか • QrioLockの事例で考えるBLEアプリ設計のノウハウ
6. (イメージ動画再⽣)
7. • スマホで解施錠 • オートロック • ハンズフリー解錠 • カギのシェア • 解施錠履歴の確認や通知
8. スマホとロックの通信に
 BLE(Bluetooth Low Energy)を使⽤
9. BLEって？ • Bluetooth v4.0から⼊った
 省電⼒(Low Energy)なBluetooth規格 • それまでのBluetooth規格(=クラシック Bluetooth)と違い、少量のデータを低頻度で
 やりとりするのに適切 • データ量が多いものや、やりとりが⾼頻度の データはクラシックBluetoothが適切
 (例: ⾳声) BLE
10. なぜBLE？ Wi-Fiとかの⽅が便利なのでは？
11. BLE • BLEだと１年 • Wi-Fiだと(たぶん)1ヶ⽉ なぜBLE？ 1.省電⼒
12. BLE • BLEの⼀部である
 ビーコンのこと • ハンズフリー解錠に
 使える なぜBLE？ 2.近接検知
13. Web経由もサポート • QrioHubという拡張セットがある • ロックの近くのコンセントに挿して使う • 遠隔解施錠とかできるようになる https BLE Qrio Hub なぜBLE？
14. BLEって
 どんなプロトコルなのか
15. WebとBLEの違い BLEってどんなプロトコルなのか
16. Webの世界 Retrofit サイコー BLEってどんなプロトコルなのか WebとBLEの違い
17. BLEの世界 その１ BLEってどんなプロトコルなのか WebとBLEの違い
18. 数バイトを意識する世界 WebとBLEの違い その１
19. 通信パケットは 20バイト WebとBLEの違い その１：数バイトを意識する世界
20. 20バイトはこのくらい • UUID(123e4567-e89b-12d3-a456-426655440000) → 16バイト • Unixtime(1549449412) → 4バイト WebとBLEの違い その１：数バイトを意識する世界
21. 20バイトじゃ
 ⾜りない WebとBLEの違い その１：数バイトを意識する世界
22. リクエストが20バイトを超えたら 1バイト 19バイト リクエスト パケット パケット パケット WebとBLEの違い 19バイトに分割、先頭１バイトに順番情報を付けて
 送信、受け取る側で順番情報を⾒てくっつける その１：数バイトを意識する世界
23. (補⾜)他の⼿段 • パケット⻑(MTU)拡張 - 詳しくないけど⼤変そう - https://speakerdeck.com/coe/iosduan-mo- jian-de-detawosong-ru-blede WebとBLEの違い その１：数バイトを意識する世界
24. BLEの世界 その２ BLEってどんなプロトコルなのか WebとBLEの違い
25. ⾃前でセキュリティを
 担保する可能性がある世界 WebとBLEの違い その2
26. BLEが提供するセキュリティは制限付き • BLEは最初の鍵交換に制限がある。
 例えば以下のようなもの - デバイスのディスプレイに表⽰されたPINコードを
 スマホで⼊⼒し、数字から鍵を⽣成 • 普通にBLEで鍵交換すると傍受されてしまうため • QrioLockにディスプレイは無い
 →BLEのセキュリティには乗っかれない WebとBLEの違い その2：⾃前でセキュリティを担保する
27. BLE単体では成し得ない
 ⾃前のセキュリティが必要 • あらかじめ共通情報をWebサーバーと
 デバイスで持つなど • 僕はセキュリティの設計をしてないですが、
 実装するのに「暗号技術⼊⾨」が
 役に⽴ちました WebとBLEの違い その2：⾃前でセキュリティを担保する
28. BLEの世界まとめ • Webに⽐べてとてもプリミティブな世界 • 数バイトを気にする • セキュリティを⾃前で担保する可能性 BLEってどんなプロトコルなのか WebとBLEの違い
29. BLEってどんなプロトコルなのか WebとBLEの違い BLEどうですか？
30. Qrio Lock の事例で考える
 BLEアプリ設計ノウハウ
31. デバイス・Webサーバーの
 情報に関するノウハウ #1 情報の持ち⽅ #2 同期の遅延を考慮 #3 結果整合性 BLEアプリ設計ノウハウ アプリ設計に関する
 ノウハウ #4 通信先はドメイン層の関⼼事 #5 BLE通信は専⽤アプリを作る
 #6 UIは簡素に設計する
32. 通信経路の構成 デバイス アプリ Webサーバー BLEアプリ設計ノウハウ #1〜#3 BLE Wi-Fi
 3G/LTE
33. #1 情報の持ち⽅
 情報はWebサーバーで持ち、
 デバイスはシンプルに BLEアプリ設計ノウハウ
34. ロックに名前を 持たせたい 名前をつけてロックを
 判別できるようにしたい ＃1 情報の持ち⽅ BLEアプリ設計ノウハウ
35. 「ロックの名前」をデバイスとWebサーバー どちらが持つべきか？ BLEアプリ設計ノウハウ ＃1 情報の持ち⽅
36. デバイスの特徴 • 近くじゃないと通信できない。
 BLEなので数m程度。 • なるべくシンプルにしたい - アップデートが⼤変
 (ユーザーがアプリからアップデートする) - 故障する可能性(交換可能にしたい) - 開発効率低い(C⾔語) - メモリの制約 BLEアプリ設計ノウハウ ＃1 情報の持ち⽅
37. Webサーバーの特徴 • ほぼどこでも通信できる • いつでもアップデートできる • 開発効率はデバイスより⾼い BLEアプリ設計ノウハウ ＃1 情報の持ち⽅
38. 「ロックの名前」を デバイスとWebサーバーのどちらが持つべき？ BLEアプリ設計ノウハウ • Webサーバーに持たせる - デバイスはシンプルにしたい - Webならどこでも取得更新ができる ＃1 情報の持ち⽅ Q
39. 情報はWebサーバーで持ち、デバイスはシンプルに ⼀般化 「ロックの名前」を デバイスとWebサーバーのどちらが持つべき？ Q BLEアプリ設計ノウハウ ＃1 情報の持ち⽅ • Webサーバーに持たせる - デバイスはシンプルにしたい - Webならどこでも取得更新ができる
40. #2 同期は遅延を考慮
 スマホが中継する同期は常に出来るわけでは ない。なので、デバイス・Webサーバーの
 同期は遅延を考慮する BLEアプリ設計ノウハウ
41. ロックの解施錠状態が
 知りたい • 次に開けるべきか閉めるべきかも
 ⾃ずと決まる ＃2 同期は遅延を考慮 BLEアプリ設計ノウハウ
42. デバイスから取る BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 BLEアプリ設計ノウハウ ＃2 同期は遅延を考慮
43. Webサーバーと同期したら、
 デバイスの遠くからでも取れる BLEアプリ設計ノウハウ BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 3 ＃2 同期は遅延を考慮
44. Webサーバーと同期した後、
 ⼿動で解施錠されたら？ 4 3 BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 BLEアプリ設計ノウハウ ＃2 同期は遅延を考慮
45. デバイスとWebサーバーで不整合が起きる
 (同期が遅延しているとも⾔える) BLEアプリ設計ノウハウ 4 3 BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 ＃2 同期は遅延を考慮
46. 同期の遅延が許容できない場合
 Webサーバーと同期しないほうが良い BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 BLEアプリ設計ノウハウ ＃2 同期は遅延を考慮
47. 同期は遅延を考慮する •デバイスとWebサーバー間の同期をスマホが中継する場合、
 同期の遅延を許容する •同期の遅延が許容できない場合は以下を検討する 1. そもそもWebサーバーと同期しない 2. 頻繁に同期できる通信経路を設ける 1. デバイス⾃体がWi-Fi/LTE通信できるようにする 2. QrioHubのようなゲートウェイデバイスを⽤意する BLEアプリ設計ノウハウ ＃2 同期は遅延を考慮
48. #3 結果整合性 
 同期に失敗した時は
 結果整合性を考慮する BLEアプリ設計ノウハウ
49. BLEアプリ設計ノウハウ ＃3 結果整合性 オートロックの 設定をしたい • デバイスとWebサーバーで設定を
 同期した場合を考えてみる • 同期した場合
 どこからでも閲覧できるのがメリット
50. BLEアプリ設計ノウハウ ＃3 結果整合性 同期のシーケンス BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 3
51. BLEアプリ設計ノウハウ ＃3 結果整合性 デバイスの設定に成功しても 同期に失敗したら? BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 3
52. BLEアプリ設計ノウハウ ＃3 結果整合性 元の設定に戻せる保証はない 4. 設定巻き戻し BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 3
53. BLEアプリ設計ノウハウ ＃3 結果整合性 デバイスとWebサーバーで不整合が起きる 4. 設定巻き戻し BLE Wi-Fi
 3G/LTE デバイス アプリ Webサーバー 2 1 3
54. デバイスとWebサーバーの
 同期に失敗したら • 完全な整合性は(たぶん)無理 • 時間が経てば整合性がとれるようにする(結果整合性) BLEアプリ設計ノウハウ ＃3 結果整合性
55. 結果整合性を取るだけで
 いろんな選択肢がある • どのような選択肢があるかは時間の都合でカットしました - ʮBluetoothΘ͔ΜͶ͐Αͳ͊ʂϋϜଠ࿠ʂʯΛࢀর͍ͩ͘͞
 https://speakerdeck.com/tomohikosato/bluetooth-hamutaro- d7f061c5-d5fb-438c-b1d3-062d63b11614 BLEアプリ設計ノウハウ ＃3 結果整合性
56. 結果整合性を扱うにあたって
 APIのべき等性が重要 • べき等なAPIとは、何度呼んでも結果が変わらない
 APIのこと • BLEアプリ開発では、結果整合性をとるために同期処理や リトライ処理が発⽣しがち - 同じリクエストを何度呼んでも⼤丈夫にしておく - 基本的にべき等なAPIが良いが、
 結果整合性を扱うなら更に重要 BLEアプリ設計ノウハウ ＃3 結果整合性
57. べき等なAPIの例 1. 設定を更新する -  叩くたび設定が逆になる {autolock_toggle: true} -  何回叩いても同じ設定になる {autolock: true} 2. ログをアップロードする -  同じログをPOSTすると重複して作られる -  ログにIDを付けて識別し、同じログをPOSTしても
 重複して作られないようにする BLEアプリ設計ノウハウ ＃3 結果整合性
58. デバイス・Webサーバーの情報に関する
 ノウハウまとめ BLEアプリ設計ノウハウ #1〜#3まとめ 1. 情報はWebサーバーで持ち、デバイスはシンプルに 2. 同期の遅延を考慮する - 同期しないことを検討したり、
 常に同期できる別の通信経路を検討する 3. 同期に失敗したら結果整合性を考慮する - 結果整合性を扱うにあたってAPIのべき等性が⼤事
59. BLEアプリ設計ノウハウ デバイス・Webサーバーの
 情報に関するノウハウ #1 情報の持ち⽅ #2 同期の遅延を考慮 #3 結果整合性 アプリ設計に関する
 ノウハウ #4 通信先はドメイン層の関⼼事 #5 BLE通信は専⽤アプリを作る
 #6 UIは簡素に設計する
60. 前提:アプリの設計 BLEアプリ設計ノウハウ #4〜#6 前提設計 Qrio Lock はクリーンアーキテクチャみたいな設計 (正確な定義に則っているかは⾃信ありません)
61. 設計イメージ 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 前提設計
62. • 何のシステムかを表現 • ユースケース(DDD的にはアプリ ケーション層)もドメイン層と
 ⾔うことにしてます ドメイン層 BLEアプリ設計ノウハウ #4〜#6 前提設計
63. ドメインじゃない層 • 何のシステムか以外を分離 • 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 前提設計
64. BLEアプリ設計ノウハウ #4 通信先はドメイン層の関⼼事 
 デバイス・Webサーバーは持つ情報も
 通信プロトコルの性格も違うので
 ドメイン層で区別して扱う
65. ドメイン層のモデルクラスを考えてみる BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事
66. プロパティによって取得する通信先が違う デバイスのみ Webサーバーのみ デバイス・
 Webサーバー両⽅ BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事
67. Web・BLEは性格が異なるため、 違うタイミングでnullが⼊る デバイスのみ
 Bluetoothがオフ、
 デバイスから遠いとnull Webサーバーのみ
 オフラインだとnull デバイス・
 Webサーバー両⽅ BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事
68. Web・BLEは性格が異なるため、
 様々なタイミングでnullが⼊ってしまう nullが⼊るパターンが多くてコントロールできない BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事 デバイスのみ
 Bluetoothがオフ、
 デバイスから遠いとnull Webサーバーのみ
 オフラインだとnull デバイス・
 Webサーバー両⽅
69. 通信先によってモデルクラスを分ける Webサーバー向き デバイス向き BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事
70. BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事 通信先がドメインの関⼼事となっている 会話で頻繁にWebサーバー・デバイスが出てくる 「ロック設定画⾯はデバイスと通信するっけ？」
71. 通信先を抽象化したドメイン層のクラスも
 Webサーバー・デバイスで別にする BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事 Webサーバー向き デバイス向き
72. ドメインで通信先を意識したコードの例 BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事 ΦʔτϩοΫͷΦϯΦϑΛઃఆΛ͢Δ ϩοΫͷઃఆΛ͢ΔϢʔεέʔε
73. BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事 Webαʔόʔ(͔ϩʔΧϧΩϟογϡ)͔ΒϩοΫΛอଘऔಘ σόΠεͱͷ΍ΓͱΓ
74. BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事 Webαʔόʔ(͔ϩʔΧϧΩϟογϡ)͔ΒϩοΫΛऔಘ
75. BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事 σόΠεͷઃఆΛมߋ
76. BLEアプリ設計ノウハウ ＃4 通信先はドメイン層の関⼼事 Webαʔόʔ(ͱϩʔΧϧΩϟογϡ)ʹσόΠεͷઃఆΛ൓ө
77. BLEアプリ設計ノウハウ #5 BLE通信は専⽤アプリを作る 
 デバイスの動作確認をしたいケースが
 多いため、BLE通信部分は
 別モジュールにして専⽤アプリを作る
78. 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は専⽤アプリを作る
79. BLE通信部分は別モジュールにして 専⽤アプリを作る BLEアプリ設計ノウハウ ＃5 BLEは専⽤アプリを作る • デバイスの動作確認をしたいケースが多いため - デバイス開発チームの動作確認 - バグの原因の切り分け(デバイスか、それ以外か) - ⼯場でのデバイスの動作確認
80. #6 UIは簡素に設計
 簡素なUIが多いので、
 MVP/MVVMといったパターンが
 冗⻑になる画⾯が多いかもしれない BLEアプリ設計ノウハウ
81. • Qrio Lockの場合、機器の登録や設定画⾯が多い • IoT系アプリは機器の登録や設定など、
 簡素なUIが多くなりがち • (もちろんサービス次第です) BLEアプリ設計ノウハウ ＃6 UIは簡素に設計 IoTのUIは簡素
82. Qrio Lock でMVVMを採⽤した理由 • MVCはイマドキ(2017/10頃)じゃない的な判断、、 • プレゼンテーションロジックをテストできる BLEアプリ設計ノウハウ ＃6 UIは簡素に設計
83. • リターン - UIからプレゼンテーションロジックを分離 できる - プレゼンテーションロジックをテストでき る • コスト - MVVMの実装コスト - MVVMのベストプラクティスを探るコスト BLEアプリ設計ノウハウ ＃6 UIは簡素に設計 MVVMのリターンとコストを考える
84. BLEアプリ設計ノウハウ ＃6 UIは簡素に設計 MVVMのリターンとコストを考える ؆ૉͳUIͩͱ
 ϝϦοτ͕ബ͍ ؆ૉͳUIͰ΋
 ίετ͸͔͔Δ • リターン - UIからプレゼンテーションロジックを分離 できる - プレゼンテーションロジックをテストでき る • コスト - MVVMの実装コスト - MVVMのベストプラクティスを探るコスト
85. • MVVMのようなView周りの複雑さを解消する設計は
 あまり機能しなかった • MVVMをやるなら複雑な画⾯に対してのみ適⽤するのが良い(?) • BLEアプリではUIよりも複雑になりそうな箇所がある。そちらを重点的に設計 - #4で話したような、通信先をドメインで扱う設計とか - エラーハンドリングとか(通信先が増える分、エラーのパターンが増える) BLEアプリ設計ノウハウ ＃6 UIは簡素に設計 UIは簡素に設計
86. アプリ設計に関するノウハウ • ドメインで通信先(デバイス・Webサーバー)を意識する • BLE通信部分は別モジュールに切り出して専⽤アプリを作る • 簡素なUIが多いので、MVP/MVVMといったパターンが
 冗⻑になる画⾯が多いかもしれない BLEアプリ設計ノウハウ #4〜#6 まとめ
87. さいごに
88. 試⾏錯誤でやってます • あくまでQrioLockアプリ開発を通して学んだ
 個⼈の⾒解です • 代案などあればぜひ教えてください！ • カットした内容はまたどこかで話したい
89. BLEアプリ開発のおもしろさ • 類例が少ないので「そもそも」を考える機会が多い - デバイスとWebサーバーで情報を同期すべきか、とか - ドメインで通信を意識するべきかどうか、とか • アプリ開発以外の⽂脈に類例が⾒つかったりする - 結果整合性とか
90. Thank you