Hiltのナビゲーション引数で SavedStateHandle から卒業する

なぜ Hilt 2.49+ と @AssistedInject が、完全な型安全性を備えた引数渡しの「正解」と言えるのか。

 

🤔 問題点:静的な依存関係と動的なデータの混在

Android開発において、ViewModelにランタイム引数(実行時引数)を注入することは、常に議論の的となってきました。

その本質は、「静的依存関係」(DIによって管理されるリポジトリなど)と、「動的データ」(画面遷移時に渡されるナビゲーション引数など)の対立にあります。

適切なDIパターンを適用せずにこの問題に対処しようとすると、高確率でアンチパターンに陥ります。たとえば、一時的な状態をシングルトン(Singleton)内に保持してしまうと、状態の汚染や画面間でのデータ漏洩といった致命的なバグを引き起こす危険性があります。

 

🤔 解決策:ハイブリッド注入を実現する @AssistedInject

この「静的」と「動的」のギャップを埋めるための最適なツールが、@AssistedInject です。これを使用することで、DI(Hilt)が管理するオブジェクトと、実行時に受け取るランタイムパラメータをスマートに組み合わせた「ハイブリッド注入」が可能になります。

通常の @Inject は不要 :
@AssistedInject を使用する場合、コンストラクタに通常の @Inject を付ける必要はありません(というか、付けてはいけません)。

関心の分離 :
リポジトリなどの依存関係は Hilt が自動で供給し、ナビゲーション引数などの動的なデータだけを手動で安全に渡す、という明確な役割分担(関心の分離)が実現します。

クリーンなコードへ :
これにより、バグの温床になりがちだった危険な lateinit var による後からの初期化コードとは、完全におさらばできます。


// ViewModel 実装

@HiltViewModel(assistedFactory = RouteBViewModel.Factory::class) 
class  RouteBViewModel  @AssistedInject constructor( 
    private val repository: MyRepository,
    @Assisted val navKey: RouteB,
) : ViewModel() { 

    @AssistedFactory
    interface Factory { 
        fun create (navKey: RouteB) : RouteBViewModel 
    } 
}

 

🤔 実装:assistedFactory と hiltViewModel の組み合わせ

公式の nav3-recipes リポジトリでは、Hilt 2.49 以降で導入された最新の標準的な実装パターンが示されています。

ファクトリの宣言 :
@HiltViewModel(assistedFactory = ...) を使用して、Assisted Factory を ViewModel に直接リンクさせます。

2つの型パラメータ: Compose 側では、hiltViewModel() のように両方の型を明示的に指定して呼び出します。

安全なライフサイクル管理 :
creationCallback を利用することで、ナビゲーションのバックスタック管理(Lifecycle)を壊すことなく、安全にランタイム引数を渡すことができます。


// UI(ナビゲーション定義)

 entry<RouteB> { key -> 
    val viewModel = hiltViewModel<RouteBViewModel, RouteBViewModel.Factory>( 
        creationCallback = { factory -> 
            factory.create(key) 
        } 
    ) 
    ScreenB(viewModel = viewModel) 
}

 

🤔 メリット:100%の型安全性を実現し、SavedStateHandle のボイラープレートを完全に排除

このアーキテクチャ(Navigation 3 + @AssistedInject)に移行することで、コードベースの品質は大幅に向上します。

完全な型安全性(100% Type-Safe):
かつての文字列ベースのキー(string のキー指定)は過去のものです。ナビゲーション引数は、Route(Serializable等で定義された型)として、厳密に型指定されたオブジェクトのまま直接安全に渡されます。

SavedStateHandle からの解放 :
単に次の画面へ引数を渡すだけのために、SavedStateHandle を使ってごにょごにょと値を書き出したり読み出したりする定型文(ボイラープレート)はもう一切不要になります。

圧倒的なリファクタリングのしやすさ :
すべてがコンパイル時にチェックされるため、引数の追加・削除・変更といったリファクタリングが、一瞬かつ確実に(ランタイムエラーの心配なく)行えるようになります。

 

🤔 まとめ

Hilt と最新の Jetpack Navigation の相乗効果により、画面間の引数の受け渡しは驚くほどスムーズかつ洗練されたものになりました。もはや、型安全性を犠牲にしたり、不自然なアーキテクチャで回避策(ワークアラウンド)を講じたりする必要はありません。

@AssistedInject と、進化した hiltViewModel() API を組み合わせることで、「完璧な型安全性」と「クリーンなハイブリッド依存性注入(DI)」を今すぐあなたのプロジェクトに導入できます。


【Jetpack Compose Navigation3】EntryDecorator と ViewModel の「key」の深い関係

Jetpack Compose の Navigation3 では、画面遷移の引数として RouteB(val id: String) のようなデータクラスを渡します。

