【Kotlin】コピペで使える「null」を消すテクニック頻出順40

 

🧑🏻‍💻 1. Non-null を基本にする


// 悪い
val name: String?

// 良い
val name: String

Nullable を作らないことが最も重要。

 

🧑🏻‍💻 2. DTOだけ Nullable


data class UserResponse(
    val name: String?
)

外部データだけ Nullable にする。

 

🧑🏻‍💻 3. Domain は Non-null


data class User(
    val name: String
)

アプリ内部では Non-null を維持する。

 

🧑🏻‍💻 4. Repositoryで吸収する


fun load(): User =
    api.load()?.toUser() ?: User.EMPTY

Repository より先へ Nullable を持ち込まない。

 

🧑🏻‍💻 5. デフォルト値を使う


data class User(
    val name: String = ""
)

初期値で null を不要にする。

 

🧑🏻‍💻 6. orEmpty()


val name = user.name.orEmpty()

null を空文字へ変換する。

 

🧑🏻‍💻 7. emptyList()


fun users(): List<User> = emptyList()

List? を返さない。

 

🧑🏻‍💻 8. emptyMap()


fun settings(): Map<String, String> = emptyMap()

Map? を返さない。

 

🧑🏻‍💻 9. emptySet()


fun tags(): Set<String> = emptySet()

Set? を返さない。

 

🧑🏻‍💻 10. ?: return


val user = repository.find(id) ?: return

null を早期に除去する。

 

🧑🏻‍💻 11. ?: continue


val name = user.name ?: continue

ループ中の null をスキップする。

 

🧑🏻‍💻 12. ?: break


val item = iterator.nextOrNull() ?: break

null を終了条件として扱う。

 

🧑🏻‍💻 13. ?: error()


val token = token ?: error("Token required")

あり得ない null は即座に失敗させる。

 

🧑🏻‍💻 14. mapNotNull()


val names = users.mapNotNull { it.name }

変換と null 除去を同時に行う。

 

🧑🏻‍💻 15. filterNotNull()


val names = names.filterNotNull()

Collection の null を取り除く。

 

🧑🏻‍💻 16. Flow filterNotNull()


val users: Flow<User> =
    repository.userFlow.filterNotNull()

Flow の null を流さない。

 

🧑🏻‍💻 17. firstOrNull() ?: return


val user = users.firstOrNull() ?: return

最初の要素が無ければ早期終了する。

 

🧑🏻‍💻 18. by lazy


private val repository by lazy {
    UserRepository()
}

遅延初期化で Nullable を不要にする。

 

🧑🏻‍💻 19. Smart Cast(ローカル変数へ退避)


val user = currentUser ?: return

println(user.name)

Smart Cast を有効にして !! を避ける。

 

🧑🏻‍💻 20. StateFlow を Nullable にしない


private val uiState =
    MutableStateFlow(UserUiState())

StateFlow より状態オブジェクトを持つ。

 

🧑🏻‍💻 21. Compose State を Nullable にしない


var uiState by mutableStateOf(UserUiState())

mutableStateOf より状態オブジェクトを持つ。

 

🧑🏻‍💻 22. Java境界で Non-null 化する


val title: String =
    javaApi.title.orEmpty()

Platform Type (String!) を入口で閉じ込める。

 

🧑🏻‍💻 23. requireNotNull()


val user = requireNotNull(user)

引数や入力値の null を早期に拒否する。

 

🧑🏻‍💻 24. checkNotNull()


val database = checkNotNull(database)

オブジェクトの状態が不正なら失敗させる。

 

🧑🏻‍💻 25. Null Object Pattern


interface Logger

object EmptyLogger : Logger

Logger? の代わりに空実装を使う。

 

🧑🏻‍💻 26. sealed class / interface


sealed interface UiState {
    data object Loading : UiState
    data class Success(val users: List<User>) : UiState
    data class Error(val message: String) : UiState
}

null の代わりに状態を型で表現する。

 

🧑🏻‍💻 27. Result


fun load(): Result<User>

失敗を null ではなく Result で表現する。

 

🧑🏻‍💻 28. value class


@JvmInline
value class UserId(val value: Long)

IDなどを専用型にして null を減らす。

 

🧑🏻‍💻 29. takeIf()


val adult = user.takeIf { it.age >= 18 } ?: return

条件を満たさなければ早期終了する。

 

🧑🏻‍💻 30. firstNotNullOf()


val token = providers.firstNotNullOf {
    it.token
}

