2020-10-24

androidx.lifecycle.toLiveData()では内部的にpostValue()が使われているという話

Android TIL

androidのライブラリ lifecycle-reactivestreams-ktx にはRxJavaの Publisher<T> を LiveData<T> に変換する拡張関数 androidx.lifecycle.toLiveData() がある。この関数が返してくるLiveDataの実装クラス LiveDataReactiveStreams.PublisherLiveData は、RxのonNext()でオブジェクトを受け取るたび、LiveData.postValue() に値を渡している*1。つまり、次のようなコード：

Flowable.just("a", "b", "c").toLiveData().observe(activity) {
  Timber.tag(TAG).d(it)
}

では、"c"だけがログに出力されることになる。"a"も"b"も出力したいという場合には、toLiveData()を呼ぶ前の段階でフレームごとに一つだけ取得するようなスケジューラを挟む必要がある。あるいは、RxもLiveDataもやめて、Kotlin coroutinesのflowを使うという手もある。

しかしながら、実際のアプリで"a", "b", "c"のすべてが必要という場合にはLiveDataは使用すべきではなく、RxのクラスかFlow/Channelを使い、subscribeやcollectの中でイベントとして消費するようにしたほうがよい。

*1:ver. 2.2.0時点での挙動

2020-09-30

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

Android Kotlin

つづきです akihito104.hatenablog.com

今：Eventを流してModelを更新し、その結果ViewStateが更新される
課題：Modelを更新したときに出てくる例外をどうするか

例えばこんな感じのハッピーパスしか考えてないやつ（スレッドとか中断関数とかそういうことは端折っています）：

val state: LiveData<State> = updateEventFlowable
    .map { event -> model.update(event.text) }
    .toLiveData()

model.update()で例外が起きるとLiveDataでは例外を処理できない的なメッセージが出てクラッシュする。こういうケースでどうするか考えていく。

想定される例外（IOExceptionとかAPI limit exceeded的なやつ）が起きたときはリカバリしたい
- リカバリは今のところやり直すとかいうよりは「だめだったからあとでやり直してね」ってToastとかSnackbarとかでユーザーに伝えるぐらいしかない
想定外の例外が起きてリカバリできない（どうするのが正しいのか分からない）時はちゃんと大域脱出（クラッシュ）したい
- テストの文脈（mockkとか）で出てくるような例外を握りつぶさないように
- でも例えばFragmentスコープでは解決できなくてもActivityスコープとかApplicationスコープでなら解決できるならそのスコープでキャッチしてリカバリしてもいいと思う

Event -> (Model) -> ViewState という流れとは別に、 Event -> (Model) -> 例えばMessage のような終端も必要ということかなと考えて、

Eventを流してModelを更新し、その結果をResultという形で得る
ResultからViewStateを得る、もしくはResultから例外を得てリカバリする

のような感じで、間にもう1クッション挟んで分岐できるようにしたらいいのだろうか。だんだん巨大になっていくのでもっといい抽象化の仕方があるのではないかという気がする。結論は出ていないけどとりあえずその方向で実装して動きを見てみようと思う。

あとは、RepositoryからLiveDataを返すような関数を生やしていたけど、上のようなことを考慮するにあたってLiveDataを返すようなのはこのケースには合わないのかなと思い始めている。この辺はまだもやもやしていてうまく説明できない。でもRepositoryのコードがViewStatesにどんどん移動していくことになりそう。

追記: akihito104.hatenablog.com

2020-09-04

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

Android Kotlin

以前書いたこの記事

akihito104.hatenablog.com

の中で、

最初はViewStatesに入れれば一方向のフローになるかなと思ってやってみたんだけどkaptがメッセージ無しの謎のエラーを吐いてこれを解決できなかったので断念した

というようなことを書いた。今回はこれを解決したのでその顛末を書く。

ここで困っていることをもう少しだけ詳しく説明すると、NavControllerを持っているNavigationDelegateクラスをViewStatesに注入したくてそのようにコードを書いたら、daggerがコード生成をやっている最中に謎のエラーを吐いてうまくいかなかった、という感じ。エラーメッセージはタスクの実行時にstacktraceオプションを付けなければ見ることができなかったし、スタックトレースをさかのぼった先にあるエラーメッセージに

java.lang.IllegalArgumentException: no expression found for BindingRequest...

と書いてあってもどこがどう悪いのかさっぱり分からんので詰んだと思っていた。しかしながら詰んだといっても投げ出すのも癪なので、依存関係のグラフを描いてくれてそのうえダメなところを図示してくれるツールとか無いんだろうかと探してみたところ、scabbardというツールを見つけた。

arunkumar9t2.github.io

ダメなところを教えてくれるというのは無理なようだが*1、グラフをインタラクティブなSVGで出力してくれるというもの*2で、依存関係の全体像をつかむのにすごく役立った。

私のケースでは、ビルドは失敗しているものの図の出力はなぜかできていたので、コードを少しいじってはビルドして図を眺めるというのをしばらく繰り返した。そんなことをやっているうちに、あるコンテキストでは注入しているオブジェクトが、また別のコンテキストでは注入できていないということに気が付いて雑にprovide関数を実装したところビルドが通るようになった。図で描くとこんな感じ。