हमेशा एंड्रॉइड का उपयोग क्यों न करें: configChanges = "keyboardHidden | ओरिएंटेशन"?


178

मैं सोच रहा था कि android:configChanges="keyboardHidden|orientation"हर (लगभग हर?) गतिविधि में उपयोग क्यों नहीं होता ?

माल:

  • अपनी गतिविधि के बारे में चिंता करने की कोई जरूरत नहीं है
  • यह तेज है

इतना अच्छा नही है:

  • अपने लेआउट को बदलने की जरूरत है अगर वे स्क्रीन के आकार पर निर्भर हैं (जैसे दो स्तंभ या तो लेआउट के साथ)

खराब:

  • अलग-अलग अभिविन्यास पर अलग-अलग लेआउट के लिए कोई लचीला तरीका नहीं है
  • टुकड़ों का उपयोग करते समय इतना अच्छा नहीं है

लेकिन अगर हम अलग-अलग लेआउट का उपयोग नहीं करते हैं, तो क्यों नहीं?


6
आप यह भी समझाना चाहिए कि तुम क्या लगता है keyboardHidden | उन्मुखीकरण कर रही है
ब्लंडेल

यह निर्दिष्ट कॉन्फ़िगरेशन परिवर्तनों के मूल हैंडलिंग का उपयोग करने से रोक रहा है और एप्लिकेशन को इसे संभालने की अनुमति देता है, है न?
मिकोस

2
इसलिए यह विकल्प है, यदि आप जानते हैं कि आप क्या कर रहे हैं (संसाधनों में कोई बदलाव नहीं), तो इसका उपयोग करें।
पॉइंटर नल

स्क्रीनसेज़ का उपयोग करने से यह तेज़ क्यों है?
बैटमासी

जवाबों:


334

त्वरित पृष्ठभूमि

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

जब आप android:configChanges="keyboardHidden|orientation"अपने AndroidManifest में परिभाषित करते हैं, तो आप Android से कह रहे हैं: "कृपया कीबोर्ड रीसेट करने पर डिफ़ॉल्ट रीसेट न करें, या फ़ोन घुमाया जाए; मैं इसे स्वयं हैंडल करना चाहता हूँ। हाँ, मुझे पता है कि मैं क्या कर रहा हूँ। "

क्या यह अच्छी चीज है? हम जल्द ही देखेंगे ...

कोई चिंता नहीं?

आपके द्वारा शुरू किए जाने वाले पेशेवरों में से एक यह है:

अपनी गतिविधि के बारे में चिंता करने की कोई जरूरत नहीं है

कई मामलों में, लोग गलती से मानते हैं कि जब उनके पास एक त्रुटि है जो एक अभिविन्यास परिवर्तन ("रोटेशन") द्वारा उत्पन्न हो रही है, तो वे बस इसे डालकर ठीक कर सकते हैं android:configChanges="keyboardHidden|orientation"

हालाँकि, android: configChanges = "कीबोर्डहाइंड | ओरिएंटेशन" एक बैंडेड से ज्यादा कुछ नहीं है। सच में, कई तरीके हैं जिनसे कॉन्फ़िगरेशन परिवर्तन को ट्रिगर किया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता एक नई भाषा (यानी स्थान बदल गया है) का चयन करता है, तो आपकी गतिविधि उसी तरह से फिर से शुरू हो जाएगी जैसे यह एक अभिविन्यास परिवर्तन द्वारा करता है। यदि आप चाहें तो आप सभी विभिन्न प्रकार के कॉन्फ़िगरेशन परिवर्तनों की सूची देख सकते हैं

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

दूसरे शब्दों में, का उपयोग android:configChanges="keyboardHidden|orientation"करना आपकी "चिंताओं" का समाधान नहीं है। सही तरीका यह है कि आप अपनी गतिविधियों को कोड करें ताकि वे उन पर किसी भी एंड्रॉइड थ्रो के साथ खुश हों। यह एक अच्छा अभ्यास है जो आपको सड़क को नीचे लाने में मदद करेगा, इसलिए इसकी आदत डालें।

तो मुझे इसका उपयोग कब करना चाहिए?

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

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

हालाँकि , अगर किसी कारण से आप डिवाइस में लैंडस्केप होने पर एक अलग लेआउट का उपयोग करते हैं, तो तथ्य यह है कि एंड्रॉइड आपकी गतिविधि को फिर से लोड करता है क्योंकि यह सही लेआउट को लोड करेगा। [यदि आप इस तरह की गतिविधि पर ओवरराइड का उपयोग करते हैं, और रनटाइम पर कुछ जादुई री-लेआउट करना चाहते हैं ... अच्छा, सौभाग्य - यह सरल से बहुत दूर है]

त्वरित सारांश

हर तरह से, अगर android:configChanges="keyboardHidden|orientation"आपके लिए सही है, तो इसका उपयोग करें। लेकिन यह ज़रूर परखें कि जब कुछ बदलता है, तो क्या होता है, क्योंकि एक अभिविन्यास परिवर्तन ही एकमात्र तरीका नहीं है, जिसे पूर्ण गतिविधि पुनरारंभ किया जा सकता है।


