احتفظ التطبيق بكلمة البحث بعد تدوير الهاتف، فاعتبر الفريق أن الاستعادة مكتملة. لكن النظام قد ينهي عملية التطبيق في الخلفية، وهي حالة تختلف عن تغيير اتجاه الشاشة. اختبار Android SavedStateHandle يبدأ بتسمية الحدث الذي تريد الاستعادة منه قبل اختيار أداة التخزين.
ViewModel لا يغطي كل عمر التطبيق
توضح وثائق Android للحالة المحفوظة أن ViewModel يتعامل مع تغييرات الإعدادات، وأن SavedStateHandle يمكن أن يدعم استعادة الحالة بعد قتل العملية بواسطة النظام. الحالة مرتبطة بمكدس المهمة؛ لا تُعامل كحفظ دائم يبقى بعد إزالة المهمة أو الإيقاف القسري أو إعادة تشغيل الجهاز.
في مثال افتراضي، تحتوي شاشة الطلبات على بحث Demo وفلتر Open. يحتاج المنتج استعادة هذين الاختيارين عند العودة بعد فقد العملية، ثم إعادة تحميل النتائج المناسبة. لا يلزم حفظ نسخة ضخمة من نتائج الخادم داخل الحالة كي تبدو الشاشة كما كانت.
اكتب ثلاثة اختبارات مختلفة
| الحدث | سؤال القبول |
|---|---|
| تغيير اتجاه الشاشة | هل بقي البحث والفلتر دون إعادة ضبط غير مقصودة؟ |
| التطبيق في الخلفية ثم فقد العملية بواسطة النظام | هل استعيدت المدخلات القابلة للحفظ وعادت النتائج بوضوح؟ |
| إزالة المهمة أو الإيقاف القسري | هل السلوك يطابق سياسة المنتج دون وعد باستعادة غير مضمونة؟ |
حدد ما يجب أن يدوم فعلًا
مسودة طلب طويلة يريد المستخدم إكمالها غدًا قد تحتاج تخزينًا محليًا دائمًا أو حفظًا خادميًا وفق تصميم المنتج. افصلها عن حالة واجهة مؤقتة. كذلك لا تعِد استخدام صلاحية قديمة للوصول إلى سجل؛ تحقق من الجلسة والسجل عند إعادة الجلب.
تذكر توقيت حفظ الحالة عند انتقال Activity إلى التوقف، كما تحذر الوثائق من حدود الكتابة أثناء التوقف. سجل خطوات الاختبار وإصدارات المكتبات والنظام؛ لا تعتبر إبقاء التطبيق مفتوحًا في المصحح محاكاة كافية لفقد العملية.
سجل الاستعادة والفشل معًا
ضمن تطوير تطبيقات الهاتف استخدم بيانات تجريبية وافحص نتيجة العودة بلا شبكة أيضًا. وتحتاج المراجعة التقنية دليلًا على ما استُعيد وما جرى جلبه من جديد. الهدف عودة مفهومة، لا عرض بيانات قديمة على أنها حُدثت أو حفظ لم يحدث.
