फ़्रैगमेंट के साथ सेव करने की स्थिति

Android सिस्टम से जुड़ी अलग-अलग कार्रवाइयां, आपके फ़्रैगमेंट की स्थिति पर असर डाल सकती हैं. Android फ़्रेमवर्क अपने-आप यह पक्का करता है कि उपयोगकर्ता की स्थिति सेव की जाए, फ़्रैगमेंट और पिछली गतिविधियों को सेव और पहले जैसा करता है. इसलिए, आपको ताकि यह पक्का किया जा सके कि आपके फ़्रैगमेंट में मौजूद डेटा को भी सेव और वापस लाया जा सकता है.

नीचे दी गई टेबल में उन कार्रवाइयों के बारे में बताया गया है जिनकी वजह से आपका फ़्रैगमेंट खो सकता है राज्य के साथ-साथ यह भी देख सकते हैं कि क्या अलग-अलग बदलाव. टेबल में बताए गए राज्य के टाइप:

• वैरिएबल: फ़्रैगमेंट में लोकल वैरिएबल.
• व्यू स्टेट: ऐसा कोई भी डेटा जिसका मालिकाना हक फ़्रैगमेंट में एक या उससे ज़्यादा व्यू के पास है.
• सेव की गई स्थिति: इस फ़्रैगमेंट इंस्टेंस में मौजूद डेटा, जिसे सेव किया जाना चाहिए onSaveInstanceState() में.
• नॉन-कॉन्फ़िगरेशन: किसी बाहरी सोर्स से लिया गया डेटा, जैसे कि सर्वर या लोकल सोर्स डेटा स्टोर करने की जगह या उपयोगकर्ता का बनाया गया डेटा हो सकता है, जो एक बार काम करने के बाद सर्वर को भेजा जाता है.

अक्सर वैरिएबल को SavedState की तरह ही माना जाता है, लेकिन नीचे दी गई टेबल में, इन दोनों के बीच अंतर बताया गया है. में से हर कार्रवाई के लिए किया जा सकता है.

कार्रवाई	वैरिएबल	व्यू स्टेट	सेव की गई स्थिति	नॉन-कॉन्फ़िगरेशन
पिछली गतिविधियों में जोड़ा गया	✓	✓	x	✓
कॉन्फ़िगरेशन में बदलाव	x	✓	✓	✓
मौत/मनोरंजन की प्रोसेस	x	✓	✓	✓*
पिछली गतिविधियों में नहीं जोड़ा गया	x	x	x	x
होस्ट का सेशन खत्म हो गया	x	x	x	x

* नॉन-कॉन्फ़िगरेशन स्थिति को, पूरी प्रोसेस के दौरान जारी रखा जा सकता है. इसके लिए ViewModel के लिए सेव किया गया स्टेट मॉड्यूल.

टेबल 1: अलग-अलग फ़्रैगमेंट को नुकसान पहुंचाने वाली कार्रवाइयां और उनके असर जो अलग-अलग स्टेट टाइप पर होती हैं.

आइए, एक खास उदाहरण देखें. ऐसी स्क्रीन पर ध्यान दें जो रैंडम स्ट्रिंग, इसे TextView में दिखाती है और इसमें बदलाव करने का विकल्प देती है स्ट्रिंग को किसी दोस्त को भेजें:

पहली इमेज. यह बताने वाला रैंडम टेक्स्ट जनरेटर ऐप्लिकेशन अलग-अलग राज्यों के लिए है.

उदाहरण के लिए, मान लें कि एक बार उपयोगकर्ता ने 'बदलाव करें' बटन दबाया, तो ऐप्लिकेशन, EditText व्यू दिखाता है, जहां उपयोगकर्ता मैसेज में बदलाव कर सकता है. अगर जब कोई उपयोगकर्ता CANCEL पर क्लिक करता है, तो EditText व्यू को मिटा दिया जाना चाहिए विज़िबिलिटी को View.GONE पर सेट किया गया. इस तरह आसान बनाने के लिए, स्क्रीन पर डेटा के चार हिस्सों को मैनेज करने की ज़रूरत पड़ सकती है अनुभव:

