Infinito Nirone 7

白羽の矢を刺すスタイル

Dagger Hilt と WorkManager を組み合わせて使う

Dagger Hilt は Android 用に様々な場面で使いやすいようになっていて、WorkManager を使った場合にも Dagger Hilt で DI が実現できるようになっています。

依存関係

Dagger Hilt と WorkManager を依存関係に追加します。2021/12 時点で Dagger Hilt の KSP 対応は完了していないので、kapt を使います。

buildscript {
    dependencies {
        // Hilt Gradle Plugin への依存を追加
        classpath("com.google.dagger:hilt-android-gradle-plugin:2.40.3")
    }
}
plugins {
    // kapt を適用
    kotlin("kapt")
    // Hilt Gradle Plugin を適用
    id("dagger.hilt.android.plugin")
}

dependencies {
    // Dagger-Hilt の依存
    implementation("com.google.dagger:hilt-android:2.40.3")
    kapt("com.google.dagger:hilt-android-compiler:2.40.3")
    // AndroidX Hilt の依存
    implementation("androidx.hilt:hilt-common:1.0.0")
    kapt("androidx.hilt:hilt-compiler:1.0.0")
    implementation("androidx.hilt:hilt-work:1.0.0")
    // WorkManager の依存
    implementation("androidx.work:work-runtime-ktx:2.7.1")
}

kapt {
    correctErrorTypes = true
}

Worker の定義

Worker の定義は次の通りで、@HiltWorker, @AssistedInject, @Assisted の 3 つのアノテーションを使います。 - @HiltWorker: クラス定義に使うアノテーション - @AssistedInject: Worker のコンストラクタに使うアノテーション - @Assisted: WorkManager 内部で Worker に渡される Context と WorkerParameters に対して使うアノテーション

@HiltWorker
class SampleWorker @AssistedInject constructor(
    @Assisted applicationContext: Context,
    @Assisted params: WorkerParameters,
) : Worker(applicationContext, params) {
    override fun doWork(): Result {
      // ...
    }
}

この Worker に対し、さらに別のオブジェクトを差し込みたい場合は単純にコンストラクタに差し込みたいオブジェクトを追加していくだけです。

@HiltWorker
class SampleWorker @AssistedInject constructor(
    @Assisted applicationContext: Context,
    @Assisted params: WorkerParameters,
    // なんらかの data source レイヤのクラスを注入する(別途この data source の実体を提供するための module の宣言などは必要)
    private val sampleDataSource: SampleDataSource,
) : Worker(applicationContext, params) {
    override fun doWork(): Result {
      // ...
    }
}

WorkerFactory の追加

WorkManager では Work クラスの生成はほぼ自分で記述することがありません。Worker の定義がシンプルでコンストラクタの引数に Context と WorkerParameters しかない場合は、WorkRequest を経由して自動で Worker がインスタンス化されます。一方で引数に Context と WorkerParameters 以外のものがある場合は WorkManager が自動で Worker を生成できないため、Worker を生成するための手順を実装し WorkManager に教えてあげる必要があります。

Dagger Hilt を使う場合、先ほどの SampleWorker を生成するには Dagger が知っている object graph から SampleDataSource の実体を取り出して Worker にわたす手順が必要ですが、その手順は hilt-work が用意してくれていて、アプリの実装としては Application クラスを拡張し必要なインタフェースの実装を追加するだけになります。

@HiltAndroidApp
// androidx.work の Configuration.Provider を実装する
class ExampleApplication : Application(), Configuration.Provider {

    // Dagger Hilt 用の WorkerFactory
    @Inject lateinit var workerFactory: HiltWorkerFactory

    // Dagger Hilt 用の WorkerFactory を設定して Configuration を返す
    override fun getWorkManagerConfiguration() =
        Configuration.Builder()
            .setWorkerFactory(workerFactory)
            .build()
}

この設定のため AndroidManifest.xml では WorkManager の default initializer を無効化しておきます。default initializer の無効化手順は、アプリで App Startup を使っているかどうかによって変わります。WorkManager は内部で App Startup の仕組みを使っているため、アプリが WorkManager 以外の用途で App Startup を使っている場合は、その App Startup から WorkManager のみを無効化する必要があります。

<!-- アプリで他に AppStartup を使わない場合 -->
<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    tools:node="remove">
</provider>
<!-- アプリで他に AppStartup を使っている場合 -->
<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data
        android:name="androidx.work.WorkManagerInitializer"
        android:value="androidx.startup"
        tools:node="remove" />