このとき、同じ RouteB でも id が違えば「別の画面(別の ViewModel)」として扱いたいですよね。

ここで重要になるのが EntryDecoratorviewModel(key = ...) の関係です。

 

🤔 結論:Decorator が「鍵」を管理してくれるか否か

一言でいうと、こうなります。

Decorator を使わない場合:
手動で viewModel(key = "unique_id") を指定する必要がある。

Decorator を使えば:
viewModel() の引数は不要。
Decorator が自動で各エントリに個別の ViewModelStore を割り当ててくれる。

 

🤔 1. Decorator を使わないパターン(手動管理)

Navigation3 の基本機能 NavDisplay を使う場合、ViewModel の生存期間はデフォルトの「Activity 全体」に紐づきます。

同じ RouteB でも id ごとに ViewModel を作り分けたい場合、以下のように手動で key を渡して、内部のキャッシュを分ける必要があります。


entry<RouteB> { key ->
    // key(RouteBのインスタンス)の id を使って、ViewModelを区別する
    val vm = viewModel(
        key = key.id, // ← これが必要!
        factory = RouteBViewModel.Factory(key)
    )
    ScreenB(vm)
}

これを忘れると、id = "1" の画面から id = "2" の画面へ遷移しても、同じ ViewModel インスタンスが使い回されてしまい、表示内容が更新されない というバグに繋がります。

 

🤔 2. Decorator を使うパターン(Navigation3 の推奨)

サンプルの BasicViewModelsActivity で採用されている方法です。

NavDisplay の設定に rememberViewModelStoreNavEntryDecorator() を追加します。


NavDisplay(
    backStack = backStack,
    entryDecorators = listOf(
        rememberSaveableStateHolderNavEntryDecorator(),
        rememberViewModelStoreNavEntryDecorator() // ← これが魔法のスパイス
    ),
    entryProvider = entryProvider {
        entry<RouteB> { key ->
            // key 指定が不要になる!
            val vm = viewModel(factory = RouteBViewModel.Factory(key))
            ScreenB(vm)
        }
    }
)

なぜ key が不要になるのか?

ViewModelStoreNavEntryDecorator は、バックスタックにある 「各エントリ(NavEntry)」ごとに独立した ViewModelStore を生成してくれます。

RouteB("1") のエントリ ➔ 専用の ViewModelStore A が用意される

RouteB("2") のエントリ ➔ 専用の ViewModelStore B が用意される

viewModel() 関数は、その時点の LocalViewModelStoreOwner(Decorator が提供するエントリごとのストア)を参照します。そのため、わざわざ key を指定しなくても、エントリが違えば自動的に別の ViewModel が作られる仕組みです。

 

🤔 まとめ:どっちを使うべき?

基本的には「Decorator を使う」のが正解です。

理由1:
コードがシンプルになる(key の指定漏れがなくなる)。

理由2:
画面を戻ったときに ViewModel が正しく破棄されるなど、ライフサイクル管理が Navigation3 のエントリと完全に同期する。

「この画面だけは特殊な管理をしたい」という場合を除き、rememberViewModelStoreNavEntryDecorator() をセットアップして、型安全な key をそのまま Factory に渡すスタイルを基本にしましょう。


「process death」とは何?

Androidにおける Process Death (プロセス終了) とは、システムがメモリ不足(Memory Pressure)になった際に、バックグラウンドにあるアプリのプロセスを OS が強制的に終了させる仕組みのことです。

ユーザーがアプリを閉じたり明示的に終了させたりする「通常の終了」とは異なり、OS側の都合で実行されるため、適切な対策をしないとアプリに戻った際にデータが消えてしまう原因になります。

 

🤔 なぜ気ににする必要があるのか

長いお問い合わせフォームを入力中に、少し調べ物をして戻ったら全部消えていた。

ECサイトで商品を比較していたのに、トップ画面に戻された。

「このアプリは不安定だ」「使いにくい」と思われ、アンインストールや低評価に直結します。

 

🤔 予期せぬクラッシュを防ぐため

Process Death からの復帰時、OSは「最後に開いていた画面」をいきなり表示しようとします。

もし、その画面が 「前の画面から渡されたデータ(IDなど)」 に依存しているのに、それをメモリ上の変数(ViewModelのフィールドなど)にしか持っていなかった場合、復帰した瞬間にデータが null や空になり、アプリがクラッシュします。

 

🤔 「バックグラウンド=一時停止」ではない

Androidの設計思想では、アプリがバックグラウンドに回った瞬間から、いつ消されても文句は言えないことになっています。

「メモリが潤沢にあるから大丈夫だろう」という想定は、現代のAndroid(特にバックグラウンドで動くサービスや重いゲームが多い環境)では通用しません。

「プロセスは必ずいつか死ぬ」という前提で設計することが、Android開発におけるプロフェッショナルな作法とされています。

 