डेटा	टाइप	राज्य का टाइप	ब्यौरा
seed	Long	नॉन-कॉन्फ़िगरेशन	किसी भी क्रम में कोई नया काम करने के लिए इस्तेमाल किए गए बीज. जनरेट होने का समय ViewModel बनाया जाता है.
randomGoodDeed	String	सेव किया गया स्टेटस + वैरिएबल	यह तब जनरेट होता है, जब फ़्रैगमेंट पहली बार बनाया जाता है. randomGoodDeed को सेव किया जाता है, ताकि यह पक्का किया जा सके कि लोगों को प्रक्रिया की मृत्यु के बाद भी कोई अच्छा काम करना और मनोरंजन.
isEditing	Boolean	सेव किया गया स्टेटस + वैरिएबल	उपयोगकर्ता के बदलाव करना शुरू करने पर, बूलियन फ़्लैग true पर सेट हो जाता है. isEditing को सेव किया जाता है, ताकि यह पक्का किया जा सके कि फ़्रैगमेंट को फिर से बनाने पर, स्क्रीन दिखती रहेगी.
वह टेक्स्ट जिसमें बदलाव किया गया है	Editable	व्यू स्टेट (EditText के मालिकाना हक वाली)	EditText व्यू में बदलाव किया गया टेक्स्ट. EditText व्यू इस टेक्स्ट को सेव करता है, ताकि यह पक्का किया जा सके कि उपयोगकर्ता का जो बदलाव लागू होते हैं वे मिटते नहीं हैं.

दूसरी टेबल: इसमें यह जानकारी दी गई है कि रैंडम टेक्स्ट जनरेटर ऐप्लिकेशन को किन बातों को मैनेज करना चाहिए.

यहां दिए सेक्शन में बताया गया है कि अपने डेटा को सही तरीके से मैनेज कैसे करें नुकसान पहुंचाने वाली कार्रवाइयों से निपटना चाहिए.

व्यू स्टेट

अपने राज्य को मैनेज करने के लिए व्यू ज़िम्मेदार होते हैं. उदाहरण के लिए, जब किसी व्यू, उपयोगकर्ता के इनपुट स्वीकार करता है. इसे सेव करना और वापस लाना व्यू की ज़िम्मेदारी है जो कॉन्फ़िगरेशन बदलावों को हैंडल करने के लिए इनपुट देता है. सभी Android फ़्रेमवर्क के साथ व्यू के लिए, onSaveInstanceState() को खुद लागू किया जाता है और onRestoreInstanceState(), ताकि आपको इसके अंदर व्यू स्टेट मैनेज नहीं करना पड़े आपका फ़्रैगमेंट.

ध्यान दें: कॉन्फ़िगरेशन में बदलावों के दौरान, गड़बड़ियों को सही तरीके से हैंडल करने के लिए, आपको सभी के लिए, onSaveInstanceState() और onRestoreInstanceState() को लागू करें से ज़्यादा व्यू मिलते हैं.

उदाहरण के लिए, पिछले उदाहरण में, बदली गई स्ट्रिंग EditText. EditText को पता है दिखाए जा रहे टेक्स्ट की वैल्यू, और अन्य जानकारी, जैसे कि चुने गए टेक्स्ट के शुरुआती और आखिरी हिस्से को शामिल करें.

किसी व्यू की स्थिति बनाए रखने के लिए, आईडी की ज़रूरत होती है. इसमें यह आईडी यूनीक होना चाहिए: फ़्रैगमेंट और उसके व्यू हैरारकी (व्यू और व्यू ग्रुप के लेआउट का क्रम) के हिसाब से. बिना आईडी वाले व्यू को बनाए नहीं रखा जा सकता उनके राज्य का नाम है.

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

