عملیات های مختلف سیستم اندروید می تواند بر وضعیت قطعه شما تأثیر بگذارد. برای اطمینان از ذخیره شدن وضعیت کاربر، فریم ورک اندروید به طور خودکار قطعات و پشته پشته را ذخیره و بازیابی می کند. بنابراین، باید اطمینان حاصل کنید که هر داده ای در قطعه شما ذخیره و بازیابی می شود.
جدول زیر به تشریح عملیاتی میپردازد که باعث میشود قطعه شما حالت خود را از دست بدهد، به همراه اینکه آیا انواع مختلف حالت در طول این تغییرات باقی میمانند یا خیر. انواع حالت های ذکر شده در جدول به شرح زیر است:
- متغیرها: متغیرهای محلی در قطعه.
- View State: هر داده ای که متعلق به یک یا چند نما در قطعه است.
- SavedState: داده های ذاتی این نمونه قطعه که باید در
onSaveInstanceState()
ذخیره شود. - NonConfig: دادههایی که از یک منبع خارجی، مانند سرور یا مخزن محلی، یا دادههای ایجاد شده توسط کاربر که پس از انجام تعهد به سرور ارسال میشوند، استخراج میشوند.
اغلب اوقات با متغیرها مانند SavedState رفتار میشود، اما جدول زیر بین این دو تمایز قائل میشود تا تأثیر عملیاتهای مختلف بر روی هر کدام را نشان دهد.
عملیات | متغیرها | مشاهده وضعیت | SavedState | NonConfig |
---|---|---|---|---|
به پشته اضافه شد | ✓ | ✓ | x | ✓ |
تغییر پیکربندی | x | ✓ | ✓ | ✓ |
فرآیند مرگ/تفریح | x | ✓ | ✓ | ✓* |
حذف شده به پشته اضافه نشده است | x | x | x | x |
میزبان تمام شد | x | x | x | x |
* حالت NonConfig را می توان با استفاده از ماژول وضعیت ذخیره شده برای ViewModel در سراسر مرگ فرآیند حفظ کرد.
جدول 1: عملیات مخرب قطعات مختلف و اثرات آنها بر انواع حالت های مختلف.
بیایید به یک مثال خاص نگاه کنیم. صفحهای را در نظر بگیرید که یک رشته تصادفی تولید میکند، آن را در TextView
نمایش میدهد و گزینهای برای ویرایش رشته قبل از ارسال آن به یک دوست فراهم میکند:
![برنامه تولید متن تصادفی که انواع مختلف حالت را نشان می دهد](https://developer.android.com/static/images/guide/fragments/text-generator-app.png?authuser=0&hl=fa)
برای این مثال، فرض کنید وقتی کاربر دکمه ویرایش را فشار میدهد، برنامه یک نمای 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
- آزمایشگاه کد اجزای آگاه از چرخه حیات