تغييرات حالة النشاط

يمكن أن تؤدي الأحداث المختلفة، بعضها من تنفيذ المستخدم وبعضها من تنفيذ النظام، إلى انتقال Activity من حالة إلى أخرى. يوضّح هذا المستند بعض الحالات الشائعة التي تحدث فيها عمليات الانتقال هذه وكيفية التعامل معها.

لمزيد من المعلومات عن حالات النشاط، يُرجى الاطّلاع على مقالة دورة حياة النشاط. للتعرّف على كيفية مساعدة فئة ViewModel في إدارة دورة حياة النشاط، يُرجى الاطّلاع على نظرة عامة على ViewModel.

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

تغيير الإعدادات

هناك عدد من الأحداث التي يمكن أن تؤدي إلى تغيير الإعدادات. ربما يكون المثال الأبرز هو التغيير بين الوضعَين العمودي والأفقي. تشمل الحالات الأخرى التي يمكن أن تؤدي إلى تغيير الإعدادات تغييرات إعدادات اللغة أو جهاز الإدخال.

عند حدوث تغيير في الإعدادات، يتم إتلاف النشاط وإعادة إنشائه. يؤدي ذلك إلى استدعاء دوالّ ردّ الاتصال التالية في مثيل النشاط الأصلي:

1. onPause
2. onStop
3. onDestroy

يتم إنشاء مثيل جديد للنشاط، ويتم استدعاء دوالّ ردّ الاتصال التالية:

1. onCreate
2. onStart
3. onResume

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

استخدِم مجموعة من مثيلات ViewModel أو rememberSaveable أو مساحة التخزين المحلية الثابتة للحفاظ على حالة واجهة مستخدم النشاط عند تغيير الإعدادات. يعتمد تحديد كيفية دمج هذه الخيارات على مدى تعقيد بيانات واجهة المستخدم وحالات استخدام تطبيقك، بالإضافة إلى مراعاة سرعة الاسترداد مقابل استخدام الذاكرة. بالنسبة إلى معظم حالات الاستخدام، عليك نقل الحالة إلى ViewModel واستخدام rememberSaveable لضمان استمرار الحالة خلال تغييرات الإعدادات وإيقاف العملية نهائيًا من قِبل النظام. لمزيد من المعلومات عن حفظ حالة واجهة مستخدم النشاط، يُرجى الاطّلاع على مقالة حفظ حالات واجهة المستخدم.

عند إعادة إنشاء نشاط بسبب تغيير الإعدادات، يتم التخلّص من التركيب الأولي. يضمن استخدام ViewModel أو rememberSaveable استعادة حالة واجهة المستخدم في التركيب الجديد.

لمزيد من المعلومات، يُرجى الاطّلاع على مقالتَي مراحل النشاط في Jetpack Compose وState و Jetpack Compose.

التعامل مع حالات النوافذ المتعددة

عندما يدخل تطبيق وضع النوافذ المتعددة، المتاح في Android 7.0 (المستوى 24 من واجهة برمجة التطبيقات) والإصدارات الأحدث، يُعلم النظام النشاط قيد التشغيل بتغيير الإعدادات، ما يؤدي إلى الانتقال خلال عمليات الانتقال في دورة الحياة الموضّحة سابقًا.

يحدث هذا السلوك أيضًا إذا تم تغيير حجم تطبيق في وضع النوافذ المتعددة. يمكن أن يتعامل النشاط مع تغيير الإعدادات بنفسه، أو يمكنه السماح للنظام بإتلاف النشاط وإعادة إنشائه بالأبعاد الجديدة.

لمزيد من المعلومات عن مراحل نشاط النوافذ المتعددة، يُرجى الاطّلاع على شرح مراحل نشاط النوافذ المتعددة في استخدام وضع النوافذ المتعددة.

في وضع النوافذ المتعددة، على الرغم من ظهور تطبيقَين للمستخدم، لا يكون في المقدّمة ويكون التركيز على التطبيق الذي يتفاعل معه المستخدم فقط. تكون حالة هذا النشاط "مستأنفًا"، بينما تكون حالة التطبيق في النافذة الأخرى "متوقفًا مؤقتًا".