50
यह जोड़ने योग्य है कि आपकी गतिविधि को फिर से शुरू न करने का मतलब है कि आपके पास कम आम कॉन्फ़िगरेशन परिवर्तनों को न संभालने की तुलना में बड़ी समस्याएं हैं। यहां उपयोग की जाने वाली गतिविधि फिर से शुरू होती है, ठीक वैसा ही तंत्र है जैसा कि एंड्रॉइड आपकी गतिविधि को उसकी पिछली स्थिति में पुनर्स्थापित करता है जब आपका ऐप पृष्ठभूमि में मारा जाता है। यदि आप इसे सही तरीके से नहीं कर रहे हैं, तो आपके उपयोगकर्ता बेतरतीब ढंग से पृष्ठभूमि से वापस आने पर आपके ऐप को सही ढंग से वापस नहीं आने का अनुभव करेंगे, यह इस बात पर निर्भर करता है कि क्या प्रक्रिया हुई थी। तो एक बड़ा लाभ: यह सुनिश्चित करता है कि आपका ऐप सही तरीके से पुनरारंभ हो।
हैकबॉड

14
एंड्रॉइड 3.x से "स्क्रीनसेज़" को जोड़ने से न चूकें ---------- Android: configChanges = ["mcc", "mnc", "locale", "touchscreen", "कीबोर्ड", "कीबोर्डहेड", "नेविगेशन", "स्क्रीनलैटआउट", "फॉन्टस्केल", "यूमोड", "ओरिएंटेशन", "स्क्रीनसाइज़", "सबसे छोटा स्क्रीनसेज़"]
माइकल

1
मैंने देखा है कि जब आप configChanges विशेषता का उपयोग करते हैं, तो आपका ऐप ओरिएंटेशन-लॉक सुविधा को भी अनदेखा करता है। आप इसे कैसे हल कर सकते हैं? यदि आप इसका उत्तर जानते हैं, तो कृपया इसे यहाँ लिखें: stackoverflow.com/questions/24000361/…
android डेवलपर

4
Please don't do the default reset when the keyboard is pulled outमैंने कभी भी कीबोर्ड पुल आउट के लिए एक्टिविटी रीस्टार्ट नहीं देखी !
मुहम्मद बाबर

अच्छी तरह से कभी-कभी पुनरारंभ मेरी राय में ठीक है ... configChanges मेरे लिए अधिकांश मामलों को संभालता है ... अच्छी तरह से शायद अनुप्रयोगों में कुछ अन्य प्रकार में यह समस्या हो सकती है, लेकिन यह वास्तव में निर्भर करता है ....
रेनेटिक

2

मेरे दृष्टिकोण से: यदि लेआउट लैंडस्केप और पोर्ट्रेट मोड दोनों में समान है - तो आप अपने ऐप में दो में से एक को अक्षम कर सकते हैं।

इस कारण से कि मैं यह बताता हूं कि मैं एक उपयोगकर्ता के रूप में उम्मीद करता हूं कि जब मैं अभिविन्यास बदलूं तो ऐप मुझे कुछ लाभ प्रदान करे। अगर इससे कोई फर्क नहीं पड़ता कि मैं अपना फोन कैसे रखता हूं, तो मुझे विकल्प की जरूरत नहीं है।

उदाहरण के लिए एक ऐप लें, जहाँ आपके पास एक सूची दृश्य है, और एक सूची पर क्लिक करने पर आप उस आइटम के लिए एक विस्तृत दृश्य दिखाना चाहते हैं। परिदृश्य में आप स्क्रीन को दो में विभाजित करके इसे छोड़ देंगे, दाईं ओर सूची दृश्य और दाईं ओर विस्तृत दृश्य। पोर्ट्रेट में आपके पास एक स्क्रीन में सूची होगी और फिर एक ListItem चयनित होने पर स्क्रीन को विस्तृत दृश्य में बदल दें। उस मामले में अभिविन्यास परिवर्तन समझ में आता है और साथ ही विभिन्न लेआउट।


4
हाँ, हम अपने ऐप्पल रिलीज़ को मैच करने के लिए, हमारे ऐप के संस्करण 1.0 में गए थे। यह केवल चित्र में प्रस्तुत किया गया था। जो मेरे Droid X पर बहुत अच्छा लग रहा था, हमने IOS संस्करण के पॉपअप कीबोर्ड व्यवहार से बिल्कुल मिलान किया। तब सीएफओ ने ऐप को अपने Droid पर स्थापित किया, इसे किनारे की ओर घुमाया और कीबोर्ड को खोल दिया। उफ़। एंड्रॉइड के बारे में बात यह एक खुला मंच है और आप वास्तव में हार्डवेयर कॉन्फ़िगरेशन की भविष्यवाणी नहीं कर सकते हैं या उपयोगकर्ता इसके साथ क्या करना चाहते हैं, इसलिए आपको बस मामले में दोनों (सभी) झुकावों का समर्थन करना चाहिए।
Tevo D