最初に見つかった Non-null 値を取得する。

 

🧑🏻‍💻 31. SharedFlow を使う


private val events = MutableSharedFlow<Event>(
    replay = 1
)

イベントでは StateFlow より SharedFlow が適している場合がある。

 

🧑🏻‍💻 32. Nothing を使う


fun fail(message: String): Nothing =
    throw IllegalStateException(message)

val token = token ?: fail("Token required")

Nothing を使うと独自のガード関数を作れる。

 

🧑🏻‍💻 33. !! を使わない


// 悪い
val user = user!!

// 良い
val user = requireNotNull(user)

!! より意図が明確な API を使う。

 

🧑🏻‍💻 34. let を減らす


// 悪い
user?.let {
    println(it.name)
}

// 良い
val user = user ?: return
println(user.name)

ネストを減らして読みやすくする。

 

🧑🏻‍💻 35. lateinit


private lateinit var repository: UserRepository

後から初期化する参照型では Nullable を避けられる。

 

🧑🏻‍💻 36. Delegates.notNull()


var count: Int by Delegates.notNull()

Int や Boolean など lateinit が使えない型向け。

 

🧑🏻‍💻 37. takeUnless()


val user = user.takeUnless { it.deleted } ?: return

条件を満たしたら除外したい場合に使う。

 

🧑🏻‍💻 38. firstNotNullOfOrNull()


val token = providers.firstNotNullOfOrNull {
    it.token
}

最初の Non-null を取得し、無ければ null を返す。

 

🧑🏻‍💻 39. Kotlin Contracts


@OptIn(ExperimentalContracts::class)
fun requireUser(user: User?) {
    contract {
        returns() implies (user != null)
    }
    requireNotNull(user)
}

独自関数でも Smart Cast を効かせられる。

 

🧑🏻‍💻 40. associateNotNull() パターン


val map = users
    .mapNotNull {
        it.id?.let { id -> id to it }
    }
    .toMap()

Map を作る途中で null を除外する。

 

🧑🏻‍💻 まとめ

「null」を未だに使ってるプロジェクト、実際現場では多いですよね。

「NullPointerExeption(ヌルポ)」の対応による開発時間の損失は、IT業界全体で年間数十兆円、個々の開発プロジェクトでも全体の数割の時間を奪うレベルの巨大なインパクトを持っています。


「View と State を分離する」は Compose 時代でも重要なのか?

Jetpack Compose が普及した今でも、「View と State を分離することは重要ですか?」という質問をよく見かけます。

結論から言うと、重要ではあるものの、設計の中心ではなくなりました。

Compose が登場したことで、私たちが考えるべきことは「View と State を分離すること」から、「State をどこに持つべきか」へと変わっています。

 

🤔 XML 時代は「View と State の分離」が重要だった

従来の Android View システムでは、View は変更可能なオブジェクトでした。

画面を更新するたびに、

- setText()
- setVisibility()
- notifyDataSetChanged()

のような API を呼び出して View を直接変更します。


State
   │
ViewModel
   │
View(XML)

View が多くの状態を抱えていたため、UI の更新処理とビジネスロジックを分離することが、保守性を高めるために非常に重要でした。

 

🤔 Compose は View 自体が状態を持たない

Compose では UI は関数です。


@Composable
fun UserScreen(state: UserState) {
    Text(state.name)
}

state が変われば、Compose が自動的に再コンポーズし、UI を描き直します。

開発者が View を直接更新することはほとんどありません。

つまり、


 State
   │
Composable
   │
  UI

という流れになり、「View をどう更新するか」を意識する場面は大幅に減りました。

その結果、「View と State を分離すること」自体の重要性は相対的に小さくなっています。

 

🤔 公式ドキュメントが強調しているのは State Hoisting

Compose の公式ドキュメントを見ると、「View と State の分離」ではなく State Hoisting が中心テーマになっています。

最初に紹介される原則がこちらです。

State は、それを利用する場所のできるだけ近くに置くべき

これは XML 時代の

「まず ViewModel に置こう」

という発想とは少し異なります。

例えば、1つの Composable だけが利用する状態なら、


var expanded by rememberSaveable {
    mutableStateOf(false)
}

のように Composable の中で保持することが推奨されています。

公式ドキュメントでも、

Keeping UI element state internal to composable functions is acceptable.

と明記されています。

 

🤔 ViewModel は「すべての State の置き場所」ではない

