ContentProvider を Flow 化する方法 - CashApp Cooper

cashapp/cooper


fun ContentResolver.observeQuery(
  uri: Uri,
  projection: Array<String>? = null,
  selection: String? = null,
  selectionArgs: Array<String>? = null,
  sortOrder: String? = null,
  notifyForDescendants: Boolean = false
): Flow<Query> {
  val query = ContentResolverQuery(this, uri, projection, selection, selectionArgs, sortOrder)
  return flow {
    emit(query)


    val channel = Channel<Unit>(CONFLATED)
    val observer = object : ContentObserver(mainThread) {
      override fun onChange(selfChange: Boolean) {
        channel.offer(Unit)
      }
    }


    registerContentObserver(uri, notifyForDescendants, observer)
    try {
      for (item in channel) {
        emit(query)
      }
    } finally {
      unregisterContentObserver(observer)
    }
  }
}

👉 FlowContentResolver.kt#L43-L90
👉 copper/FlowContentResolver.kt at trunk · cashapp/copper

Kotlin coroutines Flow や RxJava Observable を使ったリアクティブクエリ用の ContentProvider のラッパーです。

使用方法


implementation 'app.cash.copper:copper-flow:1.0.0'

ContentResolver で query() を observeQuery() に変更することで、リアクティブ版を実現します。


contentResolver.observeQuery(uri).collect { query ->
  query.run()?.use { cursor ->
    // ...
  }
}

query() とは異なり、observeQuery() は Query オブジェクトを返します。このオブジェクトは、カーソルの基礎となるクエリを実行するために run() を呼び出す必要があります。これにより、値をキャッシュする中間オペレータがリソースをリークすることなく、コンシューマーがカーソルのライフタイム全体にアクセスできるようになります。

cursor を直接処理する代わりに、含まれる値をセマンティックタイプに変換するためのオペレータを提供しています。


contentResolver.observeQuery(uri)
  .mapToOne { cursor ->
    Employee(cursor.getString(0), cursor.getString(1))
  }
  .collect {
    println(it)
  }


Employee(id=bob, name=Bob Bobberson)

mapToOne オペレータは、1 つの行を返すクエリを受け取り、ラムダを起動してカーソルを希望の型にマッピングします。クエリがゼロまたは1行を返す場合は、コルーチン成果物には mapToOneOrNull オペレータがあり、RxJava成果物には mapToOptional 演算子があります。

クエリがリストを返す場合は、同じラムダでmapToListを呼び出します。


contentResolver.observeQuery(uri)
  .mapToList { cursor ->
    Employee(cursor.getString(0), cursor.getString(1))
  }
  .collect {
    println(it)
  }


[Employee(id=alice, name=Alice Alison), Employee(id=bob, name=Bob Bobberson)]

安定の神Jake産です。

👉 【SQLDelight 】Query を Flow 化するプラグイン 


【Kotlin】StateFlow は distinctUtilChanged 不要

distinctUntilChanged

StateFlow のインスタンスは、distinctUtilChanged 演算子がに適用されているように動作するので、distinctUntilChanged を StateFlow に適用しても効果はないことに注意してください。

👉 distinctUntilChanged 

オペレータの組み合わせ
flowOn、conflate、buffer CONFLATED/RENDEZVOUS、capacity、distinctUntilChanged、cancelable のいずれかの演算子を StateFlow に適用しても効果はありません。

👉 StateFlow 

SharedFlow で StateFlow を作ることができます。StateFlow は ある設定をした SharedFlow です。



👉 StateFlow の View への公開 
👉 【MVVM】Flow vs LiveData 
👉 【Kotlin】SharedFlow と BroadcastChannel 


StateFlow の View への公開

以下のような ViewModel があったとして、バッキングプロパティ部分。

どう書いてますか。


class CounterModel {
  private val _counter = MutableStateFlow(0)

  ??? counter ??? = _counter ???

  fun inc() {
    _counter.update { count -> count + 1 } 
  }
}

以下の登場時の開発の様子を参考に。

Introduce StateFlow
👉 Introduce StateFlow · Issue #1973 · Kotlin/kotlinx.coroutines 

StateFlow は、状態を表す更新可能な値の Flow です。

- StateFlow インターフェイスは、現在の値にアクセスするための読み取り専用で、値の更新を collect するための Flow を実装しています。

- MutabaleStateFlow インターフェースは、値を変更する操作を追加しています。

- MutableStateFlow(x) のコンストラクタ関数が用意されています。この関数は、与えられた初期値を持つ MutableStateFlow の実装を返します。値への高速で非リアクティブなアクセスが必要な場合は StateFlow として、値への更新のリアクティブな表示のみが必要な場合は Flow として、外部に公開することができます。

次のようにまとめることができます。


package kotlinx.coroutines.flow

interface StateFlow<T> : Flow<T> {
  val value: T // always availabe, reading it never fails
}

