Arrangement.spacedBy()

Arrangement.spacedBy() を使うと、Column や Row の要素間に同じ大きさの余白を設けることができます。

Spacer で余白を実装する場合、上端や下端に余白が入らないように index を使った制御が必要になります。 Column { list.forEachIndexed { index, item -> if (index > 0) { Spacer(Modifier.height(8.dp)) } ListItem(...) } } Arrangement.spacedBy() を使う場合、Spacer や index を使った制御が不要になるほか、if 文で要素を表示しないときに余白も自動で表示されなくなります。 Column( verticalArrangement = Arrangement.spacedBy(8.dp) ) { list.forEach { item -> ListItem(...) } }

Kotlinらしいコードを書こう - Convert Java File to Kotlin File のあとにやること

KotlinFest 2024 で話すはずだった講演内容です。

---

みなさん、こんにちは。あんざいゆきです。Android の Google Developer Expert をしています。よろしくお願いします。

私はいろんなクライアントさんの Android アプリ開発のお手伝いをさせていただいていまして、Java から Kotlin に変換した Pull Request のレビューをすることがあります。

プロジェクトの大多数がまだ Java だったり、最近 Android 開発をはじめたばかりだったりして Kotlin になじみがない場合だと、自動変換されただけのような状態でレビュー依頼されることがままあります。

そこでこのセッションでは、Java から Kotlin に自動変換したあと、より Kotlin らしいコードにするためにどういうことをしてほしいのかを紹介したいと思います。

Kotlin らしいコードの話をする前に、Java から Kotlin に変換する Pull Request について話したいと思います。

1 commit で Kotlin 化すると、Java ファイルの削除と Kotlin のファイルの新規追加の履歴になり、Kotlin 化前後のコードを比較するのがけっこう大変です。

そこで、Kotlin 化する前に拡張子を .java から .kt に rename する commit を入れておきます。中身は Java のままです。
commit したら拡張子をまた .kt から .java に戻し、その後に Convert Java File to Kotlin File などで Kotlin 化します。

こうした場合、rename と Kotlin 化の 2つの commit の Pull Request になります。
Files changed タブだと 1 commit で Kotlin 化したときと同じように Kotlin 化前後のコードを比較するのが大変なんですが、

Commits タグを開いて

2つめの commit をみると

同じ .kt ファイルの変更なので、Kotlin 化前後のコードが比較しやすい表示になります。

では本題に入りましょう。

残念ながら Java コード側の情報が少ないと変換したコードに !! が出てくることがあります。
!! が不要になるようにコードを修正しましょう。
この例では引数の newItems を non-null にすれば !! は不要になります。

@NonNull アノテーションがついていない場合、@Nullable なメソッドに渡されている変数は nullable だと解釈されます。
例えば Bundle の putString() メソッドは key も value も @Nullable アノテーションがついています。

そのため Kotlin に自動変換すると、createInstance() メソッドの title 引数は nullable String になります。
もともと null が来ることを想定しているならこのままでよいですが、

null が来ることがありえない、あってはいけないという場合はそれを表現するよう non-null にしましょう。

型パラメータも自動変換時に nullable と判定されることがあるので注意しましょう。

初期化の後に利用されることが保証できる場合（初期化前アクセスが発生するのはコーディングエラー時のみという場合）、

lateinit var を使うことで non-null にすることができます。

var を val にできないか考えましょう。
Kotlin の標準ライブラリに用意されている関数を利用することで val にできることがよくあります。

様々な便利関数があるので、変換されたやつでいいやってなる前に、活用できるものがないか調べましょう。

?.let や ?: を使ってより簡潔に記述できるようにならないか考えましょう。

apply や also は初期化処理をまとめるのによく使います。

Kotlin では使っていない lambda の引数を _ にすることができます。
自動変換ではやってくれませんが、変換後のコードでグレーの波線が出るので対応しましょう。

A から B に変換する処理は Aの拡張関数にすると呼び出し側がすっきりします。

自動変換では Smart cast が効いている部分の cast を外してくれないので自分で外しましょう。

また、as? を使うことでチェックと呼び出し部分を1行で書くこともできます。

Java の switch 文は自動で when にしてくれますが、if else の連続は自動で when にしてくれません。

必要に応じて自分で when にしましょう。

Java から Kotlin の lambda を引数にとるメソッドを呼んでいる部分があるとします。
これを Kotlin 化した場合、関数参照を使ったほうが記述が簡潔になる場合があります。

List を操作する Java コードを Kotlin に自動変換した場合、MutableList を使ったものになります。

