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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ध्यान दें: ऊपर दी गई टेबल में, सेव किए गए इंस्टेंस की स्थिति में onSaveInstanceState() और rememberSaveable एपीआई और SavedStateHandle का हिस्सा है.

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

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

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

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

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

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

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

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

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

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

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

ध्यान दें: Android, मेमोरी में डेटा की एक सीरियल कॉपी को, आपके स्टोर के प्रोसेस. सिस्टम, अलग-अलग फ़ैक्टर के आधार पर इसे ऑप्टिमाइज़ करने की कोशिश कर सकता है प्रोसेस करें और उसी बंडल ऑब्जेक्ट को मेमोरी में छोड़ दें और झटपट ऐक्सेस शामिल है. हालांकि, ये काम Android API के सभी वर्शन में बदल सकते हैं.

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

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

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

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

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

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

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

ध्यान दें: rememberSaveable के बारे में ज़्यादा जानने के लिए, State और Jetpack देखें दस्तावेज़ लिखें.

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

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

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

अहम जानकारी: SavedStateHandle में लिखा गया डेटा सिर्फ़ तब सेव किया जाता है, जब Activity को रोक दिया गया है. Activity के होने पर SavedStateHandle को लिखता है रोक तब तक सेव नहीं की जाती, जब तक Activity को onStart के बाद फिर से onStop.

Kotlin

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

Java

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.

Kotlin

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

Java

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);
    ...
}

ध्यान दें: SavedStateRegistry डेटा को उसी Bundle में सेव करता है जिसमें अन्य डेटा सेव है इंस्टेंस स्टेट एपीआई के लिए बनाया गया है, इसलिए वही बातें और डेटा सीमाएं लागू करें.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अन्य संसाधन

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

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

ब्लॉग

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