इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

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

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

गतिविधि से जुड़ी जानकारी

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

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

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

एक ऐसे TextView पर विचार करें जो लेआउट एक्सएमएल फ़ाइल में बताए गए android:text="@string/title" का इस्तेमाल करके, कोई स्टैटिक टाइटल दिखाता है. व्यू बनाने पर, यह मौजूदा भाषा के आधार पर टेक्स्ट को सिर्फ़ एक बार सेट करता है. अगर भाषा बदल जाती है, तो सिस्टम गतिविधि को फिर से बनाता है. इसलिए, सिस्टम भी व्यू को फिर से बनाता है और नई भाषा के आधार पर उसे सही वैल्यू पर शुरू करता है.

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

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

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

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

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

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

Activity रीक्रिएशन की मदद से, काम की स्थिति को बनाए रखने के लिए, ये तीन मुख्य तरीके अपनाए जा सकते हैं. किसका इस्तेमाल करना है, यह इस बात पर निर्भर करता है कि आपको किस तरह की स्थिति को बनाए रखना है:

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

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

गतिविधि के तौर पर मनोरंजन पर पाबंदी लगाना

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

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

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

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

कॉन्फ़िगरेशन में कुछ बदलाव करने पर, गतिविधि हमेशा रीस्टार्ट हो जाती है. इन्हें बंद नहीं किया जा सकता. उदाहरण के लिए, Android 12L (एपीआई लेवल 32) में पेश किए गए डाइनैमिक कलर बदलने की सुविधा को बंद नहीं किया जा सकता.

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

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

View सिस्टम में, जब कॉन्फ़िगरेशन में ऐसा बदलाव होता है जिसके लिए आपने Activity को फिर से बनाने की सुविधा बंद की है, तो ऐक्टिविटी को Activity.onConfigurationChanged() को कॉल करने के लिए कहा जाता है. अटैच किए गए किसी भी व्यू को भी View.onConfigurationChanged() पर कॉल भेजा जाता है. android:configChanges में जोड़े गए कॉन्फ़िगरेशन में बदलाव न करने पर, सिस्टम गतिविधि को फिर से बनाता है.

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

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

उदाहरण के लिए, यहां दिया गया onConfigurationChanged() लागू करने का तरीका यह जांचता है कि कीबोर्ड उपलब्ध है या नहीं:

Kotlin

override fun onConfigurationChanged(newConfig: Configuration) {
    super.onConfigurationChanged(newConfig)

    // Checks whether a keyboard is available
    if (newConfig.keyboardHidden === Configuration.KEYBOARDHIDDEN_YES) {
        Toast.makeText(this, "Keyboard available", Toast.LENGTH_SHORT).show()
    } else if (newConfig.keyboardHidden === Configuration.KEYBOARDHIDDEN_NO) {
        Toast.makeText(this, "No keyboard", Toast.LENGTH_SHORT).show()
    }
}

Java

@Override
public void onConfigurationChanged(Configuration newConfig) {
    super.onConfigurationChanged(newConfig);

    // Checks whether a keyboard is available
    if (newConfig.keyboardHidden == Configuration.KEYBOARDHIDDEN_YES) {
        Toast.makeText(this, "Keyboard available", Toast.LENGTH_SHORT).show();
    } else if (newConfig.keyboardHidden == Configuration.KEYBOARDHIDDEN_NO){
        Toast.makeText(this, "No keyboard", Toast.LENGTH_SHORT).show();
    }
}

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

डेटा को बनाए रखना

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

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

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

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

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

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

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

उदाहरण

नीचे दिए गए उदाहरण में, एक कॉम्पोज़ेबल किसी खास फ़ॉर्मैट में तारीख दिखाता है. यह कॉम्पोनेंट, 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 के मामले में होता है. Locale.getDefault() का इस्तेमाल करके Compose में मौजूदा स्थानीय भाषा को पढ़ने की कोशिश करने पर, कॉम्पोज़ेबल फिर से कॉम्पोज़ नहीं होता और कॉन्फ़िगरेशन में हुए बदलावों पर प्रतिक्रिया नहीं देता. ऐसा इसलिए है, क्योंकि यह State टाइप का नहीं है. Compose में स्टेट के बारे में ज़्यादा जानने के लिए, स्टेट और Jetpack Compose लेख पढ़ें.

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

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

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

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

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

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

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

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

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

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

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

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

Android 7.0 (एपीआई लेवल 24) और इसके बाद के वर्शन पर, Activity साइज़ के आधार पर कॉन्फ़िगरेशन में होने वाले बदलावों के लिए, सिर्फ़ तब फिर से साइज़ तय किया जाता है, जब साइज़ में काफ़ी बदलाव होता है. जब सिस्टम, साइज़ कम होने की वजह से Activity को फिर से नहीं बनाता है, तो हो सकता है कि वह इसके बजाय Activity.onConfigurationChanged() और View.onConfigurationChanged() को कॉल करे.

Activity को फिर से न बनाने पर, Activity और View कॉलबैक के बारे में कुछ बातों का ध्यान रखना चाहिए:

Android 11 (एपीआई लेवल 30) से लेकर Android 13 (एपीआई लेवल 33) तक, Activity.onConfigurationChanged() को कॉल नहीं किया जाता.
एक समस्या है, जिसकी वजह से हो सकता है कि Android 12L (एपीआई लेवल 32) और Android 13 (एपीआई लेवल 33) के शुरुआती वर्शन पर, कुछ मामलों में View.onConfigurationChanged() को कॉल न किया जाए. ज़्यादा जानकारी के लिए, यह सार्वजनिक समस्या देखें. हालांकि, Android 13 के बाद के रिलीज़ और Android 14 में इस समस्या को ठीक कर दिया गया है.

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