Introduce Bletia

[izumin5210]

79

WHY

設定系APIが不安定

Android由来かkonashi由来かは不明であるが，複数のタスクを間髪を入れずに実行しようとすると最初のタスク以外はすべて無視される． この影響で，現行SDK（α〜v0.5.0）のコールバックベースのAPIとkonashiの設定変更系の処理（pinMode，pwmPeriod，etc.）が非常に相性が悪い（=> #8 #76 など）．

実装すべきコールバックメソッドが多い

konashiにある大量のAPIのほとんどにコールバックメソッドが用意されているため，それを実装するためのインタフェースも肥大化してしまっている（0.5.1時点で7つのインタフェースに分割されている）．

クラス肥大化によりメンテナンスが困難

大量のAPIからのコールバックを捌くために超肥満体型Managerクラスが誕生しており，メンテナンスやテストを困難なものにしている（#36）．

エラーがわかりにくい

あらゆるエラーのコールバックは全て同じメソッドに返るため，どの処理由来のエラーなのかがわからない（#69）．

WHAT

Bletiaを導入することで， https://github.com/YUKAI/konashi-android-sdk/issues/76#issuecomment-132843538 で提案があったPromiseベースのAPIに変更する．

// こんな感じに書けるようになる
konashiManager.pinMode(Konashi.PIO1, Konashi.OUTPUT)
        .then(new DoneCallback<BluetoothGattCharacteristic>() {
                  @Override
                  public void onDone(BluetoothGattCharacteristic result) {
                  }
        })
        .fail(new FailCallback<BletiaException>() {
                  @Override
                  public void onFail(BletiaException result) {
                  }
        });

メリットとしては以下のようなものが挙げられる:

• 設定変更系APIのthen内で次の処理を呼ぶようにすればThread.sleep()いれなくても良くなる
• エラーは全てfailに返るのでハンドリングが楽
• BletiaにはActionという概念がある
  • Actionを継承させたクラスをBletia#excecute()に渡してあげればあとはよしなにやってくれる
  • 対応してるのは以下の処理
  • readCharacteristic
  • writeCharacteristic
  • readDescriptor
  • writeDescriptor
  • enableNotification
  • readRemoteRssi
  • パラメータの検証・変換等はActionの実装に移譲できる
  • 責務が分担されてtestabilityが向上する
  • KonashiManagerが痩せる
• HandlerThreadによるキューイングや接続・切断などありがちな処理はすべてBletia内に実装されている
  • Message系クラスやKonashiHandlerThread，EventやCharacteristicのハンドリング用Enumなどのクラスは削除できる
• 大量のListenerクラスのほとんどが削除可能
  • 接続とNotificationのコールバックだけは残る

    TODO

• Promisifying
  • [x] PIO
  • [x] PWM
  • [x] AIO
  • [x] UART
  • [x] I2C
  • [x] Battery / RSSI
• Refactoring
  • [x] Listener classes
  • [x] Konashi{,Base}Manager
  • [x] Remove unnecessary codes
  • (Message classes, KonashiMessageHandler, Event classes , KonashiCharacteristic, KonashiNotifier, etc.)
  • [ ] Utility classes

[izumin5210]

05f049d まででPIOまわり（Read除く）の置き換え完了．

手順はだいたい以下のとおり:

• Storeクラス作る
• Dispatcherクラス作る
• Updaterをつくる-> UpdaterからDispatcherを生成
• Filterつくる（必要に応じて）
• Actionのテスト書く
• Action実装する
• KonashiManager内の実装をPromise化

Storeを単純なgetter/setterだけの薄い実装にして，Dispatcherで変更を通知してあげる．DispatcherにはDoneCallbackを実装することでthenに放り込むだけであとはいい感じになんとかなる． Actionに関してはKonashiWriteCharacteristicActionという抽象クラスを作ってあるので，それを継承してあげる．hasValidParams()で値のバリデーション，setValue()で値を変換してCharacteristicに渡してあげるところまでやる（INVALID_PARAMETERなげるのとかはActionをexecuteするときにhasValidParams()の結果見て勝手にやってくれる）．

---

このペースで全部の処理をPromise化してたら100commits超えてもおかしくないので，ここから適当にブランチ切っていったほうがいいかもしれない．

[izumin5210]

よくよく考えると，ユーザからしたら`BluetoothGattCharacteristicとか返されても困る DoneFilter噛ませてIntegerに変換とかしたほうが良さそう

[izumin5210]

テストぶっ壊れてるからなおす

[izumin5210]

Utilityまわりのリファクタしたかったけど，テスト書くのがあまりにも面倒だから保留． Androidに依存しない部分なので，Groovy・Spockを導入してみてもいいかもしれない．