عندما ينتقل المستخدم من التطبيق "أ" إلى التطبيق "ب"، يستدعي النظام onPause على التطبيق "أ" وonResume على التطبيق "ب". يتم التبديل بين هاتَين الطريقتَين في كل مرة يبدّل فيها المستخدم بين التطبيقات.

لمزيد من التفاصيل عن وضع النوافذ المتعددة، يُرجى الرجوع إلى مقالة استخدام وضع النوافذ المتعددة.

ظهور نشاط أو مربّع حوار في المقدّمة

إذا ظهر نشاط أو مربّع حوار جديد في المقدّمة، ما يؤدي إلى التركيز عليه وتغطية النشاط قيد التقدّم جزئيًا، يفقد النشاط المغطّى التركيز ويدخل حالة "متوقفًا مؤقتًا". بعد ذلك، يستدعي النظام onPause عليه.

عندما يعود النشاط المغطّى إلى المقدّمة ويستعيد التركيز، يستدعي الـ نظام onResume.

إذا ظهر نشاط أو مربّع حوار جديد في المقدّمة، ما يؤدي إلى التركيز عليه وتغطية النشاط قيد التقدّم بالكامل، يفقد النشاط المغطّى التركيز ويدخل حالة "متوقفًا". بعد ذلك، يستدعي النظام onPause و onStop بسرعة.

عندما يعود المثيل نفسه من النشاط المغطّى إلى المقدّمة، يستدعي الـ نظام onRestart وonStart وonResume في الـ نشاط. إذا كان مثيلاً جديدًا من النشاط المغطّى الذي ينتقل إلى الخلفية، لا يستدعي النظام onRestart، بل يستدعي onStart وonResume فقط.

لا تتأثر عملية إعادة التركيب بمربّعات الحوار التي تظهر في المقدّمة. ومع ذلك، يجب أن تستخدم الآثار الجانبية المرتبطة بمراحل النشاط، مثل التدفقات والرسوم المتحركة، واجهات برمجة تطبيقات تراعي مراحل النشاط (مثل collectAsStateWithLifecycle) لـ إيقاف العمل مؤقتًا واستئنافه تلقائيًا حسب الحاجة. لمزيد من المعلومات، يُرجى الاطّلاع على مقالة State وJetpack Compose.

نقر المستخدم على "رجوع" أو استخدام إيماءة "رجوع"

إذا كان النشاط في المقدّمة ونقر المستخدم على "رجوع" أو استخدم إيماءة "رجوع"، ينتقل ال نشاط خلال دوالّ ردّ الاتصال onPause وonStop و onDestroy. يتم إتلاف النشاط وإزالته من مكدس الرجوع.

في تطبيق ذي نشاط واحد، مثل معظم تطبيقات Compose، لن يحافظ rememberSaveable على الحالة إذا تمت إزالة العنصر القابل للإنشاء من مكدس التنقّل للرجوع. يرجع ذلك إلى أنّه عندما ينقر المستخدم على "رجوع"، لا يُتوقَّع أن يعود إلى المثيل نفسه، لذا يتم محو جميع الحالات.

لتنفيذ سلوك "رجوع" مخصّص، مثل عرض مربّع حوار يطلب من المستخدم تأكيد رغبته في الخروج من تطبيقك، استخدِم واجهة برمجة التطبيقات NavigationEventHandler.

إيقاف النظام لعملية التطبيق

إذا كان التطبيق في الخلفية وكان النظام بحاجة إلى إخلاء الذاكرة لتطبيق يعمل في المقدّمة، يمكن للنظام إيقاف التطبيق في الخلفية. وعندما يوقف النظام تطبيقًا، ليس هناك ما يضمن استدعاء onDestroy في التطبيق.

لمزيد من المعلومات عن كيفية تحديد النظام للعمليات التي سيتم محوها، يُرجى قراءة حالة النشاط والإزالة من الذاكرة والـ العمليات ومراحل نشاط التطبيق.

للتعرّف على كيفية حفظ حالة واجهة مستخدم النشاط عندما يوقف النظام عملية تطبيقك ، يُرجى الاطّلاع على مقالة حفظ حالة واجهة المستخدم المؤقتة واستعادتها.