Compose の公式ドキュメントには、さらに興味深い説明があります。

The lowest common ancestor can also be outside of the Composition. For example, when hoisting state in a ViewModel because business logic is involved.

ここで重要なのは、

「ビジネスロジックが関係するから ViewModel に置く」

と説明していることです。

「画面の State はすべて ViewModel に置く」とは書かれていません。

さらに、公式は ViewModel を次のようにも説明しています。

A ViewModel is just an implementation detail of a state holder with certain responsibilities.

つまり ViewModel は、

State Holder の実装方法の一つ

という位置付けです。

もちろん、ViewModel は今でも重要なコンポーネントです。

しかし、Compose の世界では「唯一の State Holder」ではありません。

 

🤔 Compose では「State の寿命」を考える

Compose では State の種類ごとに、適切な置き場所があります。


UIだけで使うState
      │
  remember
      │
rememberSaveable
      │
 Navigation
      │
 ViewModel
      │
 Repository

それぞれ保持できる期間が異なります。

- remember は再コンポーズまで
- rememberSaveable は Configuration Changes や Process Death 後まで
- Navigation は画面遷移に関する状態
- ViewModel は画面のライフサイクルとビジネスロジック
- Repository はアプリ全体のデータ

Compose では、

「この State は ViewModel に置くべきか?」

ではなく、

「この State はどのくらい生き続けるべきか?」

という視点で考える方が自然です。

 

🤔 まとめ

Compose によって、「View と State を分離する」という考え方が間違いになったわけではありません。

ただし、Compose は UI 自体が宣言的になったため、その問題は以前ほど大きくなくなりました。

現在の Android アーキテクチャで重要なのは、

「State をどこに配置するか」

そして

「その State をどのライフサイクルまで保持するか」

です。

実際、Compose の公式ドキュメントも「View と State の分離」ではなく、「State Hoisting」や「State Ownership」を中心に説明しています。

ViewModel を使うことが目的ではなく、State に最適な寿命と責務を与えることが、Compose 時代の設計と言えるでしょう。

 

🤔 参考


Navigation 3 時代でも ViewModel は State Holder であるべきか?

Compose と Navigation 3 が変えた ViewModel の役割

長年、Android 開発では一つの考え方が当たり前とされてきました。

画面の状態(State)は ViewModel に持たせる。

これは単なるベストプラクティスではなく、Android アーキテクチャの基本原則の一つでした。

ViewModel は Configuration Changes(画面回転など)でも破棄されず、さらに SavedStateHandle を使えば Process Death 後の状態復元もできます。

そのおかげで Activity や Fragment は UI を表示することに専念でき、画面の状態はすべて ViewModel が管理する、という設計が一般的になりました。

しかしここ数年で、この考え方は少しずつ変わり始めています。

Compose も Navigation 3 も ViewModel を不要にしたわけではありません。

代わりに、それぞれが 「本来その State を持つべき場所」 を用意するようになりました。

そこで、こんな疑問が生まれます。

Navigation 3 の時代でも、ViewModel は State Holder であるべきなのでしょうか?

 

🤔 以前の ViewModel は画面の State をすべて抱えていた

Compose が登場する以前は、多くの ViewModel が画面に関するほぼすべての状態を保持していました。


ViewModel
├── UI State
│   ├── text
│   ├── scrollPosition
│   ├── selectedTab
│   └── dialogState
│
├── Navigation State
│   └── screen arguments
│
└── Presentation Logic

この構成には多くのメリットがありました。

- Configuration Changes に強い
- Process Death 後も状態を復元できる
- Activity / Fragment をシンプルに保てる
- UI とビジネスロジックを分離できる

そのため、新しい State が増えたら、

とりあえず ViewModel に置く

という設計が自然になっていました。

 

🤔 Compose は UI State を UI に戻した

Jetpack Compose は、この考え方を少し変えました。

すべての UI State を ViewModel に持たせる必要はなく、Composable 自身が State を持てるようになったのです。

例えば検索文字列なら、


var query by remember {
    mutableStateOf("")
}

だけで十分です。

さらに Configuration Changes や Process Death を越えて保持したいなら、


var query by rememberSaveable {
    mutableStateOf("")
}

を使えます。

例えば次のような State は、

- TextField の入力内容
- 選択中のタブ
- 展開状態
- ダイアログの表示状態
- スクロール位置

どれも 純粋な UI State です。

ビジネスロジックではありません。

そのため、実際に使っている Composable の中に置く方が責務も分かりやすくなります。