1
जो संयोगवश हमारी पोट्रेट-ओनली सेटिंग को ओवरराइड करता है क्योंकि यह मूल रूप से हार्डवेयर में था कि परिदृश्य तब सामान्य था, वैकल्पिक नहीं, अभिविन्यास। जो वास्तव में हमारे लेआउट गड़बड़ कर दिया :( और बहुत शर्मनाक था, उसके कुछ ही सेकंड के भीतर एक बड़ी खराबी एप्लिकेशन को स्थापित करने में
Tevo D

1
आप इसे आईओएस की तरह व्यवहार करने की कोशिश क्यों कर रहे थे? :(
फूंकमोंक

7
@FunkTheMonk दुर्भाग्य से हम एक ऐसी दुनिया में रहते हैं जहाँ व्यवसायी तकनीकी निर्णय लेते हैं। यहां तक ​​कि अगर आप इसके खिलाफ बहस करते हैं, तो भी आधा समय वे सोचते हैं कि वे सही हैं। और वे आपकी तनख्वाह को नियंत्रित करते हैं।
स्टैकऑवरफ्लो

2
केवल एक लेआउट का उपयोग करने का मतलब यह नहीं है कि घुमाए जाने पर स्क्रीन समान दिखाई देगी। एक अच्छी तरह से संरचित XML लेआउट उचित आयामों के साथ अच्छी तरह से काम करने के लिए चीजों को स्वचालित रूप से चारों ओर स्थानांतरित कर देगा, और उपयोगकर्ता इसकी सराहना करेंगे।
मेलिंडा ग्रीन

-1

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

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

तो मुझे मार डालो, लेकिन मैं इसे अनुप्रयोगों के पार सफलतापूर्वक उपयोग करता हूं ... एंड्रॉइड: configChanges = "लोकेल | कीबोर्ड | कीबोर्ड किया हुआ | अभिविन्यास | स्क्रीनलेयूट | uiMode | screenSize | smallestScreenSize" लेकिन मैं समझता हूं कि कुछ विशेष प्रकार के अनुप्रयोगों में यह नहीं हो सकता है। अच्छा तरीका है, लेकिन अधिकांश एप्लिकेशन इसके ठीक ओके रह सकते हैं।


नमस्ते किसी को इस विषय पर जानकार कृपया मेरे धागे पर एक नज़र हो सकता है: stackoverflow.com/questions/35941585/…? सख्त मदद की जरूरत है।
ल्यूक एलीसन

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

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

गतिविधि अनुबंध (राज्य को बचाने / बहाल करने) का पालन करने की उपेक्षा करना बुरा व्यवहार है, और यह समग्र भयानक सलाह है। प्रक्रिया मृत्यु के खिलाफ परीक्षण करने का प्रयास करें और देखें कि आपका ऐप आपको कहां मिलता है, और यह व्यवहार पूरी तरह से मानक "सामान्य परिस्थिति" है यदि आपका उपयोगकर्ता अपने फोन पर कम से कम 2-3 ऐप का उपयोग करता है और उनके बीच स्विच करता है।
एपिकपांडाफार्स

-3

हाँ, मुझे लगता है कि रुकने से यह खिलाड़ी को रिलीज़ करने की तुलना में जल्दी कर देगा। हालांकि अभी भी विराम है।

अब एक समाधान मिल गया है जो गीत को विराम नहीं देगा।

यह प्रकट करने की स्थिति में कि आप स्क्रीन अभिविन्यास के लिए कॉन्फ़िगरेशन परिवर्तन को संभाल लेंगे और फिर लेआउट फ़ाइल को लोड करने के लिए onConfigurationChanged विधि का उपयोग करें। LogCat में ऐसा करके मैं onPause, onCreate और onResume देख सकता हूं, और इसलिए गीत को रोका नहीं गया है।

  1. अभिविन्यास को संभालने के लिए मैनिफ़ेस्ट को अपडेट करें।

    android:configChanges="orientation|screenSize"
  2. इस कोड को जोड़ें

    @Override
    public void onConfigurationChanged(Configuration newConfig) {
        // TODO Auto-generated method stub      
        super.onConfigurationChanged(newConfig);        
        setContentView(R.layout.activity_main);
    }

आपको संगीत चलाने के लिए एक सेवा का उपयोग करना चाहिए। गंभीरता से, आप लोगों को उस कोड को जोड़ने के लिए कह रहे हैं जिसमें अभी भी "// TODO ऑटो-जनरेटेड तरीका स्टब" है। मैला घोल। यह अच्छी तरह से काम नहीं करेगा, आपको अपने सभी संदर्भों को फिर से बनाने की आवश्यकता होगी, और यदि आप नहीं करते हैं तो वे अप्रत्याशित रूप से सबसे अच्छा होने जा रहे हैं।
HaMMeReD
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.