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

R8でコードシュリンクしつつInstrumentation Testをやる

いろいろハマってしんどかったので雑にまとめておく。

github.com

ことの顛末

  • Instrumentation Testのテストが全然動かない。テストがないとか言われる
  • LogcatをみるとDaggerTestAppComponentDaggerAppComponentにキャストできませんとか言われている。そらそうよ
  • ちょっと書き換えると今度はkotlin.reflect.KProperty0がないとか言ってくる。なんでや
  • キャストするコードは書いていない。明にキャストしたり、安全キャスト(as?)をやったりしてみるがなぜかDaggerAppComponentにキャストされようとしてクラッシュする。Kotlinバイトコードデコンパイルしてみても特に変なところはない。dexにする段階で何か変わってしまったのか?と思ってapkファイルの中のバイトコードを確認すると、check-castという命令が追加されており、ここでDaggerAppComponent型かどうかのチェックがされていた。
  • R8の最適化が効いたのかな?と思って最適化させない命令(-dontoptimize)を付けると今度はkotlin.reflect.KProperty0が無いといわれる。またか。だがdexのバイトコードにはcheck-castがなくなっていた。
  • そうかそれならってことで今度は-keepkotlin.reflect以下のクラスを残すことにした。すると今度は別のクラスが無いという話になったので、一応効いているということが分かった。ないといわれたクラスを片っ端からkeepで残すことにしていったらテストが動くようになった。

敗因

  • R8の最適化が効いてたのが分からなかった
  • テスト用のアプリにクラスが足りないのかと思って(MockKを足したりしたので)いろいろ足してみたけど効果が無くて、本当はテスト対象側にそのクラスが無いといけなかった様子
  • 最初はDaggerの方を疑っていたが結果的に関係なかった
  • testSharedディレクトリを追加したあたりが悪かったのかと思って指定を付けたり外したりしてみていたけど結果的に関係なかった(ちょっとずつ変更しながら動きを見ていればよかった)
  • コードシュリンクしないとビルドできない(かといってMultidexにするほどでもない)

SavedStateHandleを使ってLiveDataの値を保存する

ViewModelが持っているLiveDataの値をインスタンスステートとして保持したいとき、androidxのlifecycle-viewmodel-savedstateライブラリを使う。fragment 1.2.0activity 1.1.0を入れているとその依存関係としてsavedstateも入ってくる*1。この記事ではlifecycle-viewmodel-savedstate 2.2.0での挙動を前提とする。

本当はDIを使ってViewModelSavedStateHandleを注入するところまでが大変なのだが、いろんなブログや本に書いてあるので割愛する。タイトルの通りLiveDataの値を保存したいときはまず、ViewModelに注入されたSavedStateHandleからgetLiveData()を使ってMutableLiveDataを取り出す。

val data: MutableLiveData<Hoge> = savedStateHandle.getLiveData("key_data")

こうすると、SavedStateHandle内部に定義してあるSavingStateLiveDataというクラスのインスタンスが内部キャッシュから返されるか、そこになければ生成される。このSavingStateLiveDatasetValue()の都度、SavedStateHandle.set()相当の処理をやってくれる。つまり、上で書いたdataに対しては

data.value = someHogeValue  // postValue()も大丈夫なはず

をやるだけでよい。これでいつonSaveInstanceState()が呼ばれても大丈夫。いうまでもないが、LiveData以外のプロパティに対しては別途対応が必要になる。