جارٍ حفظ الحالة مع الأجزاء

يمكن أن تؤثر عمليات نظام Android المختلفة في حالة الجزء. لضمان حفظ حالة المستخدم، يتم تلقائيًا استخدام إطار عمل Android. لحفظ الأجزاء وحزمة الخلفية واستعادتها. لذلك، تحتاج إلى لضمان حفظ أي بيانات في الكسر واستعادتها أيضًا.

يوضح الجدول التالي العمليات التي تؤدي إلى فقدان الجزء وما إذا كانت الأنواع المختلفة من الحالات تستمر من خلال تلك التغييرات. في ما يلي أنواع الحالات المذكورة في الجدول:

• المتغيرات: المتغيّرات المحلية في الجزء.
• حالة العرض: أي بيانات يملكها ملف شخصي واحد أو أكثر في الجزء.
• SaveState: البيانات المتأصلة في مثيل الجزء هذا والتي يجب حفظها في onSaveInstanceState().
• NonConfig: البيانات التي يتم استخراجها من مصدر خارجي، مثل خادم أو محلي أو بيانات ينشئها المستخدم ويتم إرسالها إلى الخادم بعد إتمامها.

في كثير من الأحيان، يتم التعامل مع المتغيرات بالطريقة نفسها مثل SavedState، ولكن يتم يميز الجدول التالي بين الاثنين لتوضيح تأثير على العمليات المختلفة في كل منها.

* يمكن الاحتفاظ بحالة NonConfig في جميع مراحل انتهاء العملية باستخدام وحدة الحالة المحفوظة لتطبيق ViewModel

الجدول 1: العمليات العديدة التي تؤدي إلى تدمير الأجزاء وتأثيراتها في أنواع الحالات المختلفة.

لنلقِ نظرة على مثال محدد. ضع في اعتبارك شاشة تنشئ سلسلة عشوائية، ويتم عرضها في TextView، وتوفّر خيار تعديلها السلسلة قبل إرسالها إلى صديق:

في هذا المثال، افترض أنه بمجرد ضغط المستخدم على زر التعديل، التطبيق طريقة عرض "EditText" حيث يمكن للمستخدم تعديل الرسالة. إذا كانت ينقر المستخدم على إلغاء، وسيتم محو طريقة العرض EditText تم ضبط مستوى الرؤية على View.GONE. مثل قد تتطلب الشاشة إدارة أربع قطع من البيانات لضمان الخبرة:

الجدول 2: يشير إلى ضرورة أن يديره تطبيق منشئ النص العشوائي.

توضّح الأقسام التالية كيفية إدارة حالة بياناتك بشكلٍ سليم. من خلال عمليات التدمير.

عرض الحالة

تتحمّل المشاهدات مسؤولية إدارة حالتها الخاصة. على سبيل المثال، عندما فإن طريقة العرض تقبل البيانات التي أدخلها المستخدم، وتقع على عاتق العرض مسؤولية حفظها واستعادتها هذا المدخل للتعامل مع تغييرات التهيئة. جميع أطر عمل Android لكل ملف شخصي تنفيذ خاص به لـ onSaveInstanceState() onRestoreInstanceState()، لذا لن تحتاج إلى إدارة حالة العرض ضمن الجزء الخاص بك.

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

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

<EditText
    android:id="@+id/good_deed_edit_text"
    android:layout_width="match_parent"
    android:layout_height="wrap_content" />

كما هو موضّح في الجدول 1، يتم حفظ ViewState واستعادتها من خلال طرق العرض جميع العمليات التي لا تزيل الجزء أو تدمر المضيف.

SavedState