Kotlin std lib に用意されているメソッドを使うと MutableList を不要にできることがあります。

Java では Mutable Collection と Immutable Collection で型が分かれていないので、自動変換すると mutable として外部に公開するべきでないところでも mutable として公開されてしまいます。

Mutable Collection の変数は private にし、公開用に Immutable Collection 型のプロパティを定義するようにします。

Java で ArrayList を new しているところは自動変換しても同じです。

mutableListOf() を使ってより Kotlin らしいコードにしましょう。
同様に HashMap, LinkedHashMap には mutableMapOf(), HashSet, LinkedHashSet には mutableSetOf() が使えます。

List や Map を構成する部分は、自動変換ではほぼそのままの形にしかなりません。

初期化時のみ List や Map を編集するのであれば buildList { } や buildMap { } を使って Mutable Collection の変数が定義されないようにしましょう。

Android 特有の内容も紹介します。

Bundle の生成用に bundleOf() メソッドが用意されています。

TextUtils.isEmpty() は Kotlin の isNullOrEmpty() に置き換えましょう。

TextUtils.equals() は Kotlin の == に置き換えましょう。

Kotlin では、Activity や Fragment で ViewModel のインスタンスを取得するのに by viewModels() を利用することができます。

DI で値がセットされるフィールドは Java から Kotlin に自動変換すると nullable の var になってしまいます。
しかしこれらは参照されるときには値がすでにセットされていることが期待されるものなので、lateinit var に変えましょう。

最後にチェックリストをまとめました。ありがとうございました。

---

WorkManager で android.net.ConnectivityManager$TooManyRequestsException が起こった場合、Coil の使い方が良くない場合がある

WorkManager の Worker の Constraints として val constraints = Constraints.Builder() .setRequiredNetworkType(NetworkType.CONNECTED) .build() val request = OneTimeWorkRequestBuilder<MyWorker>() .setConstraints(constraints) .build() のように RequiredNetworkType を指定すると、ConnectivityManager の registerDefaultNetworkCallback() が呼ばれます。

ここで TooManyRequestsException が起こったときに、Coil の使い方が原因になってることがありました。

registerDefaultNetworkCallback() の実装を見ると、同時に 100 を超える NetworkCallback を register すると exception が投げられると書いてあります。 /** * ... * * To avoid performance issues due to apps leaking callbacks, the system will limit the * number of outstanding requests to 100 per app (identified by their UID), ... If this limit is * exceeded, an exception will be thrown. ... */ @RequiresPermission(android.Manifest.permission.ACCESS_NETWORK_STATE) public void registerDefaultNetworkCallback(@NonNull NetworkCallback networkCallback) { registerDefaultNetworkCallback(networkCallback, getDefaultHandler()); } つまり、どこかで同時に大量に NetworkCallback を登録してるところがあるということです。

それがどこか探したところ、coil の ImageLoader.kt にいる @JvmName("create") fun ImageLoader(context: Context): ImageLoader { return ImageLoader.Builder(context).build() } をリクエストごとに呼び出している箇所が原因でした。

coil では ImageLoader ごとに registerDefaultNetworkCallback() が呼ばれます。

ImageLoader.Builder の build() で RealImageLoader が作られ、NetworkObserver が作られ、 RealNetworkObserver() が作られます。
RealNetworkObserver の init で registerNetworkCallback() しています。 private class RealNetworkObserver( private val connectivityManager: ConnectivityManager, private val listener: Listener ) : NetworkObserver { ... init { val request = NetworkRequest.Builder() .addCapability(NET_CAPABILITY_INTERNET) .build() connectivityManager.registerNetworkCallback(request, networkCallback) } ... } RealNetworkObserver のインスタンスを作るところで try-catch しているので、ここでは問題に気づかず、WorkManager の方で発覚したということでした。 internal fun NetworkObserver( context: Context, listener: Listener, logger: Logger? ): NetworkObserver { val connectivityManager: ConnectivityManager? = context.getSystemService() ... return try { RealNetworkObserver(connectivityManager, listener) } catch (e: Exception) { logger?.log(TAG, RuntimeException("Failed to register network observer.", e)) EmptyNetworkObserver() } } ImageLoader のインスタンスを取得するときは ImageLoader.kt にいる ImageLoader() ではなく、Coil.imageLoader() を使うようにしましょう！

こちらは共通の ImageLoader インスタンスが返されるので registerNetworkCallback() を呼び過ぎることにはなりません。


参考 : https://issuetracker.google.com/issues/231499040#comment3