composable(): ما هي، NavHost والتوجيه في Jetpack Compose

ما هو composable() في NavHost

composable() هي دالة امتداد لكائن NavHost. تسمح Kotlin DSL باستدعائها داخل كتلة NavHost لوصف جميع شاشات التطبيق بشكل تصريحي. كل استدعاء يُنشئ مدخلاً في الرسم البياني للتنقل، رابطًا مسارًا نصيًا بدالة composable. عندما ينتقل المستخدم إلى مسار معين، يعرض NavHost composable المقابل كالشاشة الحالية، مخفيًا الشاشة السابقة.

مكتبة Navigation Compose قدمتها Google في 2021 كبديل للتنقل المستند إلى Fragment لـ Jetpack Compose. الميزة الرئيسية هي التوافق الكامل مع نموذج Compose: تعمل composable() في نفس دورة حياة مكونات Compose الأخرى، دون الحاجة إلى FragmentManager أو المعاملات. هذا يلغي فئة من الأخطاء المتعلقة بعدم تطابق دورة حياة Fragment و Compose.

تأخذ كل composable() مسارًا نصيًا ودالة lambda تستلم كائن NavBackStackEntry وتعيد UI قابلة للتركيب. داخل lambda، يمكن الوصول إلى 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() آلية التهيئة البطيئة: يحدث تركيب الشاشة فقط عند التنقل الأول إلى ذلك المسار. هذا يعني أن الشاشات التي لم ينتقل إليها المستخدم أبدًا لا تشغل الذاكرة ولا تنفذ أي كود. هذا النهج يحسن الأداء بشكل كبير في التطبيقات التي تحتوي على العديد من الشاشات.

تسمح معلمة key في composable() بإدارة إعادة إنشاء الشاشة. افتراضيًا، لا يُعاد إنشاء 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 بتقليل حجم البيانات المنقولة — من الأفضل تمرير معرف وتحميل الكائن بواسطة المعرف داخل الشاشة. هذا يمنع المشاكل مع البيانات المسلسلة الكبيرة ويبسط معالجة تغييرات التكوين.

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 ومكدس عودة خاص بها. هذا يعني أن التنقل داخل علامة تبويب لا يؤثر على التنقل في علامات التبويب الأخرى — يمكن للمستخدم التبديل بحرية بين علامات التبويب دون فقدان تاريخ التنقل داخل كل منها. هذه البنية تسمى Scoped Navigation وتوصي بها Google للتطبيقات ذات التنقل المعقد متعدد المستويات.

عند تنفيذ التنقل المتداخل، من المهم إدارة حالة NavController بشكل صحيح: يجب أن تخزن كل NavHost متداخلة rememberNavController الخاص بها داخل نطاق دالة composable. وفقًا لـ Android Developer Summit 2024، أكثر من 40% من تطبيقات Jetpack Compose ذات ثلاث علامات تبويب أو أكثر تستخدم بنية 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() مع التنقل بواسطة Intent

قبل Jetpack Compose، كانت الطريقة القياسية للتنقل في Android تستخدم Intent و FragmentManager. Intent هي رسالة نظام تُطلق Activity جديدة، مما يعني إعادة إنشاء شجرة View بأكملها. على النقيض من ذلك، تعمل composable() داخل Activity واحد وتستبدل ببساطة جزءًا من شجرة Compose، وهو أسرع بكثير وأكثر كفاءة في استخدام الذاكرة.

الاختلافات الرئيسية بين composable() والتنقل المستند إلى Intent:

• السرعة — composable() تبدل الشاشات بالمللي ثانية دون إعادة إنشاء Activity؛ Intent يتطلب إعادة تشغيل Activity.
• الرسوم المتحركة — في Navigation Compose، تُحدد رسوم الانتقال بشكل تصريحي عبر AnimatedNavHost، دون الحاجة إلى overridePendingTransition.
• الحالة المشتركة — تعمل composable() في نطاق ViewModel مشترك، مما يبسط نقل البيانات بين الشاشات دون Intent extras.

الانتقال من Intent إلى composable() ليس مجرد استبدال API، بل تغيير في النموذج المعماري. بدلاً من تحديد أي Activity يجب فتحها بشكل صريح، يصف المطور بشكل تصريحي جميع المسارات الممكنة في مكان واحد، مما يحسن قابلية قراءة الكود ويبسط اختبار التنقل. وفقًا لـ Google I/O 2024، يقلل Jetpack Compose مع Navigation Compose من كود التنقل بنسبة 40–60% مقارنة بـ FragmentManager.

الأخطاء الشائعة مع composable()

أحد أكثر الأخطاء شيوعًا هو إعادة إنشاء NavController أثناء إعادة التركيب. إذا تم إنشاء NavController عبر rememberNavController() على مستوى composable الأصلي، الذي قد يُعاد إنشاؤه عند تغيير الحالة، يتعطل التنقل — يُفقد التاريخ. الحل الصحيح هو رفع NavController إلى مستوى composable مستقر، مثل مستوى Activity أو composable الجذر للتطبيق.

المشكلة الثانية الشائعة هي إعادة التركيب اللانهائية أثناء التنقل. يحدث هذا عندما يتم وضع navController.navigate() مباشرة في جسم دالة composable. نظرًا لأن التنقل يغير حالة NavHost، فإنه يؤدي إلى إعادة تركيب، والتي تستدعي navigate() مرة أخرى، مما يُنشئ حلقة. يجب أن تكون جميع استدعاءات التنقل مغلفة في lambdas معالجة (onClick، onButtonPressed)، وليس تنفيذها في التركيب.

الخطأ الثالث هو معالجة غير صحيحة لمكدس العودة عند استخدام BottomNavigation. التنقل البسيط عبر navigate() في كل تبديل علامة تبويب يُضيف مدخلاً جديدًا إلى المكدس بدلاً من العودة إلى الموجود. لـ BottomNavigation، يجب استخدام navController.navigate() مع restoreState = true و launchSingleTop = true، مما يضمن استعادة الحالة بشكل صحيح عند تبديل علامات التبويب.

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