यूज़र इंटरफ़ेस (यूआई) की स्थितियां सेव करें

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

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

उपयोगकर्ता की उम्मीदों और सिस्टम के व्यवहार के बीच के अंतर को कम करने के लिए, तरीकों का इस्तेमाल करके देखें:

• ViewModel ऑब्जेक्ट.
• सेव किए गए इंस्टेंस की स्थिति यहां दी गई है:
  • Jetpack Compose: rememberSaveable.
  • व्यू: onSaveInstanceState() एपीआई.
  • ViewModels: SavedStateHandle.
• लोकल स्टोरेज, ताकि ऐप्लिकेशन और गतिविधि के ट्रांज़िशन के दौरान, यूज़र इंटरफ़ेस (यूआई) की स्थिति को बनाए रखा जा सके.

सबसे अच्छा समाधान आपके यूज़र इंटरफ़ेस (यूआई) के डेटा की जटिलता, आपके ऐप्लिकेशन के इस्तेमाल पर निर्भर करता है और डेटा तक पहुंचने की स्पीड और मेमोरी के इस्तेमाल के बीच संतुलन बनाए रखने में मदद मिलती है.

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

उपयोगकर्ता की उम्मीदें और सिस्टम का व्यवहार

उपयोगकर्ता की कार्रवाई के आधार पर, वह उम्मीद करता है कि गतिविधि की स्थिति साफ़ करने या सुरक्षित किए जाने वाले राज्य को हटाना होगा. कुछ मामलों में, सिस्टम उपयोगकर्ता की उम्मीद के मुताबिक काम अपने-आप करता है. अन्य मामलों में सिस्टम, उपयोगकर्ता की उम्मीद के मुताबिक नहीं होना चाहिए.

उपयोगकर्ता की ओर से शुरू की गई यूज़र इंटरफ़ेस (यूआई) स्थिति खारिज करना

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

• खास जानकारी (हाल ही के) स्क्रीन पर गतिविधि को स्वाइप करके बंद करना.
• सेटिंग स्क्रीन पर जाकर, ऐप्लिकेशन को बंद करना या उसे ज़बरदस्ती बंद करना.
• डिवाइस को फिर से चालू किया जा रहा है.
• अपने कारोबार को "खत्म" करने जैसा कोई काम करना कार्रवाई (जिसकी Activity.finish()).

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

पूरी तरह से खारिज करने के बारे में इस नियम के कुछ अपवाद हैं—उदाहरण के लिए, उपयोगकर्ता यह उम्मीद कर सकता है कि ब्राउज़र उन्हें ठीक उसी वेबपेज पर ले जाए जिसे वे ढूंढ रहे थे पर दिखाई दे सकते हैं.

सिस्टम से शुरू की गई यूज़र इंटरफ़ेस (यूआई) स्थिति खारिज करना

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

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

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

यूज़र इंटरफ़ेस (यूआई) की स्थिति को बनाए रखने के विकल्प

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

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

कॉन्फ़िगरेशन में बदलाव करने के लिए, ViewModel का इस्तेमाल करना

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

ViewModel डेटा को मेमोरी में बनाए रखता है, जिसका मतलब है कि इसे हासिल करना इससे सस्ता है डिस्क या नेटवर्क से लिया गया है. ViewModel किसी गतिविधि से जुड़ा है (या लाइफ़साइकल के किसी दूसरे मालिक) - यह कॉन्फ़िगरेशन के दौरान मेमोरी में बना रहता है में बदलाव किया जाता है और सिस्टम अपने-आप ViewModel को नए कॉन्फ़िगरेशन में बदलाव होने की वजह से होने वाली गतिविधि का इंस्टेंस.

जब उपयोगकर्ता बैक आउट करता है, तब ViewModels सिस्टम अपने-आप मिट जाता है या अगर finish() को कॉल किया जाता है, तो इसका मतलब है कि स्थिति इन स्थितियों में उपयोगकर्ता की उम्मीद के मुताबिक मिटा दिए जाते हैं.

सेव की गई इंस्टेंस स्थिति से अलग, सिस्टम से शुरू होने के दौरान ViewModels खत्म हो जाते हैं पूरी तरह बंद हो जाता है. किसी गड़बड़ी की वजह से, सिस्टम की ओर से शुरू की गई प्रोसेस के बंद होने के बाद, डेटा को फिर से लोड करने के लिए ViewModel, SavedStateHandle एपीआई का इस्तेमाल करें. वैकल्पिक रूप से, अगर डेटा यूआई से संबंधित हो और इसे ViewModel में रखने की ज़रूरत नहीं होती, इसलिए इसका इस्तेमाल करें व्यू सिस्टम में onSaveInstanceState() या Jetpack में rememberSaveable लिखें. अगर डेटा ऐप्लिकेशन का डेटा है, तो बेहतर होगा कि इसे बनाए रखें इसे डिस्क पर ले जाएं.

