Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

कॉन्फ़िगरेशन के बदलावों को हैंडल करना

ऐप्लिकेशन के चलने के दौरान, कुछ डिवाइस कॉन्फ़िगरेशन बदल सकते हैं. इनमें ये शामिल हैं, लेकिन ये इन्हीं तक सीमित नहीं हैं:

ऐप्लिकेशन के डिसप्ले का साइज़
स्क्रीन डेंसिटी (डिसप्ले स्केलिंग)
स्क्रीन की दिशा
फ़ॉन्ट का साइज़ और मोटाई
स्थान-भाषा
गहरे रंग वाली थीम बनाम हल्के रंग वाली थीम
कीबोर्ड की उपलब्धता

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

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

ऐक्टिविटी को फिर से बनाना

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

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

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

मनोरंजन का उदाहरण

एक ऐसे कंपोज़ेबल पर विचार करें जो स्ट्रिंग रिसॉर्स का इस्तेमाल करके स्टैटिक टाइटल दिखाता है:

// In the res/values/strings.xml file
// <string name="compose">Jetpack Compose</string>

// In your Compose code
Text(
    text = stringResource(R.string.compose)
)ResourcesSnippets.kt

Activity बनने पर, Text कंपोज़ेबल मौजूदा कॉन्फ़िगरेशन (जैसे, भाषा) को पढ़ता है और सही स्ट्रिंग रिसॉर्स को रिज़ॉल्व करता है.

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

फिर से बनाने पर, Activity में फ़ील्ड के तौर पर सेव की गई कोई भी स्थिति मिट जाती है.

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

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

उपयोगकर्ता की उम्मीदें

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

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

डिवाइस को घुमाना
मल्टी-विंडो मोड में जाना
मल्टी-विंडो मोड या फ़्री-फ़ॉर्म विंडो में ऐप्लिकेशन का साइज़ बदलना
एक से ज़्यादा डिसप्ले वाले फ़ोल्डेबल डिवाइस को फ़ोल्ड किया जा रहा है
सिस्टम सेटिंग में जाकर, डिसप्ले साइज़ या डिसप्ले स्केलिंग को बदलना
ऐप्लिकेशन को अलग-अलग स्क्रीन डेंसिटी वाले डिसप्ले के बीच मूव करना. जैसे, कनेक्ट किए गए बाहरी मॉनिटर या फ़ोल्ड किए जा सकने वाले डिवाइस के डिसप्ले
सिस्टम की थीम बदलना, जैसे कि गहरे रंग वाली थीम से हल्के रंग वाली थीम पर स्विच करना
फ़ॉन्ट का साइज़ बदलना
सिस्टम या ऐप्लिकेशन की भाषा बदलना
हार्डवेयर कीबोर्ड को कनेक्ट या डिसकनेक्ट करना
डॉक को कनेक्ट या डिसकनेक्ट करना

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

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

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

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

गतिविधि को फिर से बनाने पर पाबंदी लगाएं

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

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

कॉन्फ़िगरेशन में हुए बदलावों को सीधे Compose में मैनेज करने के कई फ़ायदे हैं:

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

कॉन्फ़िगरेशन में किए गए कुछ खास बदलावों के लिए, गतिविधि को फिर से बनाने की सुविधा बंद करने के लिए, कॉन्फ़िगरेशन टाइप को android:configChanges में जोड़ें. इसके लिए, अपनी AndroidManifest.xml फ़ाइल में <activity> एंट्री में जाएं. संभावित वैल्यू, android:configChanges एट्रिब्यूट के दस्तावेज़ में दिखती हैं.

यहां दिया गया मेनिफ़ेस्ट कोड, स्क्रीन ओरिएंटेशन और कीबोर्ड की उपलब्धता में बदलाव होने पर, MyActivity के लिए Activity को फिर से बनाने की सुविधा बंद कर देता है:

<activity
    android:name=".MyActivity"
    android:configChanges="orientation|screenSize|screenLayout|keyboardHidden"
    android:label="@string/app_name">

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

Android 17

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

CONFIG_KEYBOARD
CONFIG_KEYBOARD_HIDDEN
CONFIG_NAVIGATION
CONFIG_TOUCHSCREEN
CONFIG_COLOR_MODE
CONFIG_UI_MODE (सिर्फ़ तब, जब यूज़र इंटरफ़ेस (यूआई) मोड UI_MODE_TYPE_DESK में बदलता है या UI_MODE_TYPE_DESK से किसी दूसरे टाइप में बदलता है)

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

<activity
    android:name=".MyActivity"
    android:recreateOnConfigChanges="keyboard|keyboardHidden|navigation|colorMode|touchscreen|...">
    ...
</activity>

कॉन्फ़िगरेशन में हुए बदलावों पर प्रतिक्रिया देना

Jetpack Compose की मदद से, आपका ऐप्लिकेशन कॉन्फ़िगरेशन में हुए बदलावों पर ज़्यादा आसानी से प्रतिक्रिया दे सकता है. हालांकि, अगर आपने कॉन्फ़िगरेशन में होने वाले सभी बदलावों के लिए, Activity को फिर से बनाने की सुविधा बंद कर दी है, तो भी आपके ऐप्लिकेशन को कॉन्फ़िगरेशन में होने वाले बदलावों को सही तरीके से मैनेज करना होगा.