🤔 開発時の確認方法

以下で開発時に確認しておくのがいいです。


1. アプリを起動したあと、ホーム画面に移動する。(終了させるのではなくて、バックグラウンドに移動する)

2. adb shell am kill <アプリのパッケージ名>

3. アプリの起動履歴から再度アプリを選択する。

注意: am force-stop とは異なり、am kill はバックグラウンドにいるアプリに対して「メモリが足りなくなったからシステムが回収した」という状態をシミュレートします。

起動履歴から再度アプリを起動したときに、バックグラウンドに移動する前の画面と同じものが表示されれば OK です。

 

🤔 まとめ

上記手順でやってみました。

これでOK!!


Mac Book の 日本語 JIS キーボードを 英語 US キーボードになるべく違和感なく変える方法

日本語 JIS キーボードが馴染めない場合とか

ストレスすぎますよね。

逆もしかり。

様々なキーボードマッピングカスタマイズアプリなどありますが、

強引にレイアウトを変更したとて、

そもそもキーそれぞれ一つ一つのサイズが違う。

この方法がベストだと思われます。

 

🧑🏻‍💻 Magic Keyboard を手に入れる

少し高いですが。

👉 Magic Keyboard - 英語(US) - Apple(日本)

これを買うなりして手に入れるのが一番操作感は一番近いです。

日本語 JIS と 英語 US。

指紋センサー付きとなし。

Mac Bookのキーボード。

すべてサイズ同じです。

上に乗せればそれが一番良い感じです。

以上です。

知らなかったわ。


Jetpack Compose Navigation 3: ViewModel の生存期間を NavEntry 単位に変更する

Jetpack Navigation 3は、従来の Navigation Component と比較して非常にシンプルで「Action based」な設計になっています。しかし、デフォルト設定のまま ViewModel を利用すると、その生存期間に驚くかもしれません。

今回は、rememberViewModelStoreNavEntryDecorator() を使って NavEntry(画面)の破棄と同時に ViewModel をクリアする設定 について解説します。

 

🧑🏻‍💻 ViewModel のオーナーと生存期間

Nav3 で viewModel() を呼び出した際、そのオーナー(ViewModelStoreOwner)がどこにあるかを確認することは非常に重要です。

デフォルトの挙動:Activity スコープ

特に設定を行わない場合、ViewModel のオーナーは Activity (または Fragment) になります。

現状:
スクリーンが NavBackStack から消えても、ViewModel は破棄されません。

影響:
1 Activity で構成されたフル Jetpack Compose アプリの場合、一度生成された ViewModel はアプリが終了するまでメモリ上に生き続けます。

これは、画面を戻る(Pop back)たびに状態をリセットしたい場合には不都合な挙動となります。

 

🧑🏻‍💻 entryDecorators に ememberViewModelStoreNavEntryDecorator() を追加する

画面(NavEntry)ごとに独立した ViewModelStore を持たせるためのデコレータです。これを利用することで、NavEntry がスタックに積まれている間だけ ViewModel が生存するようになります。

設定方法:entryDecorators への追加

NavDisplay を呼び出す際、entryDecorators 引数にこのデコレータを渡します。


val backStack = rememberNavBackStack(initialBackStack)

NavDisplay(
    backStack = backStack,
    entryDecorators = listOf(
        rememberSaveableStateHolderNavEntryDecorator(),

        // これを追加することで NavEntry 単位の ViewModel スコープが有効になる
        rememberViewModelStoreNavEntryDecorator()
    )
) { entry ->
    // 各画面の Composable 呼び出し
    when (val key = entry.contentKey) {
        is ScreenA -> ScreenAContent()
        is ScreenB -> ScreenBContent()
    }
}

ViewModel の生存期間はどう変わるのか?

このデコレータを適用すると、内部的な構造は以下のように変化します。

適用前:
全ての NavEntry が Activity の ViewModelStore を参照。

適用後:
各 NavEntry が個別の ViewModelStore を保持。

これにより、NavBackStack から特定の NavEntry が取り除かれた(Pop された)タイミングで、紐づく ViewModelStore が clear() され、ViewModel も正しく破棄されるようになります。

 

🧑🏻‍💻 まとめ

Jetpack Navigation 3 で ViewModel を適切に管理するためのポイントは以下の通りです。

1. デフォルトでは Activity スコープ になり、画面を閉じても ViewModel は生き続ける。

2. rememberViewModelStoreNavEntryDecorator() を NavDisplay の entryDecorators に追加する。

3. これにより、Screen(NavEntry)の生存期間 = ViewModel の生存期間 となり、メモリ効率と状態管理の健全性が向上する。

Navigation 3 において、この設定は現代的な Android アプリ開発のスタンダードな構成と言えるでしょう。