تطوير Android / الأساسي: أسس Android وCompose / الدرس 6

التنقل ومكدسات الرجوع ودورة الحياة

صمّم التنقل من القائمة إلى التفاصيل مع التمييز بين حضور الشاشة وإعادة إنشاء النشاط وعمر العملية.

وقت القراءة التقريبي: 5 دقيقةتاريخ مراجعة المحتوى 2026-10-23

في هذه الصفحة

أهداف الدرس

نمذج الوجهات بمعاملات صغيرة وثابتة.
اشرح انتقالات دورة الحياة واختر حدود استعادة الحالة.

عرّف عقود الوجهات

التنقل رحلة مستخدم ذات مكدس رجوع، وليس مجرد استبدال دوال تركيبية مرئية. تفتح وجهة القائمة تفاصيل يحددها معرّف سجل. يعود Back عبر التاريخ ويتبع Up هرم التطبيق، وقد يختلفان بعد دخول خارجي. اجعل معاملات الوجهة صغيرة وقابلة للتسلسل وحمّل السجل الفعلي من طبقة البيانات. تحتاج السجلات المفقودة والروابط غير الصحيحة والدخول دون مصادقة حالات شاشة مقصودة. ارسم هذه الحالات قبل التنفيذ كي لا يصبح المسار الناجح المسار المدعوم الوحيد.

أبقِ التنقل عند حد واضح

يستخدم المقتطف التالي واجهة NavHost في Navigation Compose بمسار نصي ثابت لتوضيح المكدس. إنه نهج محدد مدعوم وليس ادعاء بأن كل مكتبة تنقل تستخدم الواجهة نفسها. ثبّت اعتماد navigation-compose متوافقاً؛ فالمسارات ذات الأنواع تحتاج إعداد التسلسل الموثق، ولـ Navigation 3 نموذج حالة مختلف. مرّر دوال رد إلى الشاشات بدلاً من إعطاء المتحكم لكل مكوّن. يتيح ذلك معاينة واختبار واجهتي القائمة والتفاصيل دون بناء مضيف تنقل كامل.

kotlin مضيف Navigation Compose لشاشتين موجودتين

@Composable
fun ReadingNavigation() {
    val nav = rememberNavController()
    NavHost(navController = nav, startDestination = "list") {
        composable("list") {
            ListScreen(onOpen = { id -> nav.navigate("detail/${Uri.encode(id)}") })
        }
        composable("detail/{id}", arguments = listOf(
            navArgument("id") { type = NavType.StringType }
        )) { entry ->
            DetailScreen(id = entry.arguments?.getString("id"))
        }
    }
}

استورد واجهات androidx.navigation.compose وNavType وnavArgument وandroid.net.Uri. الشاشتان ListScreen وDetailScreen دالتان يعرّفهما التطبيق؛ تقبل DetailScreen معرّفاً قابلاً لـ null وتعالج الإدخال غير الصحيح. يمنع ترميز URI علامات المسار من تغيير بنيته.

افهم انتقالات النشاط

يستدعي Android الدوال onCreate وonStart وonResume وonPause وonStop وربما onDestroy عند تغير ظروف النشاط. الرؤية والتفاعل النشط مرتبطان لكنهما مختلفان، خصوصاً في بيئات النوافذ المتعددة. قد تدمر تغييرات الإعداد النشاط وتعيد إنشاءه مع استمرار عملية التطبيق. قد تزيل وفاة العملية جميع الكائنات في الذاكرة، ولا يُضمن استدعاء onDestroy قبل ذلك. لا تضع النسخة الوحيدة من بيانات المستخدم المهمة في دالة استدعاء ولا تعتمد على تنظيف أخير لحفظها. احفظ التعديلات المؤكدة عبر طبقة البيانات عندما يثبتها المستخدم.

اقرن المراقبة بالمالك المرئي