interface MutableStateFlow<T> : StateFlow<T> {
  override var value: T // can read & write value
}

fun <T> MutableStateFlow(value: T): MutableStateFlow<T> // constructor fun

よって、以下、ありがちな記述。(ないか。)


var counter = _counter // NG


val counter = _counter // NG


val counter: MutableStateFlow<Int> = _counter // NG


val counter: StateFlow<Int> = _counter // NG


val counter get() = _counter // NG


val counter: MutableStateFlow<Int> get() = _counter // NG

開発者の間でも、好き嫌いはあるようですが、以下の2パターンが良さげ。Read Only であることが大事。


val counter: StateFlow<Int> get() = _counter  // OK


val counter = _counter.asStateFlow()  // OK

よって、


class CounterModel {
  private val _counter = MutableStateFlow(0)

  val counter = _counter.asStateFlow()

  fun inc() {
    _counter.update { count -> count + 1 } 
  }
}

最近の言語の仕様は、オフィシャルドキュメントでは分かりずらいポリシーが多くあるように思います。

👉 【MVVM】 ViewModel の_プロパティ記述 hatena-bookmark

👉 【MVVM】 Kotlin Flow で使える5つの利用パターン 
👉 StateFlow は distinctUtilChanged 不要  


今はまだ必要な Android ライブラリ の Bill of Materials(BOM) のURLs

以下は、Androidアプリ開発には、必ず使いますよね。

いや使うと良い、か。

 

Kotlin Libraries Bill of Materials

👉 Maven Repository: org.jetbrains.kotlin » kotlin-bom 

 

Kotlinx Coroutines BOM

👉 Maven Repository: org.jetbrains.kotlinx » kotlinx-coroutines-bom 

 

firebase-bom

👉 Google's Maven Repository - BOM 

 

OkHttp BOM

👉 Maven Repository: com.squareup.okhttp3 » okhttp-bom 

latest の更新に注意するためのな。

👉 bom - Google's Maven Repository 
👉 org.jetbrains - Maven Central Repository Search 


Android OS バージョンのシェア 2020-12

minSdkVersion をいくつにするか。

直近から80%までをカバーすることにして公式で確認してみましょう。

👉 配信ダッシュボード  |  Android デベロッパー  |  Android Developers 

今ではもう公式からのデータ公開などありません。

プラットフォームのバージョン
プラットフォームのバージョン情報については、Android Studio の [Create New Project] ウィザードでご確認ください。

 

Android Studio

確認してみます、2020-12-01現在。

Android 6.0 (API 23) 以降をカバーすれば、84.9%となり、8割をカバーすることができることになりますね。

これだけでは、あやしいのでネット上を定番サイトを巡回していきます。

 

AppBrain

AppBrain で確認してみます。


👉 Android OS version market share over time | AppBrain 

計算しやすいように順番に並び替えます。

OS Share (%) Sum (%)
6 7.6 90.6
7.0-7.1 9.8 83.0
8.0-8.1 17.8 73.2
9 24.1 55.4
10 31.1 31.3
11 0.2 0.2

Android7.0 (API24) 以降で、83%をカバーします。

 

StatCounter Global Stats

👉 Mobile & Tablet Android Version Market Share Worldwide | StatCounter Global Stats 

日本では Android8.0 (API26) 以降で 80.42%、世界では Android7.1 (API25) 以降で 81.86%をカバーします。

 

Google Play コンソール

先述の、公式ページに書いていたもう一つの関連メッセージ。


👉 配信ダッシュボード  |  Android デベロッパー  |  Android Developers 

信頼性の高いデータを使ってアプリのターゲティングを管理し、ユーザーのデバイスの特性を把握できるようにするには、Play Console で入手できるアプリの統計情報を活用することをおすすめします。

アプリ開発者向けのサイトになりますが、利用者数が多いアプリを公開していれば、最もリアルな生データになります。

しかし、そのアプリの特性も織り込まれます。

わたしらの公開しているアプリで見てみましょう。

OS Share (%) Sum (%)
7.1 2.02 88.12
8.0 10.35 86.10
8.1 2.09 75.75
9 25.31 73.66
10 46.99 48.35
11 1.36 1.36

Android8.0 (API26) 以降で 86.10% をカバーします。 アプリのユーザーは7割が日本国内を占めます。

 

まとめ

Android端末の国内発売当初から、バージョンシェアを眺めてきていますが、公式のAndroidDeveloperサイトのプラットフォームダッシュボードや、AndroidStudio内のウィザードの情報はこれまでも、かなり古い古すぎでした。

よって、今現在8割超えの minSdkVersion は「26」と決めつけちゃえ。

ちなみに以下も死んでます。

👉 minSdkVersion(@minSdkVersion)さんの返信があるツイート / Twitter 

ちなみに8年前。なつい。


👉 #androidファッション通信 | Facebook