画像読み込みライブラリ「COIL」

Glide や Picasso のような画像読み込みライブラリです。

COroutine
Image
Loader

の略だそうです。

以下の特徴を持っており、ナウい感じです。

- 拡張関数、ラムダなどKotlinの持つ機能を活用。
- コルーチンを利用。
- ディスクキャッシュとストリームバッファリング機能。
- androidx.lifecycle に対応。
- 軽量。
- R8対応。ルール不要。

👉 Introducing Coil: Kotlin-first image loading on Android 

記述例です。


// To load an image into an ImageView, use the load extension function.
imageView.load("https://www.example.com/image.jpg")

// Coil supports urls, uris, resources, drawables, bitmaps, files, and more.
imageView.load(R.drawable.image)

imageView.load(File("/path/to/image.jpg"))

imageView.load(Uri.parse("content://com.android.externalstorage/image.jpg"))

// Requests can be configured with an optional trailing lambda.
imageView.load("https://www.example.com/image.jpg") {
    crossfade(true)
    placeholder(R.drawable.image)
    transformations(CircleCropTransformation())
}

// Custom targets can be created using lambda syntax (onStart and onError are optional).
Coil.load(context, "https://www.example.com/image.jpg") {
    target { drawable ->
        // Handle the successful result.
    }
}

// To get an image imperatively, use the get suspend function.
val drawable = Coil.get("https://www.example.com/image.jpg")

👉 GitHub - coil-kt/coil: Image loading for Android backed by Kotlin Coroutines. 

パフォーマンスを Glide や Picasso と比較した記事がありますが、まあまあのようです。

Coil is a new library, so its performance may increase in the next versions. We are comparing it with mature libraries, so let’s see how it evolves.

Coil は新しいライブラリであるため、次のバージョンでパフォーマンスが向上する可能性があります。成熟したライブラリと比較しているので、どのように進化するか見ておきましょう。

👉 Coil vs Picasso vs Glide: Get Ready… Go! - ProAndroidDev 

ちなみに、必要環境は以下。

- AndroidX
- Min SDK 14+
- Compile SDK: 28+
- Java 8+

今後に期待できますかね。


【Dagger】@Provides vs @Binds

久々に Dagger を使うとかなりの不自由感。

細かく咀嚼しないと全体は理解できない感じなので、まずはこのタイトルから。

少し、細かくシリーズ化してみますが。

👉 Dagger 2 @Binds vs @Provides - Elye - Medium 

👉 Why is @Binds different from @Provides? - Frequently Asked Questions 

Android が登場してから10年程度ですが、経緯というか、伝統というか、歴史というか。

そういうの嫌いだけど、そういうのを理解しようとしないと、その対象に対しての初心者は辛い時期になってるのだろうと思う。

Toolbar / ActionBar もそうでしょう?

シンプルにググるだけでは良いコードには辿り着けません、

この、Dagger2 2019-08-15現在 もそれと同じ雰囲気なのでしょう。

以下、上記リンクより引用。

@Binds methods must have only one parameter whose type is assignable to the return type

So only a single parameter, and the type return is typically the interface of the given parameter object.

Having said that, the other tips is consider using static function for @Provides which would help also reduce some generated codes.

@Bindsメソッドには、戻り値の型に割り当て可能な型のパラメーターが1つだけ必要です

そのため、1つのパラメーターのみが返され、型の戻り値は通常、指定されたパラメーターオブジェクトのインターフェイスです。

そうは言っても、他のヒントは、生成されるコードを減らすのに役立つ「@Provides」の「静的」関数の使用を検討することです。

@Provides, the most common construct for configuring a binding, serves three functions:
1. Declare which type (possibly qualified) is being provided — this is the return type
2. Declare dependencies — these are the method parameters
3. Provide an implementation for exactly how the instance is provided — this is the method body

While the first two functions are unique and critical to every @Provides method, the third can often be tedious and repetitive. So, whenever there is a @Provides whose implementation is simple and common enough to be inferred by Dagger, it makes sense to just declare that as a method without a body (an abstract method) and have Dagger apply the behavior.

But, if we were to just say that abstract @Provides methods should be treated as we do for @Binds methods, the specification of @Provides would basically be two specifications with a bunch of conditional logic. For example, a @Provides method can have any number of parameters of any type, but a @Binds method can only have a single parameter whose type is assignable to the return type. Separating those specifications makes it easier to reason about correctness because the annotation determines the constraints.

バインディングを構成するための最も一般的な構成要素である@Providesは、3つの機能を提供します。
 1.どのタイプ(修飾されている可能性がある)が提供されているかを宣言します—これは戻りタイプです
 2.依存関係を宣言します—これらはメソッドのパラメーターです
 3.インスタンスが提供される方法を正確に実装します—これはメソッド本体です

最初の2つの関数は一意であり、「すべての@Provides」メソッドにとって重要ですが、3番目の関数は多くの場合、退屈で反復的です。そのため、実装がDaggerによって推論されるほど単純で一般的な@Providesが存在する場合はいつでも、それを本体のないメソッド(抽象メソッド)として宣言し、Daggerに動作を適用させることが理にかなっています。

