composable()：NavHostとJetpack Composeにおけるルーティングの解説

NavHostにおけるcomposable()とは

composable() はNavHostオブジェクトの拡張関数です。Kotlin DSLでは、NavHostブロック内でこれを呼び出して、アプリケーションのすべての画面を宣言的に記述できます。各呼び出しはナビゲーショングラフにエントリを作成し、文字列ルートをcomposable関数にリンクします。ユーザーが特定のルートに移動すると、NavHostは前の画面を非表示にして、対応するcomposableを現在の画面として表示します。

Navigation Compose ライブラリは、Googleが2021年にJetpack Compose向けのFragmentベースのナビゲーションに代わるものとして発表しました。主な利点はComposeパラダイムとの完全な互換性です：composable()はFragmentManagerやトランザクションを必要とせず、他のComposeコンポーネントと同じライフサイクルで動作します。これにより、FragmentとComposeのライフサイクルの不一致に関連するバグのクラスが排除されます。

各composable()は、文字列ルートと、NavBackStackEntryオブジェクトを受け取りComposable UIを返すラムダ関数を受け取ります。ラムダ内では、スコープからnavControllerを介してNavControllerにアクセスでき、他の画面へのナビゲーションが可能です。このアーキテクチャにより、ナビゲーションが明示的で予測可能になります。

@Composable
fun AppNavigation() {
    val navController = rememberNavController()
    
    NavHost(
        navController = navController,
        startDestination = "home"
    ) {
        composable("home") {
            HomeScreen(
                onNavigateToProfile = {
                    navController.navigate("profile")
                }
            )
        }
        composable("profile") {
            ProfileScreen(
                onBack = { navController.popBackStack() }
            )
        }
    }
}

composable()の仕組み：キーとパラメータ

composable() への各呼び出しは、NavHostの内部グラフに一意のルート識別子を持つ頂点を作成します。NavControllerがnavigate()を実行すると、ライブラリは要求されたルートを登録済みのすべてのcomposable頂点と比較し、一致するものを見つけます。一致後、NavBackStackEntryが作成され、ナビゲーションスタックに配置され、UIコンポジションが開始されます。

composable()の内部実装は遅延初期化メカニズムを使用しています：画面のコンポジションは、そのルートへの最初のナビゲーション時にのみ発生します。つまり、ユーザーが移動したことのない画面はメモリを占有せず、コードも実行しません。このアプローチは、多くの画面を持つアプリケーションのパフォーマンスを大幅に向上させます。

composable()のkeyパラメータを使用すると、画面の再作成を管理できます。デフォルトでは、同じルートへの繰り返しのナビゲーション時にcomposableは再作成されません — NavHostは既存のバックスタックエントリを使用します。ただし、keyが渡されて変更された場合、NavHostはcomposable関数の新しいインスタンスを作成します。これは、再開時に状態を強制的に更新する必要がある動的データを持つ画面に便利です。

val NavGraphBuilder.Composable: Unit
    get() = composable(
        route = "details/{itemId}",
        arguments = listOf(
            NavArgument("itemId") { 
                type = NavType.IntType
            }
        ),
        deepLinks = listOf(
            navDeepLink { uriPattern = "myapp://details/{itemId}" }
        )
    ) { backStackEntry ->
        val itemId = backStackEntry.arguments?.getInt("itemId") ?: 0
        DetailsScreen(itemId = itemId)
    }

composable()経由の引数渡し

composable() はargumentsパラメータを通じて柔軟な引数システムをサポートしています。各引数は、型、デフォルト値、必須かどうかを定義するNavArgumentオブジェクトによって記述されます。引数はルート内でパスパラメータ（中括弧経由）またはクエリパラメータ（疑問符経由）として渡されます。

パスパラメータはルートテンプレートに直接指定されます："profile/{userId}"。"profile/42"に移動すると、NavHostは自動的に値42を抽出し、backStackEntry.argumentsを介してアクセス可能にします。クエリパラメータは疑問符の後に追加されます："search?query={text}" で、ライブラリによって自動的に解析されます。

引数を抽出する際には、NavType.isNullableAllowedを使用してパラメータの必須を確認し、NavArgument defaultValueを介してデフォルト値を提供することが重要です。必須パラメータが欠落している場合、Navigation ComposeはIllegalArgumentExceptionをスローし、誤ったルートによる微妙なバグを防ぎます。

複雑なオブジェクトを渡すには、NavType.ParcelableTypeまたはNavType.SerializableTypeを使用することをお勧めします。ただし、Googleは転送データのサイズを最小限にするようアドバイスしています — 識別子を渡して、画面内でIDによってオブジェクトをロードする方が良いでしょう。これにより、大きなシリアル化データの問題を防ぎ、設定変更の処理を簡素化できます。

data class Profile(val id: Int, val name: String) : Parcelable

            // 最小限のデータでナビゲート
navController.navigate("profile/42")

            // 画面上で引数を取得