ينبغي لجمع البيانات في الواجهة مراعاة دورة الحياة كي لا تبقي شاشة غير مرئية عملاً غير لازم نشطاً. في Compose يعد collectAsStateWithLifecycle الجسر المعتاد لجمع Flow على Android، ويوفره lifecycle-runtime-compose. في نشاط يعتمد Views يمكن لـ repeatOnLifecycle بدء كتلة جمع وإلغائها حول حالة دورة حياة. يجب أن تكون إعادة تشغيل المراقب آمنة؛ يراقب الحقيقة الحالية بدلاً من تكرار شراء أو أمر غير قابل للعكس. تضبط إدارة دورة الحياة المراقبة ولا تحول coroutine عابرة إلى عمل خلفي دائم.

kotlin جمع يراعي دورة الحياة داخل نشاط يعتمد Views

lifecycleScope.launch {
    repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.items.collect { items ->
            adapter.submitList(items)
        }
    }
}

ضعه مرة واحدة بعد تهيئة adapter داخل ComponentActivity مع lifecycle-runtime-ktx واستيرادات coroutines. يفترض المثال ViewModel يكشف Flow ومحوّل قائمة. تستخدم شاشة Compose جسر الجمع الخاص بها بدلاً من إنشاء طبقة المحوّل هذه.

صنّف ما يجب استعادته

يصمد ViewModel عادة أمام إعادة إنشاء مالكه بسبب الإعداد، لكنه لا يصمد أمام وفاة العملية. احفظ معرّف تنقل صغيراً أو مسودة بآلية الحالة المدعومة وأعد تحميل السجلات الدائمة من التخزين. تجنب حفظ قوائم نتائج كاملة أو صور في Bundle. إعادة فتح التطبيق بعد الإيقاف الإجباري تختلف عن استعادة مهمة أعادها النظام، فحدّد التوقعات صراحة. اختبر الرجوع بعد الدخول المباشر وإعادة الإنشاء وتأكد من أن إعادة المحاولة لا تكرر إدخالات المكدس. يتحقق اختبار الاستعادة المفيد من مهمة المستخدم لا عنوان الشاشة فقط.

الأخطاء الشائعة وإصلاحها

ينكسر مسار التفاصيل لمعرّف يحتوي شرطة مائلة

لماذا يحدث؟: دُمجت البيانات الخام في صياغة المسار.
كيف تصلحه؟: رمّز المعامل أو استخدم تنقلاً ذا أنواع مضبوطاً بصورة صحيحة.
كيف تتجنب تكراره؟: اختبر الترقيم وUnicode والمعاملات المفقودة.

يؤدي الحفظ في onDestroy وحده إلى فقد التعديلات

لماذا يحدث؟: لا يضمن إنهاء العملية ذلك الاستدعاء.
كيف تصلحه؟: احفظ التغييرات المثبتة عند حدوثها واحفظ الحالة العابرة الصغيرة منفصلة.
كيف تتجنب تكراره؟: اختبر الاستعادة مع إعادة إنشاء العملية فعلياً.

تستمر شاشة مخفية في الجمع دون توقف

لماذا يحدث؟: يستخدم الجمع نطاقاً غير مدار.
كيف تصلحه؟: استخدم جمعاً يراعي دورة الحياة مع مالك الشاشة الصحيح.
كيف تتجنب تكراره؟: راجع عمر النطاق عند إضافة كل جامع.

اختبر فهمك

1. يفتح مستخدم رابط تفاصيل حُذف سجله. صف سلوك الوجهة وعقد الرجوع.

اعرض الحل المشروح

تحقق من المعرّف وابحث عبر المستودع واعرض حالة عدم وجود مع طريق إلى القائمة. لا تنشئ سجلاً فارغاً وهمياً. حدّد هل يغادر Back المهمة المدخولة خارجياً أم يعود عبر مكدس قائم، بينما يوفر Up هرم التطبيق بصورة متسقة.

2. تصمد مسودة أمام التدوير وتختفي بعد وفاة العملية. حدد السبب واختر تخزين نص المسودة والسجلات المؤكدة.