जैसा कि पहली टेबल में बताया गया है, व्यू अपने ViewState को इसके ज़रिए सेव और पहले जैसा करते हैं ऐसी सभी कार्रवाइयां जो फ़्रैगमेंट को नहीं हटाते या होस्ट को नष्ट नहीं करते.

SavedState

छोटे हिस्से में डाइनैमिक स्टेट को मैनेज करने की ज़िम्मेदारी आपके फ़्रैगमेंट की है जो फ़्रैगमेंट के काम करने के तरीके का ज़रूरी हिस्सा हैं. बनाए रखने के लिए इसका इस्तेमाल करके, डेटा को आसानी से क्रम में लगाया जा सकता है Fragment.onSaveInstanceState(Bundle). इसके समान Activity.onSaveInstanceState(Bundle) बंडल में जो डेटा आपने रखा है उसे कॉन्फ़िगरेशन में बदलाव करने पर सेव रखा जाता है और यह आपके फ़्रैगमेंट में उपलब्ध होता है. onCreate(Bundle), onCreateView(LayoutInflater, ViewGroup, Bundle), और onViewCreated(View, Bundle) तरीकों का इस्तेमाल करना होगा.

चेतावनी: onSaveInstanceState(Bundle) को सिर्फ़ तब कॉल किया जाता है, जब फ़्रैगमेंट का होस्ट ऐक्टिविटी अपनी onSaveInstanceState(Bundle) को कॉल करती है.

सलाह: ViewModel का इस्तेमाल करते समय, स्थिति को सीधे SavedStateHandle का इस्तेमाल करके ViewModel. ज़्यादा जानकारी के लिए, यह देखें ViewModel के लिए सेव किया गया स्टेट मॉड्यूल.

पिछले उदाहरण के मुताबिक, randomGoodDeed वह डीड है जो उपयोगकर्ता को दिखाई जाती है और isEditing एक फ़्लैग है जो यह तय करता है कि फ़्रैगमेंट EditText को दिखाता या छिपाता है. सेव की गई स्थिति onSaveInstanceState(Bundle) का इस्तेमाल करके जारी रखता है, जैसा कि उदाहरण:

Kotlin

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

Java

@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) में स्थिति वापस लाने के लिए, इससे स्टोर की गई वैल्यू फिर से पाएं बंडल:

Kotlin

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

Java

@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 में बताया गया है, ध्यान दें कि वैरिएबल तब बने रहते हैं, जब फ़्रैगमेंट को बैकस्टैक पर रखा गया है. उन्हें सेव किए गए स्टेटस के तौर पर देखने से पक्का होता है कि वे सभी नुकसान पहुंचाने वाली कार्रवाइयों में आज भी बने रहते हैं.

नॉन-कॉन्फ़िगरेशन

नॉन-कॉन्फ़िगरेशन डेटा को आपके फ़्रैगमेंट के बाहर डालना चाहिए, जैसे कि ViewModel. पिछले इतने समय में ऊपर दिया गया उदाहरण, ViewModel में seed (हमारी नॉन कॉन्फ़िगरेशन स्थिति) जनरेट किया गया है. इसकी स्थिति को बनाए रखने का लॉजिक, ViewModel के पास है.

Kotlin

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
    }
}

Java

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 को मौत और मनोरंजन की गतिविधि.

अन्य संसाधन

फ़्रैगमेंट स्थिति को मैनेज करने के बारे में ज़्यादा जानकारी के लिए, इन्हें देखें अतिरिक्त संसाधन शामिल करें.

कोड लैब

• लाइफ़साइकल-अवेयर कॉम्पोनेंट कोडलैब

गाइड

• व्यू मॉडल के लिए सेव किया गया स्टेट मॉड्यूल
• यूज़र इंटरफ़ेस (यूआई) की स्थितियों को सेव करना