SQLDelight で View を使うべし

👉 Drive your UI with SQLDelight’s views | Leandro Favarin 
👉 GitHub - cashapp/sqldelight: SQLDelight - Generates typesafe Kotlin APIs from SQL 

SQLDelight は、すべてのクエリーに対して自動的にモデルオブジェクトを作成します。

以下シンプルな名前付きクエリー。


bandsOrderedByName:
SELECT id, name
FROM band
ORDER BY name DESC;

bandsOrderedByAge:
SELECT id, name
FROM band
ORDER BY age;

これから以下が作成される。


data class BandsOrderedByName(id: String, name: String)

data class BandsOrderedByAge(id: String, name: String)

実際は、もっと複雑になります。

以下、join句を使ったクエリーの場合。


SELECT
  band.id,
  band.name,
  album.*
FROM band
JOIN album ON band.id = album.band_id;

SQL View を使うとエレガントになります。


👉 SQLite Query Language: CREATE VIEW 


CREATE VIEW bandWithAlbum AS
SELECT
  band.id,
  band.name,
  album.*
FROM band
JOIN album ON band.id = album.band_id;

bandsOrderedByName:
SELECT *
FROM bandWithAlbum
ORDER BY name DESC;

bandsOrderedByAge:
SELECT *
FROM bandWithAlbum
ORDER BY age;

SQLDelight は、BandWithAlbum タイプを生成します。

続いて、ページネーションの例。


count:
SELECT count(*)
FROM bandWithAlbum;

paged:
SELECT *
FROM bandWithAlbum
LIMIT ?
OFFSET ?;

SQLDelight が生成するモデルは、data クラスなので、DiffUtil コールバックはすぐに書けます。


object BandItemCallback : ItemCallback<BandWithAlbum>() {
  override fun areItemsTheSame(oldItem: BandWithAlbum, newItem: BandWithAlbum): Boolean {
    return oldItem.id == newItem.id
  }

  override fun areContentsTheSame(oldItem: BandWithAlbum, newItem: BandWithAlbum): Boolean {
    return oldItem == newItem
  }
}

また、enum クラスを使ったソートオプション。


enum class Sort { NAME, AGE }

fun bandsSorted(by: Sort): Flow<List<BandWithAlbum>> = when (by) {
  NAME -> db.bandsOrderedByName()
  AGE -> db.bandsOrderedByAge()
}.asFlow().mapToList()

逆に、これらのようなSQL処理をプログラムで実行すると効率は落ちます。
👉 The Resurgence of SQL (Droidcon NYC 2017) - Speaker Deck 

まとめ

欲しいタイプを View にすると、少ないコードで実現できます。

ユーザーの要求は、技術が発達するにつれてますます激しくなることは明らかです。良きユーザエクスペリエンスのための簡単な実装方法を常に把握しておくことが重要になります。


画像読み込みライブラリ「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