</provider>

WorkRequest を使って動かす

あとは Worker を動かす手順を実装するだけです。注意点として、WorkManager のインスタンスは必ず WorkManager.getInstance(Context) を使って取得します(引数のない getInstance メソッドでは WorkerFactory の設定などが無視されてしまう)。

val delay = 1000L
val params = Data.Builder()
    .putInt("number", 1)
    .build()

val workManager = WorkManager.getInstance(Context)
val work: OneTimeWorkRequest = OneTimeWorkRequest.Builder(SampleWorker::class.java)
    .setInitialDelay(delay, TimeUnit.MILLISECONDS)
    .setInputData(params)
    .build()
workManager.beginUniqueWork("sample_work", REPLACE, work).enqueue()

Target SDK Version を 31 に上げるときに引っかかるポイント: SparseArray

Kotlin を使用したアプリケーションという前提で、次のような構成のアプリがあり、このアプリの Target SDK Version および Compile SDK Version を 31 (Android 12) に上げることを考えます。

Target SDK Version を上げる前の構成: build.gradle

android {
    compileSdk 30

    defaultConfig {
        applicationId "dev.keithyokoma.sample"
        minSdk 23
        targetSdk 30
    }
}

dependencies {
    implementation 'androidx.core:core-ktx:1.6.0'
}

SparseArray に値をセットする

上記の構成のとき、次のようなコードは正しく意図通り動作します。 注目すべきは SparseArray に値をセットするコードです。AndroidX Core KTX の set 拡張関数 を使うことで、メソッド呼び出しではなく指定した添字への値の代入のように記述できます。

import androidx.core.util.set

val array = SparseArray<String>()
array[0] = "test" // AndroidX Core KTX の set 拡張関数を使っている

Target SDK Version および Compile SDK Version を 31 にあげる

ここで構成を変え、Target SDK Version と Compile SDK Version を最新の 31 に上げます。 するとビルド時にエラーが出力されます。

Call requires API level S (current min is 23): android.util.SparseArray#set

エラーメッセージが示す関数が androidx.core.util.set ではなく android.util.SparseArray#set になっています。これは、Android 12 (API Level 31) から新たに SparseArray#set メソッドが追加されたためです。 この新しい SparseArray#set メソッドを Kotlin で解釈したとき、Java で定義されたメソッドを添え字での値の代入として扱えるようにする仕組みが働き、array[0] = "test" はそのまま正しくコンパイル可能なコードになります。 同時に AndroidX Core KTX の set 拡張関数が使われなくなり(31 に上げると、上記 Kotlin のコードの import 文が unused になります)、minSdkVersion = 31 を要求する新しいメソッドを使っていることになるため、このようなエラーになります。

回避策

Target SDK Version および Compile SDK Version を 31 にした状態では拡張関数が利用できないので、次のように拡張関数が呼び出していた SparseArray#put を使います。

val array = SparseArray<String>()
array.put(0, "test")

類似のケース

実は Android 11 (API 30) 対応でも SparseArray の使用方法で実行時にエラーとなるケースがあったようです。

https://issuetracker.google.com/issues/168724187?pli=1

BottomNavigationView で setupWithNavController と setOnNavigationItemSelectedListener を同時に使いたい

Android Jetpack の Navigation Component と BottomNavigationView を組み合わせる場合、setupWithNavController 拡張関数を呼びだすだけで nav graph と BottomNavigationView の menu を紐付けてくれるようになります。

val navView: BottomNavigationView = ...
val navController: NavController = ...

navView.setupWithNavController(navController)

ここで、BottomNavigationView の menu を選択したときにコールバックを受けたい場合、次のように setOnNavigationItemSelectedListener を使ったコードを書くと BottomNavigationView の menu と nav graph の紐付けが壊れて画面の切り替えができなくなります。 setupWithNavController 拡張関数は内部で setOnNavigationItemSelectedListener を使って BottomNavigationView の menu を選択したときの処理を記述しているため、次のコードはその処理を上書きしてしまい、その結果画面の切り替えができなくなります。

val navView: BottomNavigationView = ...
val navController: NavController = ...

navView.setupWithNavController(navController)
navView.setOnNavigationItemSelectedListener { menu ->
  // Callback
  Log.d("Sample", "$menu is selected!!!")
  true
}