अगर आपके पास यूज़र इंटरफ़ेस (यूआई) स्थिति को सेव करने के लिए, पहले से ही मेमोरी में मौजूद कोई समाधान मौजूद है कॉन्फ़िगरेशन बदलावों के दौरान होता है, तो हो सकता है कि आपको ViewModel इस्तेमाल करने की ज़रूरत न पड़े.

सिस्टम से शुरू की गई प्रोसेस बंद होने की प्रोसेस को मैनेज करने के लिए, सेव किए गए इंस्टेंस की स्थिति को बैकअप के तौर पर इस्तेमाल करें

व्यू सिस्टम में onSaveInstanceState() कॉलबैक, Jetpack Compose में rememberSaveable और SavedStateHandle ViewModels, यूज़र इंटरफ़ेस (यूआई) कंट्रोलर की स्थिति को फिर से लोड करने के लिए ज़रूरी डेटा स्टोर करता है, जैसे कि ऐक्टिविटी या कोई फ़्रैगमेंट, अगर सिस्टम बंद कर देता है और बाद में उसे फिर से बनाता है कंट्रोलर. सेव की गई इंस्टेंस की स्थिति को लागू करने का तरीका जानने के लिए onSaveInstanceState, गतिविधि को सेव और वापस लाने की स्थिति को इसमें देखें गतिविधि की लाइफ़साइकल गाइड.

सेव किए गए इंस्टेंस की स्थिति के बंडल, कॉन्फ़िगरेशन में किए गए बदलावों और बंद होने को प्रोसेस करती हैं, लेकिन स्टोरेज और स्पीड की वजह से सीमित होती हैं, क्योंकि अलग-अलग एपीआई डेटा को क्रम से लगाएं. क्रम से लगाने की सुविधा में बहुत ज़्यादा मेमोरी खर्च हो सकती है, अगर ऑब्जेक्ट क्रम वाली वैल्यू काफ़ी जटिल होती हैं. क्योंकि यह प्रोसेस मुख्य थ्रेड पर होती है कॉन्फ़िगरेशन में बदलाव के दौरान, लंबे समय तक चलने वाले सीरियलाइज़ेशन की वजह से, फ़्रेम और विज़ुअल स्टटर को ट्रैक कर सकते हैं.

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

आपके ऐप्लिकेशन के इस्तेमाल के उदाहरणों के आधार पर, हो सकता है कि आपको सेव किए गए इंस्टेंस को इस्तेमाल करने की ज़रूरत न पड़े बिलकुल भी नहीं. उदाहरण के लिए, कोई ब्राउज़र उपयोगकर्ता को ठीक ब्राउज़र से बाहर निकलने से पहले वे जिस वेबपेज को देख रहे थे. अगर आपकी गतिविधि इस तरह से काम करता है, तो सेव की गई इंस्टेंस स्थिति का इस्तेमाल करके छोड़ दिया जा सकता है और इसके बजाय इसे बनाए रखा जा सकता है स्थानीय रूप से सब कुछ किया जा सकता है.

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

इनमें से किसी भी स्थिति में, आपको अब भी ViewModel का इस्तेमाल करना चाहिए, ताकि कॉन्फ़िगरेशन में बदलाव के दौरान, डेटाबेस से डेटा को फिर से लोड करने में समय बर्बाद होता है.

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

SafeStateRegistry का इस्तेमाल करके, सेव की गई स्थिति में बदलाव करें

फ़्रैगमेंट 1.1.0 या इसकी ट्रांज़िटिव डिपेंडेंसी गतिविधि से शुरू होना 1.0.0, यूज़र इंटरफ़ेस (यूआई) कंट्रोलर, जैसे कि Activity या Fragment, लागू करते हैं SavedStateRegistryOwner और SavedStateRegistry की जानकारी दें, उस कंट्रोलर से बंधा होता है. SavedStateRegistry, कॉम्पोनेंट को इस्तेमाल करने या उसमें योगदान देने के लिए आपके यूज़र इंटरफ़ेस (यूआई) कंट्रोलर की सेव की गई स्थिति. उदाहरण के लिए, ViewModel के लिए सेव किया गया स्टेट मॉड्यूल, SavedStateRegistry का इस्तेमाल करके SavedStateHandle और इसे अपने ViewModel ऑब्जेक्ट को दें. वापस लाए जा सकते हैं कॉल करके अपने यूज़र इंटरफ़ेस (यूआई) कंट्रोलर से SavedStateRegistry को ऐक्सेस करें getSavedStateRegistry().