Compose はまず、

「UI State は UI が持つ」

という考え方を広めました。

 

🤔 Navigation 3 はさらに一歩進めた

Navigation 3 は、この流れをさらに推し進めています。

まず、画面引数を SavedStateHandle 経由で受け渡す必要がなくなりました。

各画面は自分専用の NavKey を持ちます。


data class UserDetail(
    val userId: Long
) : NavKey

さらに Navigation 3 では rememberSerializable が追加されました。

rememberSaveable が Android の保存・復元機構を利用するのに対し、

rememberSerializableNavEntry 単位 で UI State を保持します。

つまり、UI State は Navigation の Back Stack と一緒に移動するようになります。

画面ごとの State を ViewModel に保存する必要はなく、

各画面自身が UI State を持つ

という構造になります。

役割を整理すると次のようになります。


UI State
    │
rememberSerializable
    │
Composable


Navigation State
    │
NavKey


Presentation Logic
    │
ViewModel

UI State は UI のもの。

Navigation State は Navigation のもの。

どちらも、もう ViewModel が管理すべき State ではありません。

 

🤔 では ViewModel には何が残るのか?

UI State も Navigation State も ViewModel の役割ではなくなったとしたら、

ViewModel は何を担当するのでしょうか?

実は、やることはまだたくさんあります。


ViewModel
├── Repository の調整
├── ビジネスロジック
├── Flow の変換
├── Paging
├── Retry
└── viewModelScope

ここで面白いことがあります。

この中には、

State そのものはほとんどありません。

あるのは責務です。

ViewModel は

- Repository からデータを取得し
- ユーザー操作に応答し
- ビジネスロジックを実行し
- UI が描画しやすい形へ加工する

という役割を担います。

 

🤔 ViewModel は「State Holder」ではなく「State Producer」へ

例えば次のような ViewModel を考えてみます。


val uiState = combine(
    userRepository.users,
    settingsRepository.settings
) { users, settings ->
    HomeUiState(
        users = users,
        darkMode = settings.darkMode
    )
}.stateIn(...)

ここで実際の State はどこにあるでしょうか。

ViewModel ではありません。

データの正しい管理場所(Single Source of Truth)は Repository にあります。

ViewModel は、それらを UI 用に変換しているだけです。

つまり ViewModel は

State を保持する存在ではなく、State を生成する存在

になりつつあります。

一見小さな違いに思えますが、

Presentation Layer の考え方を大きく変える変化です。

 

🤔 State を持つ責任は、それぞれのレイヤーへ

Compose より前は、


ViewModel
├── UI State
├── Navigation State
└── Presentation Logic

という構成が一般的でした。

Navigation 3 では、


rememberSerializable
└── UI State

NavKey
└── Navigation State

ViewModel
└── Presentation Logic

へと役割が整理されます。

Compose は UI State を UI に戻しました。

Navigation 3 は Navigation State を NavKey に任せ、

UI State を NavEntry ごとに保持できるようにしました。

ViewModel が不要になったわけではありません。

責務がより明確になった のです。

 

🤔 よりシンプルなアーキテクチャ

その結果、アーキテクチャは次のように整理できます。


+----------------------+
|      Composable      |
|----------------------|
| UI State             |
| rememberSerializable |
+----------+-----------+
           |
           v
+----------------------+
|      ViewModel       |
|----------------------|
| Presentation Logic   |
| Flow Transformation  |
| Repository Calls     |
+----------+-----------+
           |
           v
+----------------------+
|      Repository      |
|----------------------|
| Persistent Data      |
| DataStore / Database |
+----------------------+

各レイヤーが、それぞれ最も適した責務を持ちます。

- Composable は UI State
- NavKey は Navigation State
- Repository は永続データ
- ViewModel は Presentation Logic

責務が自然に分離された構造です。

 

🧑🏻‍💻 まとめ

Navigation 3 が登場しても、ViewModel が不要になるわけではありません。

ViewModel はこれまでどおり、

- ビジネスロジック
- Repository の調整
- Flow の変換
- Paging
- 長時間動作する Coroutine

などを担当する最適な場所です。

一方で、Compose は rememberSaveable を導入し、UI State を UI に持たせやすくしました。

さらに Navigation 3 は rememberSerializable を追加し、UI State を NavEntry ごとに保持できるようにしました。また、Navigation State は NavKey が担当します。

その結果、「とりあえず ViewModel に State を置く」という設計は、必ずしも最適ではなくなりました。