الجزء مسؤول عن إدارة كميات صغيرة من الحالة الديناميكية التي تعتبر جزءًا لا يتجزأ من كيفية عمل الجزء. يمكنك الاحتفاظ البيانات المتسلسلة بسهولة باستخدام Fragment.onSaveInstanceState(Bundle) مشابه لـ Activity.onSaveInstanceState(Bundle)، يتم الاحتفاظ بالبيانات التي تضعها في الحِزمة من خلال تغييرات الإعدادات. ثم الموت أو الترفيه، كما يتوفر في الجزء الخاص onCreate(Bundle), onCreateView(LayoutInflater, ViewGroup, Bundle), أو onViewCreated(View, Bundle) الطرق.

استكمالاً للمثال السابق، فإن randomGoodDeed هو الفعل الذي يتم عرضه للمستخدم، كما أن isEditing هي علامة لتحديد ما إذا كان يعرض الجزء EditText أو يخفيه. يجب أن تكون هذه الحالة المحفوظة: مستمر في استخدام onSaveInstanceState(Bundle)، كما هو موضح في ما يلي مثال:

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putBoolean(IS_EDITING_KEY, isEditing)
    outState.putString(RANDOM_GOOD_DEED_KEY, randomGoodDeed)
}

@Override
public void onSaveInstanceState(@NonNull Bundle outState) {
    super.onSaveInstanceState(outState);
    outState.putBoolean(IS_EDITING_KEY, isEditing);
    outState.putString(RANDOM_GOOD_DEED_KEY, randomGoodDeed);
}

لاستعادة الحالة في onCreate(Bundle)، يمكنك استرداد القيمة المخزّنة من الحزمة:

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    isEditing = savedInstanceState?.getBoolean(IS_EDITING_KEY, false)
    randomGoodDeed = savedInstanceState?.getString(RANDOM_GOOD_DEED_KEY)
            ?: viewModel.generateRandomGoodDeed()
}

@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    if (savedInstanceState != null) {
        isEditing = savedInstanceState.getBoolean(IS_EDITING_KEY, false);
        randomGoodDeed = savedInstanceState.getString(RANDOM_GOOD_DEED_KEY);
    } else {
        randomGoodDeed = viewModel.generateRandomGoodDeed();
    }
}

كما هو مذكور في الجدول 1، لاحظ أنه يتم الاحتفاظ بالمتغيرات عند على الجزء الخلفي من الصفحة. عند التعامل معها كحالة محفوظة، يضمن ذلك تستمر خلال جميع العمليات التخريبية.

عدم ضبط

يجب وضع بيانات NonConfig خارج الجزء، مثل ViewModel في الفترة السابقة في المثال أعلاه، يتم إنشاء seed (حالة NonConfig) في ViewModel. أمّا الطريقة المنطقية للحفاظ على الحالة، فتعود إلى مؤسسة ViewModel.

public class RandomGoodDeedViewModel : ViewModel() {
    private val seed = ... // Generate the seed

    private fun generateRandomGoodDeed(): String {
        val goodDeed = ... // Generate a random good deed using the seed
        return goodDeed
    }
}

public class RandomGoodDeedViewModel extends ViewModel {
    private Long seed = ... // Generate the seed

    private String generateRandomGoodDeed() {
        String goodDeed = ... // Generate a random good deed using the seed
        return goodDeed;
    }
}

تسمح الفئة ViewModel بطبيعتها ببقاء البيانات في حالة عملية الإعداد. التغييرات، مثل تدوير الشاشة، وتظل في الذاكرة عند على المكدس الخلفي. بعد الموت والاستجمام تتمّ إعادة إنشاء ViewModel وإنشاء seed جديدة. إن إضافة الوحدة SavedState إلى ViewModel يتيح لـ ViewModel الاحتفاظ بحالة بسيطة من خلال بالموت والتسلية.

مصادر إضافية

للحصول على مزيد من المعلومات حول إدارة حالة التجزئة، يمكنك الاطّلاع على ما يلي والموارد الإضافية.

الدروس التطبيقية حول الترميز

• درس تطبيقي حول ترميز المكوّنات الواعية لدورة الحياة

الأدلّة

• وحدة الحالة المحفوظة لنموذج العرض
• حفظ حالات واجهة المستخدم