सेव की गई स्थिति में योगदान करने वाले कॉम्पोनेंट लागू करने होंगे SavedStateRegistry.SavedStateProvider, जो एक तरीके के बारे में बताता है saveState() पर कॉल किया. saveState() तरीका, आपके कॉम्पोनेंट को ये काम करने की अनुमति देता है एक Bundle दिखाएं, जिसमें उस कॉम्पोनेंट से सेव की जाने वाली किसी भी स्थिति का इस्तेमाल किया गया हो. यूज़र इंटरफ़ेस (यूआई) की सेव की स्थिति वाले चरण के दौरान, SavedStateRegistry इस तरीके को कॉल करता है कंट्रोलर का लाइफ़साइकल किया होता है.

class SearchManager : SavedStateRegistry.SavedStateProvider {
    companion object {
        private const val QUERY = "query"
    }

    private val query: String? = null

    ...

    override fun saveState(): Bundle {
        return bundleOf(QUERY to query)
    }
}

class SearchManager implements SavedStateRegistry.SavedStateProvider {
    private static String QUERY = "query";
    private String query = null;
    ...

    @NonNull
    @Override
    public Bundle saveState() {
        Bundle bundle = new Bundle();
        bundle.putString(QUERY, query);
        return bundle;
    }
}

SavedStateProvider को रजिस्टर करने के लिए, इस नंबर पर registerSavedStateProvider() को कॉल करें SavedStateRegistry, जिससे कंपनी के डेटा से कनेक्ट करने के लिए एक कुंजी पास की जा रही है: . सेवा देने वाली कंपनी के लिए, पहले से सेव किया गया डेटा consumeRestoredStateForKey() को कॉल करने पर सेव की गई स्थिति से वापस लाया गया SavedStateRegistry पर, जो कंपनी की डेटा शामिल है.

Activity या Fragment की मदद से, आप SavedStateProvider में रजिस्टर कर सकते हैं super.onCreate() पर कॉल करने के बाद onCreate(). वैकल्पिक रूप से, आप एक SavedStateRegistryOwner पर LifecycleObserver, जो लागू करता है LifecycleOwner और SavedStateProvider को ON_CREATE इवेंट होता है. LifecycleObserver का इस्तेमाल करके, पहले से सेव की गई स्थिति का रजिस्ट्रेशन और उसे वापस पाना SavedStateRegistryOwner.

class SearchManager(registryOwner: SavedStateRegistryOwner) : SavedStateRegistry.SavedStateProvider {
    companion object {
        private const val PROVIDER = "search_manager"
        private const val QUERY = "query"
    }

    private val query: String? = null

    init {
        // Register a LifecycleObserver for when the Lifecycle hits ON_CREATE
        registryOwner.lifecycle.addObserver(LifecycleEventObserver { _, event ->
            if (event == Lifecycle.Event.ON_CREATE) {
                val registry = registryOwner.savedStateRegistry

                // Register this object for future calls to saveState()
                registry.registerSavedStateProvider(PROVIDER, this)

                // Get the previously saved state and restore it
                val state = registry.consumeRestoredStateForKey(PROVIDER)

                // Apply the previously saved state
                query = state?.getString(QUERY)
            }
        }
    }

    override fun saveState(): Bundle {
        return bundleOf(QUERY to query)
    }

    ...
}

class SearchFragment : Fragment() {
    private var searchManager = SearchManager(this)
    ...
}

class SearchManager implements SavedStateRegistry.SavedStateProvider {
    private static String PROVIDER = "search_manager";
    private static String QUERY = "query";
    private String query = null;

    public SearchManager(SavedStateRegistryOwner registryOwner) {
        registryOwner.getLifecycle().addObserver((LifecycleEventObserver) (source, event) -> {
            if (event == Lifecycle.Event.ON_CREATE) {
                SavedStateRegistry registry = registryOwner.getSavedStateRegistry();

                // Register this object for future calls to saveState()
                registry.registerSavedStateProvider(PROVIDER, this);

                // Get the previously saved state and restore it
                Bundle state = registry.consumeRestoredStateForKey(PROVIDER);

                // Apply the previously saved state
                if (state != null) {
                    query = state.getString(QUERY);
                }
            }
        });
    }