composable(
    route = "profile/{userId}",
    arguments = listOf(
        NavArgument("userId") { type = NavType.IntType }
    )
) { backStackEntry ->
    val userId = backStackEntry.arguments?.getInt("userId") ?: 0
    ProfileDetailScreen(userId = userId)
}

composable()を使ったネストされたナビゲーション

実際のアプリケーションでは、ネストされたナビゲーショングラフを整理する必要がよくあります — たとえば、BottomNavigationタブ内の独立した画面スタックなどです。composable() はネストされたNavHostを通じてネストをサポートします：composable画面内で、独立したルートスタックを持つ独自のNavHostを宣言できます。

各ネストされたNavHostは、独自のNavControllerとバックスタックを持ちます。つまり、あるタブ内のナビゲーションは他のタブのナビゲーションに影響しません — ユーザーは各タブ内のナビゲーション履歴を失うことなく、タブ間を自由に切り替えることができます。このアーキテクチャはスコープドナビゲーションと呼ばれ、複雑なマルチレベルナビゲーションを持つアプリケーションにGoogleが推奨しています。

ネストされたナビゲーションを実装する際は、NavControllerの状態を正しく管理することが重要です：各ネストされたNavHostは、composable関数のスコープ内に独自のrememberNavControllerを保存する必要があります。Android Developer Summit 2024によると、3つ以上のタブを持つJetpack Composeアプリケーションの40%以上が、モジュール間のナビゲーションを分離するためにネストされたNavHostアーキテクチャを使用しています。

// タブ付きメインNavHost
composable("tabs") {
    MainTabsScreen { tab ->
        when (tab) {
            Tab.Home -> HomeNavGraph()
            Tab.Search -> SearchNavGraph()
        }
    }
}

// ホームタブ内のネストされたグラフ
@Composable
fun HomeNavGraph() {
    val navController = rememberNavController()
    NavHost(
        navController = navController,
        startDestination = "home_feed"
    ) {
        composable("home_feed") { FeedScreen() }
        composable("home_detail/{postId}") { PostDetailScreen() }
    }
}

composable() vs Intentナビゲーション

Jetpack Compose以前は、Androidでの標準的なナビゲーション方法はIntentとFragmentManagerを使用していました。Intent は新しいActivityを起動するシステムメッセージで、Viewツリー全体の再作成を意味します。対照的に、composable()は単一のActivity内で動作し、Composeツリーの一部を単純に置き換えるため、大幅に高速でメモリ効率に優れています。

composable()とIntentベースのナビゲーションの主な違い：

• 速度 — composable()はActivityを再作成せずにミリ秒単位で画面を切り替えます。IntentはActivityの再起動が必要です。
• アニメーション — Navigation Composeでは、トランジションアニメーションはoverridePendingTransitionを必要とせず、AnimatedNavHostを介して宣言的に定義されます。
• 共有状態 — composable()は共有ViewModelスコープで動作し、Intent extrasなしでの画面間のデータ転送を簡素化します。

Intentからcomposable()への移行は、単なるAPIの置き換えではなく、アーキテクチャパラダイムの変更です。どのActivityを開くべきかを明示的に指定する代わりに、開発者はすべての可能なルートを一箇所で宣言的に記述するため、コードの可読性が向上し、ナビゲーションテストが簡素化されます。Google I/O 2024によると、Navigation Composeを備えたJetpack Composeは、FragmentManagerと比較してナビゲーションコードを40〜60%削減します。

composable()のよくある間違い

最も一般的な間違いの1つは、再コンポジション中のNavControllerの再作成です。状態の変更に伴って再作成される可能性のある親composableレベルでrememberNavController()を介してNavControllerが作成された場合、ナビゲーションが壊れます — 履歴が失われます。正しい解決策は、NavControllerを安定したcomposableレベル（Activityレベルやアプリケーションのルートcomposableなど）に引き上げることです。

2つ目の一般的な問題は、ナビゲーション中の無限再コンポジションです。これは、navController.navigate()がcomposable関数の本体に直接配置された場合に発生します。ナビゲーションがNavHostの状態を変更するため、再コンポジションがトリガーされ、再びnavigate()が呼び出され、ループが発生します。すべてのナビゲーション呼び出しは、ラムダハンドラー（onClick、onButtonPressed）にラップされ、コンポジション内で実行されるべきではありません。

3つ目の間違いは、BottomNavigation使用時の誤ったバックスタック処理です。各タブ切り替え時にnavigate()を介した単純なナビゲーションは、既存のエントリに戻る代わりに、スタックに新しいエントリを追加します。BottomNavigationの場合は、restoreState = trueおよびlaunchSingleTop = trueを指定したnavController.navigate()を使用する必要があります。これにより、タブ切り替え時の状態の正しい復元が保証されます。

fun NavController.navigateToTab(route: String) {
    navigate(route) {
        popUpTo(navController.graph.findStartDestination().id) {
            saveState = true
        }
        launchSingleTop = true
        restoreState = true
    }
}