しかし、abstract @Provides methodsを@Binds methodsのように扱うべきであると言うだけなら、@Providesの仕様は基本的に条件付きロジックの束を持つ2つの仕様になります。たとえば、@Provides methodは、任意の型の任意の数のパラメーターを持つことができますが、a @Binds methodは、型が戻り型に割り当て可能な単一のパラメーターのみを持つことができます。これらの仕様を分離すると、注釈によって制約が決定されるため、正確性についての推論が容易になります。

まとめ

kotlin でいうとこの

1. 基本 @Binds を使う。
2. Application 起動の object の場合(static な singleton メソッドの場合)は @Provides を使う。

という理解でいいのか。

👉 ATM - Dagger Tutorial 


coroutine の使い方 - Android Architecture Blueprints v2 #1

気がついたら「v2」です。MVVM のみとなって、 RxJava は姿を消していますが。

👉 googlesamples/android-architecture: A collection of samples to discuss and showcase different architectural tools and patterns for Android apps. 



現在、4つのバリエーションが公開されていますが、以下は共通。


- kotlin
- coroutine
- single activity
- architecture component
- navigation component + fragment
- presentetion layer(per page) = fragment + view model
- reactive ui = live data + data binding
- data layer = repositpory + local(room) + remote
- datalayer one shot operations(no listener or data streams)

非同期処理には、どのバリエーションも「coroutine」使う。

どのように coroutine を使っているか、を定型化しておきたい。

関数 coroutineScope

「kotlinx-coroutines-core」の関数の「coroutineScope」 が目についたので見ておく。


suspend fun <R> coroutineScope(
    block: suspend CoroutineScope.() → R
): R (source)

CoroutineScope を作成し、このスコープで指定された suspend ブロックを呼び出します。その外側のスコープから coroutineContext を継承しますが、そのコンテキストのJobをオーバーライドします。

この関数は、処理の並列分解用に設計されています。 このスコープ内のいずれかの子コルーチンが失敗すると、このスコープは失敗し、残りのすべての子はキャンセルされます(supervisorScope との違いを参照してください)。 与えられたブロックとそのすべての子コルーチンが完了するとすぐに戻ります。
スコープの使用例は次のようになります。


suspend fun showSomeData() = coroutineScope {

  val data = async(Dispatchers.IO) { // <- extension on current scope
     // ... load some UI data for the Main thread ...
  }

  withContext(Dispatchers.Main) {
    doSomeWork()
    val result = data.await()
    display(result)
  }
}

この例のスコープの意味は次のとおりです。

1. showSomeDataは、データがロードされてUIに表示されるとすぐに戻ります。
2. doSomeWorkが例外をスローすると、非同期タスクはキャンセルされ、showSomeDataはその例外を再スローします。
3. showSomeData の外部スコープが取り消されると、開始された async ブロックとwithContext ブロックの両方が取り消されます。
4. 非同期ブロックが失敗すると、withContext はキャンセルされます。

現在のジョブが外部でキャンセルされた場合、メソッドは CancellationException をスローします。このスコープ内に未処理の例外がある場合(たとえば、このスコープ内の起動で開始されたクラッシュコルーチンから)は、対応する未処理のThrowableをスローします。

coroutineScope - kotlinx-coroutines-core

実際の記述

coroutine を使った非同期処理は 各 ViewModel を起点に記述されています。


class TasksViewModel(
    private val tasksRepository: TasksRepository
) : ViewModel() {

    fun loadTasks(forceUpdate: Boolean) {
        viewModelScope.launch {

            // 対応する Repository メソッドをコール
            // val tasksResult = tasksRepository.getTasks(forceUpdate)

        }
    }

}

👉 android-architecture/TasksViewModel.kt at master · googlesamples/android-architecture 

Repository を展開して、スコープ周りを抜き出してみると、


class TasksViewModel(
    private val tasksRepository: TasksRepository
) : ViewModel() {

    fun loadTasks(forceUpdate: Boolean) {
        viewModelScope.launch {

            withContext(ioDispatcher) {
            
                // ...            

            }

        }
    }

}

というこれまで通り withContext() を使った dispatcher の切り換え。

他には、

前述の coroutineScope 関数を使った記述が、単独、並列、入れ子の3種類。


override suspend fun saveTask(task: Task) {
    coroutineScope {
        launch { tasksRemoteDataSource.saveTask(it) }
        launch { tasksLocalDataSource.saveTask(it) }
    }
}


override suspend fun clearCompletedTasks() {
    coroutineScope {
        launch { tasksRemoteDataSource.clearCompletedTasks() }
        launch { tasksLocalDataSource.clearCompletedTasks() }
    }
    withContext(ioDispatcher) {
        cachedTasks?.entries?.removeAll { it.value.isCompleted }
    }
}


override suspend fun deleteAllTasks() {
    withContext(ioDispatcher) {
        coroutineScope {
            launch { tasksRemoteDataSource.deleteAllTasks() }
            launch { tasksLocalDataSource.deleteAllTasks() }
        }
    }
}

👉 android-architecture/DefaultTasksRepository.kt at master · googlesamples/android-architecture 

今後、さらに簡潔に記述されていくのだろうが、意図は今のが理解しやすいと思いメモ。