    @NonNull
    @Override
    public Bundle saveState() {
        Bundle bundle = new Bundle();
        bundle.putString(QUERY, query);
        return bundle;
    }

    ...
}

class SearchFragment extends Fragment {
    private SearchManager searchManager = new SearchManager(this);
    ...
}

जटिल या बड़े डेटा के लिए, लोकल परसिस्टेंस का इस्तेमाल करें और प्रोसेस बंद होने की प्रोसेस को मैनेज करें

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

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

यूज़र इंटरफ़ेस (यूआई) की स्थिति को मैनेज करना: भाग दें और जीतें

आप कार्य को परसिस्टेंस मैकेनिज़्म होता है. ज़्यादातर मामलों में, इनमें से हर एक तरीके को को गतिविधि में इस्तेमाल होने वाला अलग तरह का डेटा सेव करना चाहिए. डेटा की जटिलता, ऐक्सेस की स्पीड, और लाइफ़टाइम में होने वाले बदलाव:

• लोकल परसिस्टेंस: इसमें कोई भी ऐसा सभी ऐप्लिकेशन डेटा स्टोर होता है जिसे आपको खोने से बचाना है आप गतिविधि को खोलते और बंद करते हैं.
  • उदाहरण: गाने से जुड़े ऑब्जेक्ट का कलेक्शन, जिसमें ऑडियो फ़ाइलें शामिल हो सकती हैं और मेटाडेटा.
• ViewModel: यह रिपोर्ट दिखाने के लिए ज़रूरी सारा डेटा, मेमोरी में सेव करता है यूज़र इंटरफ़ेस (यूआई), स्क्रीन के यूज़र इंटरफ़ेस (यूआई) की स्थिति.
  • उदाहरण: हाल ही में की गई खोज और हाल ही में खोजी गई जानकारी के गाने से जुड़े ऑब्जेक्ट खोज क्वेरी.
• सेव किए गए इंस्टेंस की स्थिति: फिर से लोड करने के लिए ज़रूरी डेटा का कुछ हिस्सा सेव करता है यूज़र इंटरफ़ेस (यूआई) की स्थिति, जब सिस्टम बंद हो जाता है और फिर से यूज़र इंटरफ़ेस (यूआई) बनाता है. सेव करने के बजाय यहां जटिल ऑब्जेक्ट, लोकल स्टोरेज और स्टोर में कॉम्प्लेक्स ऑब्जेक्ट बने रहते हैं सेव की गई इंस्टेंस स्टेट एपीआई में इन ऑब्जेक्ट के लिए एक यूनीक आईडी.
  • उदाहरण: सबसे हाल की खोज क्वेरी को स्टोर करना.

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

जब कोई उपयोगकर्ता कोई गाना जोड़ता है, तो ViewModel मौजूदा सदस्य को तुरंत उस गाने का ऐक्सेस देता है स्थानीय तौर पर इस डेटा. अगर यूज़र इंटरफ़ेस (यूआई) में जोड़ा गया यह नया गाना दिखाना है, तो को भी जोड़ा जाना चाहिए, ताकि ViewModel ऑब्जेक्ट में डेटा को भी अपडेट किया जा सके गाने. मुख्य थ्रेड से सभी डेटाबेस डालना न भूलें.

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

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

पेचीदा स्थितियों को पहले जैसा करना: टुकड़ों को फिर से जोड़ना

जब उपयोगकर्ता को गतिविधि पर वापस लौटना होता है, तो ये दो गतिविधि को फिर से बनाने की स्थिति:

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

अन्य संसाधन

यूज़र इंटरफ़ेस (यूआई) की स्थितियों को सेव करने के बारे में ज़्यादा जानने के लिए, नीचे दिए गए संसाधन देखें.

• यूज़र इंटरफ़ेस (यूआई) लेयर से जुड़ा दस्तावेज़
• State और Jetpack Compose के दस्तावेज़

ब्लॉग

• ViewModels: एक आसान उदाहरण
• ViewModels: परसिस्टेंस, onSaveInstanceState(), यूआई स्टेट को पहले जैसा करना और लोडर
• Android की लाइफ़साइकल के बारे में बताने वाले कॉम्पोनेंट के लिए कोडलैब (कोड बनाना सीखना)