ذخیره وضعیت با قطعات

عملیات های مختلف سیستم اندروید می تواند بر وضعیت قطعه شما تأثیر بگذارد. برای اطمینان از ذخیره شدن وضعیت کاربر، فریم ورک اندروید به طور خودکار قطعات و پشته پشته را ذخیره و بازیابی می کند. بنابراین، باید اطمینان حاصل کنید که هر داده ای در قطعه شما ذخیره و بازیابی می شود.

جدول زیر به تشریح عملیاتی می‌پردازد که باعث می‌شود قطعه شما حالت خود را از دست بدهد، به همراه اینکه آیا انواع مختلف حالت در طول این تغییرات باقی می‌مانند یا خیر. انواع حالت های ذکر شده در جدول به شرح زیر است:

  • متغیرها: متغیرهای محلی در قطعه.
  • View State: هر داده ای که متعلق به یک یا چند نما در قطعه است.
  • SavedState: داده های ذاتی این نمونه قطعه که باید در onSaveInstanceState() ذخیره شود.
  • NonConfig: داده‌هایی که از یک منبع خارجی، مانند سرور یا مخزن محلی، یا داده‌های ایجاد شده توسط کاربر که پس از انجام تعهد به سرور ارسال می‌شوند، استخراج می‌شوند.

اغلب اوقات با متغیرها مانند SavedState رفتار می‌شود، اما جدول زیر بین این دو تمایز قائل می‌شود تا تأثیر عملیات‌های مختلف بر روی هر کدام را نشان دهد.

عملیات متغیرها مشاهده وضعیت SavedState NonConfig
به پشته اضافه شد ✓ ✓ x ✓
تغییر پیکربندی x ✓ ✓ ✓
فرآیند مرگ/تفریح x ✓ ✓ ✓*
حذف شده به پشته اضافه نشده است x x x x
میزبان تمام شد x x x x

* حالت NonConfig را می توان با استفاده از ماژول وضعیت ذخیره شده برای ViewModel در سراسر مرگ فرآیند حفظ کرد.

جدول 1: عملیات مخرب قطعات مختلف و اثرات آنها بر انواع حالت های مختلف.

بیایید به یک مثال خاص نگاه کنیم. صفحه‌ای را در نظر بگیرید که یک رشته تصادفی تولید می‌کند، آن را در TextView نمایش می‌دهد و گزینه‌ای برای ویرایش رشته قبل از ارسال آن به یک دوست فراهم می‌کند:

برنامه تولید متن تصادفی که انواع مختلف حالت را نشان می دهد
شکل 1. برنامه تولید متن تصادفی که انواع مختلف حالت را نشان می دهد.

برای این مثال، فرض کنید وقتی کاربر دکمه ویرایش را فشار می‌دهد، برنامه یک نمای EditText را نمایش می‌دهد که در آن کاربر می‌تواند پیام را ویرایش کند. اگر کاربر روی لغو کلیک کند، نمای EditText باید پاک شود و قابلیت مشاهده آن روی View.GONE تنظیم شود. چنین صفحه‌ای ممکن است نیاز به مدیریت چهار داده داشته باشد تا از یک تجربه یکپارچه اطمینان حاصل شود:

داده ها تایپ کنید نوع حالت توضیحات
seed Long NonConfig بذر برای ایجاد تصادفی یک عمل خوب جدید استفاده می شود. هنگام ایجاد ViewModel ایجاد می شود.
randomGoodDeed String SavedState + متغیر هنگامی که قطعه برای اولین بار ایجاد می شود، ایجاد می شود. randomGoodDeed ذخیره شده است تا اطمینان حاصل شود که کاربران حتی پس از مرگ فرآیند و تفریح، همان کار خیر تصادفی را مشاهده می کنند.
isEditing Boolean SavedState + متغیر وقتی کاربر شروع به ویرایش کرد، پرچم بولی روی true تنظیم شد. isEditing ذخیره می شود تا اطمینان حاصل شود که قسمت ویرایش صفحه هنگام بازسازی قطعه قابل مشاهده است.
متن ویرایش شده Editable مشاهده وضعیت (متعلق به EditText ) متن ویرایش شده در نمای EditText . نمای EditText این متن را ذخیره می کند تا اطمینان حاصل شود که تغییرات در حال انجام کاربر از بین نمی رود.

جدول 2: بیان می کند که برنامه تولید کننده متن تصادفی باید مدیریت کند.

بخش های زیر نحوه مدیریت صحیح وضعیت داده های خود را از طریق عملیات مخرب شرح می دهد.

مشاهده وضعیت

دیدگاه ها مسئول مدیریت وضعیت خود هستند. به عنوان مثال، هنگامی که یک view ورودی کاربر را می‌پذیرد، وظیفه مشاهده و بازیابی آن ورودی برای مدیریت تغییرات پیکربندی است. همه نماهای ارائه‌شده توسط فریم‌ورک اندروید پیاده‌سازی خاص خود را از onSaveInstanceState() و onRestoreInstanceState() دارند، بنابراین شما مجبور نیستید وضعیت view را در قطعه خود مدیریت کنید.

به عنوان مثال، در سناریوی قبلی، رشته ویرایش شده در یک EditText نگهداری می شود. یک EditText ارزش متنی را که نمایش می دهد و همچنین جزئیات دیگر مانند ابتدا و انتهای هر متن انتخابی را می داند.

یک نما برای حفظ وضعیت خود به شناسه نیاز دارد. این شناسه باید در قطعه و سلسله مراتب نمای آن منحصر به فرد باشد. نماهای بدون شناسه نمی توانند وضعیت خود را حفظ کنند.

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

همانطور که در جدول 1 ذکر شد، view ها ViewState خود را از طریق تمام عملیات هایی که قطعه را حذف نمی کنند یا میزبان را از بین نمی برند ذخیره و بازیابی می کنند.

SavedState

قطعه شما مسئول مدیریت مقادیر کمی از حالت پویا است که در نحوه عملکرد قطعه ضروری است. با استفاده از Fragment.onSaveInstanceState(Bundle) می‌توانید داده‌هایی را که به راحتی سریال‌سازی می‌شوند، حفظ کنید. مشابه Activity.onSaveInstanceState(Bundle) ، داده هایی که در بسته قرار می دهید از طریق تغییرات پیکربندی و پردازش مرگ و بازآفرینی حفظ می شوند و در onCreate(Bundle) ، onCreateView(LayoutInflater, ViewGroup, Bundle) و onViewCreated(View, 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

داده‌های 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 اجازه می دهد تا حالت ساده را از طریق مرگ فرآیند و بازآفرینی حفظ کند.

منابع اضافی

برای اطلاعات بیشتر در مورد مدیریت وضعیت قطعه، منابع اضافی زیر را ببینید.

Codelabs

راهنماها