【Kotlin】Flow flatMap* を ネストするか チェインするか【coroutine】

kotlin coroutin flow のオペレータをネストするかチェインするかの話です。

👉 Kotlin flow: Nesting vs Chaining • Vasya Drobushkov 

Flow 間のデータ受け渡し


observeUser()
  .flatMap { user ->
    api.load(user.id)
      .flatMapLatest { data -> api.send(user.id, data) }
  }
  .collect()


observeUser()
  .flatMap { user ->
    api.load(user.id)
  }
  .flatMap { data -> api.send(user.id, data) } // ! user is not accessible
  .collect()

An important observation is that nesting unlike chaining creates scope. And one of the simplest things one can do with the scope is to share some data inside it.

重要なことは、チェインとは異なり、ネストによってスコープが作成されることです。そして、スコープで実行できる最も簡単なことの1つは、スコープ内のデータを共有することです。

キャンセルの伝達


observeUser()
  .flatMapLatest { user ->
    api.load(user.id)
      .flatMapLatest { observeLocation() }
  }
  .collect()


observeUser()
  .flatMapLatest { user ->
    api.load(user.id)
  }
  .flatMapLatest { observeLocation() }
  .collect()

Here we again used nesting, while we don’t need to pass any data to the observeLocation stream. Additionally, instead of flatMap we’ve used flatMapLatest (in RxJava it is called switchMap) - if the new value will be sent by upstream the downstream will be canceled and a new one created. This ensures that if the user was changed (e.g. account switched) we’ll trigger the server once again to determine whether we need to observe location.

observeLocation ストリームには何のデータも渡す必要はありません。RxJavaではswitchMapと呼ばれる flatMapLatest を使用しています。新しい値がアップストリームで送信されると、ダウンストリームはキャンセルされ、新しい値が作成されます。これにより、ユーザーが変更された場合(例えば、アカウントが変更された場合)、位置情報をobserveする必要があるかどうかを判断するために、もう一度サーバーを起動することができます。

because in the case with nesting we’ve defined the scope that has lifecycle attached to the observeUser stream: when the user is changed - everything inside flatMapLatest will be canceled. And in the case of chaining, we have observeLocation outside of user scope - so when the user changed, the location stream is not canceled.

ネスティングの場合は、observUserストリームにライフサイクルが付随するスコープを定義しているため、ユーザーが変更されると、flatMapLatest内のすべてがキャンセルされます。また、チェイニングの場合は、ユーザースコープの外側にobserveLocationを設定していますので、ユーザーが変更されてもlocationストリームはキャンセルされません。

まとめ

flatMapLatest を使う場合は、入れ子のほうが意図に沿いやすいように思えるが、コード自体の見通しは悪い。

頭のどこかに「ネストかチェインか」は置いておくべきでしょう。

👉 【MVVM】 Kotlin Flow で使える5つの利用パターン | #android ファショ通 


PreferenceFragmentCompat に ViewModel を注入する

今現在「DaggerPreferenceFragmentCompat」はありません。

MVVMなストラクチャで、

ViewModel の Fragment プロパティ への注入。

どうしてますか?

HasAndroidInjector を使う

👉 Dagger2: 2.23に入ったHasAndroidInjectorについて - stsnブログ 


class SettingsFragment : PreferenceFragmentCompat(), HasAndroidInjector {

  @Inject
  lateinit var androidInjector: DispatchingAndroidInjector<Any>

  override fun androidInjector(): AndroidInjector<Any> = androidInjector

  override fun onAttach(context: Context) {
    AndroidSupportInjection.inject(this)
    super.onAttach(context)
  }

👉 android - Using Dagger2 with PreferenceFragmentCompat - Stack Overflow 

Dagger は Square が管理してたほうが良かったんじゃねか、と思う。

今から経緯を分からず入門は厳しいはず。


@Binds - Dagger2

インターフェースを実装したクラスがあり、それをインターフェース経由でバインドしたいとき、通常以下のようにしてました。


@Module
object BookPresenterModule {
  @Provides @JvmStatic
  fun provideBookPresenter(bookPresenter: BookPresenterImpl): BookPresenter = bookPresenter
}

これは @Inject 付きコンストラクタと一緒に使われるモジュールの一部です。これは、以下のように記述するべきです。


@Module
abstract class BookPresenterModule {
  @Binds abstract fun bindBookPresenter(bookPresenter: BookPresenterImpl): BookPresenter
}

これまでどおり「インターフェースにその実装をバインドしたいとき」に使うことができます。

コード生成がされず、どこからもコールされないのに、きちんと連携情報として利用されるのが良いところです。

Dagger 2.4 で登場したにもかかわらず、なぜか公式ユーザーガイドでは説明されていません。

👉 Release Dagger 2.4 · google/dagger 

以下、公演動画などから学ぶことができます。




ApplicationComponent 実装の変遷 - Dagger2

2022-03-16 追記: 新しいDagger記事は以下リンクから

👉 MVVM で Hilt のパターン化 💉  

--------

へん‐せん【変遷】
[名](スル)時の流れとともに移り変わること。「歌もまた時代につれて変遷する」

Dagger て分かりづらいです。

タイトルがすでに謎ですが、以下のような実装のことを指しています。

アプリケーションコンテキストをオブジェクトグラフに追加する

ApplicationComponent とアプリケーションコンテキストの設定

アプリケーションコンテキスト を依存先として公開する

これまで数年に渡って変化し続けてるそんな必須の実装項目です。

ネット上をただ検索するだけでは、古い記事に最新の実装記述が埋没しています。

Dagger 2.9 以前( - 2017/02/04)


@Component(modules = [ApplicationModule::class, ...])
interface ApplicationComponent {
  ...
}


@Module
class ApplicationModule(private val applicationContext: Context) {
  @Provides fun provideApplicationContext() = applicationContext
}

これは Kotlin 記述で簡略化できます。


@Module
class ApplicationModule(@get:Provides val applicationContext: Context)


DaggerApplicationComponent
  .builder()
  .applicationModule(ApplicationModule(applicationContext))
  .build()

2.9 (2017/02/04 - ) @BindsInstance

👉 Release Dagger 2.9 · google/dagger 

We create a module that receives the application context as a constructor argument, and we create a provide method that exposes it. This works great, but then we can't have static @Provides methods anymore. And besides that, this strategy is actually going against the docs that are pretty explicit when it comes to this:

@BindsInstance methods should be preferred to writing a @Module with constructor arguments and immediately providing those values.

👉 User's Guide 


@Component(modules = ...)
interface ApplicationComponent {
  @Component.Builder
  interface Builder {
    @BindsInstance 
    fun applicationContext(applicationContext: Context): Builder
    fun build(): ApplicationComponent
  }
  ...
}


DaggerApplicationComponent
  .builder()
  .applicationContext(applicationContext)
  .build()

2.22 (2019/04/03 - ) @Component.Factory

👉 Release Dagger 2.22 · google/dagger 


@Component(modules = ...)
interface ApplicationComponent {
  @Component.Factory
  interface Factory {
    fun create(@BindsInstance applicationContext: Context): ApplicationComponent
  }
  ...
}


DaggerApplicationComponent
  .factory()
  .create(applicationContext)

まとめ

最近のコード記述を理解するには、少しだけ

「成り立ちを遡ってみる」

と理解しやすいことが多いように思います。

👉 Releases · google/dagger 
👉 Dagger 2 on Android: the shiny new @Component.Factory 

2022-03-16 追記: 新しいDagger記事は以下リンクから

👉 MVVM で Hilt のパターン化 💉