fresh digitable

めんどくさかったなってことを振り返ったり振り返らなかったりするための記録

fluxとかMVIみたいな構造のアプリを作ってみたかった

fluxとかMVIみたいなリアクティブ?な構造のアプリを作ってみたかったのでやってみた。Cycle.jsのドキュメントを参考にして自分なりにかみくだきながら作っていったので気持ちとしてはMVIのような感じだけど、実際に自分で作ったものが何なのかはわからない。少なくとも、すでに世にあるAndroidアプリのMVI実装とはぜんぜん違うようにみえる。

github.com

ざっくりとしたクラス図

実際に悩みながら分からないなりに書き進めて、ある程度形になったかなと思えるので、以下にポイントや雑感を書いていく。おおよその方針は決まったので、今後はもう少し考えて分割統治を進めたりうまくいっていないところを解消したりしていきたい。

  • コールバックを呼ぶ代わりにUIイベントのオブジェクトをイベントバス(=EventDispatcher)に流して目的別に振り分け(=Actions)、ビジネスモデルの関数を引き当てる(=ViewStates)というざっくりとした理解
    • 関心の分離の仕方は何となく好き
    • 一つのイベントを受け取って一つの状態(個々のViewの状態の集合)に遷移させるという感じのものを目指したが、Databindingと一緒に使ってると結局最後にまたばらばらにするから一つの状態にまとめる処理いらなくない?と思ってやめた
    • 画面遷移はイベントなので保存しない(RxJavaのObservable)、状態はデータなので保存する(LiveData)という考え方で組み立てている
      • 中断関数を呼び出すのが面倒(中断関数にせずRxでスレッドを切り替えるのがスマートなんだろうけど@MainThreadとかの世界には何となく戻りたくない)
    • ActionsもViewStatesもモジュールごとに分割できそう。現時点ではアプリルートのモジュールに全部書いている
  • androidx.navigationを使った画面遷移をどうすればきれいに収められるか分からなかったので残念ながらフローが分岐している
    • 画面遷移はNavHostFragmentの状態を遷移させることなので当初は自前で状態を管理しようとしていたが、NavControllerはバックスタックなども管理しているのでゆくゆくはそれも管理しなければならなくなって結局はNavControllerのようなものを作ることになるのでは…?と考えて全部androidx.navigationに寄せることにした
    • 最初はViewStatesに入れれば一方向のフローになるかなと思ってやってみたんだけどkaptがメッセージ無しの謎のエラーを吐いてこれを解決できなかったので断念した
  • テストについて:Repositoryはモックにしているが、それ以外は極力現物を使うようにしたらテストを準備するための処理が重複しまくってしまい面倒なことになってしまった。きれいにまとめる何かが必要

追記:akihito104.hatenablog.com