NavController の addOnDestinationChangedListener を使って各 menu に対応する destination に切り替わったことを検知するロジックを作ると、BottomNavigationMenu の menu を選択したときのコールバックと同等の機能が実現できます*1。 もし setOnNavigationItemSelectedListener を使いたい場合は、次のように setupWithNavController の実装を持ってくる必要があります。

val navView: BottomNavigationView = ...
val navController: NavController = ...

navView.setupWithNavController(navController)
navView.setOnNavigationItemSelectedListener { menu ->
  // Callback
  Log.d("Sample", "$menu is selected!!!")  
  NavigationUI.onNavDestinationSelected(menu, navController) // この部分が setupWithNavController でやっていること
}

Hilt 1.0.0 へのマイグレーション

Google I/O 2021 で Hilt がついに安定版に到達し、1.0.0 がリリースとなったことが告知されました。

この記事を執筆時点で Dagger Hilt および AndroidX Hilt の最新版は次のとおりです。

Dagger Hilt: 2.36 AndroidX Hilt: 1.0.0

それぞれにコンポーネントがあり別々のバージョン番号があるので少し分かりづらい状況になっていますが、少なくとも Hilt が安定版となったのは Dagger Hilt 2.35 からであることに特に注意します。

バージョンアップにともなうマイグレーション作業

ここでは主に Dagger Hilt 2.34 より前からのマイグレーション作業にフォーカスして記述します。

Dagger Hilt 2.34: @ViewModelInject の置き換え

@ViewModelInject が廃止され、@HiltViewModel に置き換わりました。これにともなって、コンストラクタに @Inject アノテーションをつける必要があります。

@HiltViewModel // @ViewModelInject ではなく @HiltViewModel を使い、コンストラクタに @Inject をつける
class SampleViewModel @Inject constructor(
  ...
) : ViewModel()

Dagger Hilt 2.34: SavedStateHandle のための @Assisted の削除

ViewModelSavedStateHandle を inject するために利用していた @Assisted が不要になりました。単純に削除するだけで OK です。

@HiltViewModel
class SampleViewModel @Inject constructor(
  ...
  savedStateHandle: SavedStateHandle, // @Assisted を消す
) : ViewModel()

Dagger Hilt 2.34: androidx.hilt:hilt-lifecycle-viewmodel への依存の削除

AndroidX Hilt には ViewModel 対応のためのアーティファクトとして androidx.hilt:hilt-lifecycle-viewmodel が用意されていますが、安定版では必要ないため削除します。Google Maven Repository には 1.0.0-alpha-03 までのバージョンがアップロードされていますが、純粋に必要なくなったため 1.0.0 のリリースはありません。依存を削除しましょう。 (AndroidX Hilt 側のリリースノートではなく Dagger Hilt 側のリリースノートに記述があるためすこし紛らわしいですが…… twitter を検索すると gerrit code review で androidx.hilt:hilt-lifecycle-viewmodel への依存を切るための差分がサブミットされている様子も見つかります。)

Dagger Hilt 2.36: Fragment#getContext の振る舞いの修正

これまで、Hilt において Fragment#getContext がうっかり Framgent が削除されたあとでもContext インスタンスを返していました。これは通常の Fragment とは異なる動きであり、通常の Fragment のように振る舞うことが本来の動作であったため、2.36 で修正が入ります。ただし、この修正には相当のインパクトが見込まれるため、 -Adagger.hilt.android.useFragmentGetContextFix=true をつかって feature flag を有効にしない限り、2.36 でも以前のバージョンと同じく Hilt の Fragment#getContextFragment が削除されたあとでも Context インスタンスを返します。

Deprecated アノテーションが deprecated になってしまったのを undeprecated した流れ

Android 12 の preview 段階で @Deprecated アノテーションが deprecated になったのがちょっと話題になりましたが、Android 12 Beta 1 では deprecated になったのを undeprecated にしたことが What's new in Android で語られました。

youtu.be

@Deprecated アノテーションは少し特殊で、Javadoc に @deprecated タグを記述することでもクラスやメソッドなどが非推奨であることを示します。 Android 12 では @Deprecated アノテーションに変更があり、forRemoval メソッドと since メソッドが増えています。これらを用いて、非推奨となったクラスやメソッドが将来的に削除予定かどうかを簡単に示せるようになります。

developer.android.com

