BLEアプリのデバッグって超めんどくない?死ぬほどマニアックなTIPSを叫ばせてくれ。
表題の通りBLEアプリのデバッグが大変すぎて死にたいですが、死ぬ前に一つだけ言わせて下さい。どう考えても同意してくれる人が日本に数人もいないと思いますが、この大発見を伝えたいです。
ここ最近キッチンカーを作りながらも、本業のiOSアプリ開発もちゃんとやってるんです。
去年から関わってる案件で、とある医療用の機器とiPadをBLEで連携するというアプリがあります。機器で測定したデータをiPadにBLEで送って、iPad上で閲覧したり編集したりします。
BLE連携iOSアプリは何回か作ったことがあるのですが、毎回テストが大変なんです。機器とiPadが謎の接続エラーに見舞われたり、周りにBlueTooth電波飛ばす機器が多いと動作がおかしくなったり。再現性ないエラーが死ぬほど発生するのでいつも大変な目に遭います。
今回特にデバッグが大変だったのは、機器とiPadが接続したらほとんどポーリング処理が走るってとこでした。今回のポーリング処理とはiPadから1秒に1回機器の状態を確認するため、コマンドを送り、機器からの返答を解析することです。ポーリングの合間に必要なやりとりを機器とiPadの間でコマンドを使って行います。
iOSはBLEからの受け取り処理はdidUpdateValueForメソッドで行います。どのコマンドを叩いてもdidUpdateValueForメソッドに機器からのデータが返ってくるので、そのメソッド内でどのコマンドに対する値かを解析して振り分けていきます。
そのためポーリングのコマンドもその他のコマンドも全部ここのメソッドで処理します。
printデバッグしようとすると、
一瞬でウィンドウ内がprintメッセージで埋め尽くされる
埋め尽くしてもなお書き続けるので必要なprintメッセージを探すだけで一苦労です。
ブレークポイントを使ってデバッグしようとすると、
プログラムを止めたせいか、いつもと違う動作する
ポーリングや多くのコマンドのやりとりをしているので、ブレークポイント使うと再現性ない変な動きしたりするんですよね。
プログラムを動作させたまま、どの部分が実行されたかを知りたい
printもブレークポイントもイマイチな今どうするべきか。。。
その解決方法こそ、今日叫びたいTIPS!!
その方法とは
音を使う!!!!!!!!!
ここまで引っ張って大したTIPSじゃなくてすみません。
簡単にいうとif文などの条件文の中にprintをしかけて、どこまで実行させるか調べると思います。上述のようなprintが使えない場合は
音でやるのがいい!!!!!
と気づいてしまいました。
swiftの場合は
AudioServicesPlaySystemSound(1000)
とかをコードに書くとiPadやiPhoneで簡単に音が鳴らせます。
1000の部分を変えるといろんな音が鳴らせます。
数字によってどんな音がなるかは色々なサイトで一覧にされています。
if文ごとに音を変えてどの部分まで進んだかも判断できたりします。たまにどの音が何番かわからなくてなって、音が鳴るだけ鳴って収拾不能になって楽しいです。
BLEのデバッグがうまくいなかない時はぜひ
音を使う
ことも検討してみて下さい。
というTIPSに納品前日に気づきました。
3ヶ月前に気づきたかったです。。。