これからは、

この State を ViewModel に保存するにはどうすればいいか?

ではなく、

そもそも、この State は ViewModel が持つべきものなのか?

と考える方が自然でしょう。

ViewModel は今でも欠かせない存在です。

しかし Navigation 3 の時代における主な役割は、State Holder ではなく Presentation Logic を担うことへと変化しつつあります。

なお、UI State を ViewModel の外へ移したからといって、Configuration Changes や Process Death に弱くなるわけではありません。

- UI State は rememberSaveablerememberSerializable
- Navigation State は NavKey
- 永続データは Repository

というように、それぞれのレイヤーが適切な仕組みを使えば、Configuration Changes と Process Death の両方に対応した堅牢なアプリケーションを構築できます。

重要なのは State を保存することではなく、

「その State を最も自然に所有すべきレイヤーが管理すること」なのです。

 

🧑🏻‍💻 参考


Navigation 3 の Navigation Graph パターンまとめ

 

🤔 Navigation Graph はもう navigation() だけじゃない

Jetpack Compose 向けの Navigation 3 では、従来の Navigation Component にあった navigation() を使ったネストした Navigation Graph の考え方がなくなりました。

その代わりに、「コードをどう整理するか」と「BackStack をどう分けるか」を分離して考える設計になっています。

この記事では、Navigation 3 でよく使われる 3 つの Navigation Graph パターンを紹介します。

 

🤔 Navigation 3 の3つのパターン


Navigation 3
│
├─ コードを整理したい
│   ├─ Extension Functions
│   └─ Sealed NavKeys
│
└─ BackStack を分けたい
    └─ Nested NavDisplay

ポイントは、

- コードを整理する方法
- BackStack を分離する方法

は別の話だということです。

 

🤔 Extension Functions で画面を機能ごとに分割する

Navigation 3 では entry() を並べて画面を登録します。

画面数が増えてくると、1つのファイルに全部書くのは見づらくなります。

そんなときは Extension Function へ切り出すのが最もシンプルです。


// AuthModule.kt
fun EntryProviderScope<NavKey>.authGraph() {
    entry<Login> {
        LoginScreen()
    }

    entry<SignUp> {
        SignUpScreen()
    }
}

メイン側では呼び出すだけです。


val entryProvider = entryProvider {
    authGraph()

    entry<Home> {
        HomeScreen()
    }
}

NavDisplay(
    backStack = backStack,
    entryProvider = entryProvider
)

これだけで認証画面を別ファイルへ分離できます。

メリット
- Feature 単位で管理できる
- モジュール分割しやすい
- BackStack は1つなので構成はシンプル

 

🤔 Sealed NavKey で画面をグループ化する

もう1つの整理方法が NavKey をグループ化する 方法です。


sealed interface AuthKey : NavKey {

    @Serializable
    data object Login : AuthKey

    @Serializable
    data object SignUp : AuthKey
}

sealed interface MainKey : NavKey {

    @Serializable
    data object Home : MainKey

    @Serializable
    data class Detail(
        val id: String
    ) : MainKey
}

画面遷移も名前空間付きで分かりやすくなります。

Navigation 3 では Graph は存在しませんが、

- Auth 系
- Main 系
- Settings 系

のように論理的に整理できます。

メリット
- 名前空間が分かりやすい
- 型安全
- Destination が探しやすい

 

🤔 NavDisplay をネストする

ここだけは少し意味が変わります。

これはコード整理ではなく BackStack を分離する方法です。

例えば

- Bottom Navigation
- タブ
- Onboarding
- 独立したフロー

では、それぞれ独自の履歴を持たせたいことがあります。

その場合は NavDisplay をネストします。


entry<MainTabs> {
    MainTabsScreen()
}


@Composable
fun MainTabsScreen() {

    val tabBackStack =
        rememberNavBackStack(HomeTab)

    NavDisplay(
        backStack = tabBackStack,
        entryProvider = entryProvider {

            entry<HomeTab> {
                HomeScreen()
            }

            entry<SearchTab> {
                SearchScreen()
            }

            entry<ProfileTab> {
                ProfileScreen()
            }
        }
    )
}

ここでは親とは別の NavBackStack を持っています。


Root 
NavDisplay
    │
    └── MainTabs
             │
             └── NavDisplay
                     │
                     ├── Home
                     ├── Search
                     └── Profile

つまり、

NavDisplay = NavBackStack の管理単位

という考え方になります。