このメソッドの追加にあわせて @Deprecated アノテーションの Javadoc も拡充されていて、より詳しく @Deprecated アノテーションの役割や挙動を説明するようになりました。 ここで Javadoc 内の @Deprecated アノテーションを表記するために {@code @Deprecated} と言う形でコードブロックの記法を使うようになりましたが、このコードブロック内の @Deprecated が Javadoc の @deprecated タグと解釈され、結果として @Deprecated アノテーションそのものが deprecated と解釈されてしまった、というのが @Deprecated アノテーションが deprecated となった経緯のようです。

うっかり deprecated になってしまった @Deprecated を undeprecated にするため、コードブロック内であっても @ をエスケープする(&#64;にする)差分が作られ、晴れて undeprecated することができたようです。

チームで育てるAndroidアプリ設計の一般販売が始まりました。

告知記事です。

Peaks のクラウドファンディングで執筆し先日電子版を先行リリースした「チームで育てるAndroidアプリ設計」の一般販売が始まりました。 これまではクラウドファンディングで出資いただいた方にのみ電子版・書籍の配送手続きをしていましたが、本日からクラウドファンディングに参加していない一般の方々にも電子版・物理本の購入をいただけるようになりました。

peaks.cc

チームで育てるAndroidアプリ設計とは

改めてこの書籍が何なのかを紹介すると、大小様々な規模のチームで継続的にAndroidアプリの開発をすすめていく中で直面するアーキテクチャの成長痛を乗り越えるためのノウハウを詰め込んだ本です。

アーキテクチャは一度整えればそれで終わるものではなく、プロダクトの成長やチームの成長とともに少しずつ形を変えていくものであるという考えのもと、最初の一歩としてどのようにアーキテクチャを選定しチームに根付かせていくか、またアプリの成長にともなって徐々に現れるひずみをどのように解消していくのか、実際の方法論を交えつつも根本にある思想や考え方、行動指針を示すことで、特定のチームにおける実例を他のチームにも活かせるプラクティスとしてまとめています。

新規事業の立ち上げから運用にいたるまでの比較的小規模なチームにおける事例を @kgmyshin さんが担当し、すでに成長を続けてきたサービスをさらに拡大していく比較的大規模なチームにおける事例を自分が担当しました。それぞれ4章分の内容があります。そして最後の章では大小それぞれの事例を振り返り、規模によらない共通点や規模によって異なるポイントをまとめています。

クラウドファンディング開始当初の意気込みなんかは次の記事に書いてありますのであわせてどうぞ。

blog.keithyokoma.dev

オンライン輪読会

実はこのプロジェクトはまだ続いていて、出版後にオンラインで輪読会を開催します。

techbookfest.connpass.com

全9回、各回で書籍の1章分の内容を輪読します。初回は早速明日4/27の22時からで、1週間ごとに読みすすめる予定です。 YouTube で配信予定で、アーカイブもあるので当日参加できない方もあとからご視聴いただけます。

val age = 0x20

やったね僕も二十歳(16進数)になりました!

去年の自分はなにか目標でも立ててたのかと思って振り返ったら何もありませんでした。代わりに DroidKaigi がコロナ禍の始まりとかちあって中止となったことで、それまでのいろいろな準備をせめて何らかの形でアウトプットしようという供養エントリを書いていました。

blog.keithyokoma.dev

まだまだコロナ禍は収まる気配はなく、DroidKaigi も平年のような大きな会場を利用しての開催予定をたてるには難しい状況ですが、Podcast を始めたり2021年版公式アプリを公開したりと少しづつ活動の幅を広げてきています。

自分自身はというと、去年は思ってもいませんでしたが新しい会社で働いていて引き続き Android アプリをもりもり作っています。 今は Android エンジニアが自分ひとりということもあり、とにかく Android アプリの実装に必要な判断を自分ひとりでやっている状況なので、はやくコードそのものだけでなく設計やら作り方など含めてレビューしてくれる仲間を求めています。もちろん単にアプリを作るだけじゃなくて、いろんなアイディアを話し合う仲間でもあってほしいですが。 スタートアップということでまだまだ足りないものだらけですが、着実に前進していて楽しく仕事をしています。新しいもの、足りてないものをもりもり作るのが好きな人は声をかけてもらえれば、いつでもお話できます。

あとはクラウドファンディングでの技術書執筆プロジェクトもすすめています。リリースがだいぶ近づいており、佳境という感じです。絶対にリリースするぞ!

干し芋