Configuration ऑब्जेक्ट, Compose यूज़र इंटरफ़ेस (यूआई) की हैरारकी में LocalConfiguration कंपोज़िशन लोकल के साथ उपलब्ध है. जब भी इसमें बदलाव होता है, तब LocalConfiguration.current से डेटा फ़ेच करने वाले कंपोज़ेबल फ़ंक्शन फिर से कंपोज़ होते हैं. CompositionLocal के काम करने के तरीके के बारे में जानने के लिए, CompositionLocal की मदद से, स्थानीय तौर पर स्कोप किया गया डेटा देखें.

अहम जानकारी: जैसा कि Activity को फिर से बनाने पर पाबंदी लगाएं सेक्शन में बताया गया है, Android ऐप्लिकेशन में Activity को फिर से बनाने की सुविधा को पूरी तरह से बंद नहीं किया जा सकता. इसलिए, जब सिस्टम किसी Activity को फिर से बनाता है, तब भी स्टेट को सही तरीके से सेव करना ज़रूरी होता है. इसके अलावा, इंटरऑपरेबिलिटी एपीआई (जैसे, AndroidView) की मदद से Compose में एम्बेड किए गए व्यू, कॉन्फ़िगरेशन में बदलाव होने पर Activity को फिर से बना सकते हैं. कॉन्फ़िगरेशन में बदलाव होने की वजह से, ऐप्लिकेशन बनाने की सुविधा फिर से कंपोज़ होती है. हालांकि, इंटरऑपरेबिलिटी एपीआई में इस्तेमाल किए गए व्यू फिर से नहीं बनाए जाते.

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

उदाहरण

यहां दिए गए उदाहरण में, कंपोज़ेबल किसी तारीख को खास फ़ॉर्मैट में दिखाता है. कंपोज़ेबल, सिस्टम की स्थान-भाषा के कॉन्फ़िगरेशन में हुए बदलावों पर प्रतिक्रिया देता है. इसके लिए, वह LocalConfiguration.current के साथ ConfigurationCompat.getLocales को कॉल करता है.

@Composable
fun DateText(year: Int, dayOfYear: Int) {
    val dateTimeFormatter = DateTimeFormatter.ofPattern(
        "MMM dd",
        ConfigurationCompat.getLocales(LocalConfiguration.current)[0]
    )
    Text(
        dateTimeFormatter.format(LocalDate.ofYearDay(year, dayOfYear))
    )
}

लोकेल बदलने पर Activity को फिर से बनाने से बचने के लिए, Compose कोड को होस्ट करने वाले Activity को लोकेल कॉन्फ़िगरेशन में होने वाले बदलावों से ऑप्ट आउट करना होगा. ऐसा करने के लिए, android:configChanges को locale|layoutDirection पर सेट करें.

चेतावनी: कंपोज़ किए जा सकने वाले फ़ंक्शन को फिर से कंपोज़ करने के लिए, रीड स्टेट State टाइप की होनी चाहिए. कॉन्फ़िगरेशन से जुड़े कंपोज़िशन लोकल और खास तौर पर LocalConfiguration के मामले में ऐसा होता है. Compose में Locale.getDefault का इस्तेमाल करके मौजूदा स्थान-भाषा को पढ़ने की कोशिश करने पर, कंपोज़ेबल फिर से कंपोज़ नहीं होता. साथ ही, कॉन्फ़िगरेशन में हुए बदलावों पर कोई प्रतिक्रिया नहीं देता. ऐसा इसलिए है, क्योंकि यह State टाइप का नहीं है. Compose में स्टेट के बारे में ज़्यादा जानने के लिए, स्टेट और Jetpack Compose देखें.

कॉन्फ़िगरेशन में बदलाव: मुख्य कॉन्सेप्ट और सबसे सही तरीके

कॉन्फ़िगरेशन में बदलाव करते समय, आपको इन मुख्य बातों का ध्यान रखना चाहिए:

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

उपयोगकर्ताओं को बेहतर अनुभव देने के लिए, यहां दिए गए सबसे सही तरीके अपनाएं:

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

साइज़ के हिसाब से कॉन्फ़िगरेशन में होने वाले बदलावों को मैनेज करना

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

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

साइज़ के हिसाब से कॉन्फ़िगरेशन में होने वाले बदलावों के लिए, गतिविधि को फिर से बनाने पर पाबंदी लगाएं

साइज़ के आधार पर कॉन्फ़िगरेशन में होने वाले बदलावों के लिए, Activity को फिर से बनाने की सुविधा बंद करने पर, सिस्टम Activity को फिर से नहीं बनाता. इसके बजाय, इसे Activity.onConfigurationChanged पर कॉल मिलता है. LocalConfiguration.current को पढ़ने वाले सभी कंपोज़ेबल, नए साइज़ के हिसाब से अपने-आप फिर से कंपोज़ हो जाते हैं.

अगर आपकी मेनिफ़ेस्ट फ़ाइल में android:configChanges="screenSize|smallestScreenSize|orientation|screenLayout" है, तो साइज़ के आधार पर कॉन्फ़िगरेशन में बदलाव करने के लिए, Activity को फिर से बनाने की सुविधा बंद हो जाती है.

अन्य संसाधन

कॉन्फ़िगरेशन में होने वाले बदलावों को मैनेज करने के बारे में ज़्यादा जानने के लिए, ये अतिरिक्त संसाधन देखें:

दस्तावेज़

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

कॉन्टेंट देखना

कॉन्फ़िगरेशन में हुए बदलावों को मैनेज करना (व्यू)