Bottom Navigation で各タブの履歴を保持できるのも、この仕組みによるものです。

 

🤔 どれを選べばいい?

次のように考えると分かりやすいでしょう。


画面を整理したい?
│
├─ Yes
│   ├─ Extension Functions
│   └─ Sealed NavKeys
│
└─ BackStack を分けたい?
    └─ Nested NavDisplay

 

🤔 まとめ

Navigation 3 では、従来の navigation() による Graph のネストはありません。

その代わりに、

- Extension Functions で entry() を機能ごとに分割する
- Sealed NavKey で Destination を整理する
- Nested NavDisplay で独立した NavBackStack を持つ

という3つのパターンを組み合わせて設計します。

特に重要なのは、コードの整理と BackStack の分離は別の概念という点です。

Navigation 3 は Graph をネストするライブラリではなく、NavDisplay と NavBackStack を組み合わせてナビゲーション構造を組み立てるライブラリへと進化しています。

 

🤔 参考


Navigation 3 時代の「二重遷移」を防ぐ正しい方法 - dropUnlessResumed は debounce ではない

Android アプリでボタンを素早く連打すると、同じ画面が何度も積み重なってしまうことがあります。


Home
  ↓
Detail
  ↓
Detail
  ↓
Detail

この問題を防ぐために debouncethrottle を使うケースは少なくありません。

しかし、Navigation 3 が提供する dropUnlessResumed は考え方がまったく異なります。

これは「一定時間タップを無視する」のではなく、画面が遷移できる状態かどうかを見てイベントを受け付ける API です。

 

🤔 debounce との違い

一見すると似ていますが、見ているものが違います。

つまり、


debounce
    ↓
「まだ500ms経ってないから無視」

dropUnlessResumed
    ↓
「この画面はもう操作できないから無視」

という違いがあります。

 

🤔 Navigationでは「時間」より「状態」が重要

画面遷移が始まると、現在の画面はすぐに RESUMED ではなくなります。


RESUMED
    │
ボタン押下
    │
navigate()
    │
STARTED
    │
STOPPED

この間にもう一度クリックされても、


dropUnlessResumed {
    navController.navigate(...)
}

であれば実行されません。

つまり、


クリック1回目
    ↓
navigate()

クリック2回目
    ↓
画面はもう RESUMED じゃない
    ↓
無視

となります。

 

🤔 なぜ debounce より自然なのか

例えば画面遷移アニメーションが長くなったとします。

debounce は

500ms待つ

という固定時間なので、

- アニメーションが300ms
- アニメーションが700ms

どちらにも最適とは限りません。

一方 dropUnlessResumed


画面が操作可能
      ↓
受け付ける

画面遷移中
      ↓
受け付けない

戻ってきた
      ↓
再び受け付ける

と、Lifecycle に合わせて自動的に動作します。

 

🤔 内部では何をしているの?

実装は驚くほどシンプルです。

概念的には次のような処理です。


if (lifecycle.currentState == Lifecycle.State.RESUMED) {
    block()
}

つまり、

- 現在の Lifecycle を確認する
- RESUMED のときだけラムダを実行する

それだけです。

タイマーも、Coroutine も、待ち時間もありません。

 

🤔 Navigation 3 での使い方

Compose ではクリックイベントをそのまま包むだけです。


val onClick = dropUnlessResumed {
    navController.navigate(Detail)
}

Button(
    onClick = onClick
) {
    Text("Open")
}

これだけで、

- 二重 Push
- 二重画面生成
- 連打による BackStack の重複

を簡単に防げます。

 

🤔 debounce を使うべき場面

もちろん debounce が不要になったわけではありません。

例えば

- 検索ボックス
- API リクエスト
- テキスト入力
- リアルタイム検索

のように「連続イベントを間引く」目的なら debounce が適しています。

一方、

- Navigation
- Dialog を開く
- BottomSheet を表示する

など Lifecycle に依存する UI 操作では dropUnlessResumed の方が自然です。

 

🤔 まとめ

dropUnlessResumeddebounce の代替ではありません。

見る対象が時間ではなく Lifecycle だからです。

Navigation では「今この画面は操作可能か」が最も重要になります。

そのため Navigation 3 では、時間ベースの制御ではなく Lifecycle ベースの制御で二重遷移を防ぐ設計になっています。

一度仕組みを理解すると、「なぜ Navigation 用に専用 API が用意されているのか」がよく分かるはずです。

 

🤔 参考