कार चलाने के लिए लाइसेंस, या अनुप्रयोग एकल-गतिविधि क्यों होना चाहिए

8-9 अक्टूबर को होने वाले AppsConf 2018 में , मैंने पूरी तरह से एक गतिविधि में Android एप्लिकेशन बनाने के बारे में एक प्रस्तुति दी। यद्यपि विषय अच्छी तरह से जाना जाता है, इस तरह के विकल्प के बारे में कई पूर्वाग्रह हैं - भीड़ के कमरे और भाषण की पुष्टि के बाद प्रश्नों की संख्या। वीडियो रिकॉर्डिंग के लिए इंतजार न करने के लिए, मैंने भाषण के प्रतिलेख के साथ एक लेख बनाने का फैसला किया।

मैं क्या बताऊंगा

1. मुझे एकल गतिविधि में क्यों और कैसे स्विच करना चाहिए
2. उन कार्यों को हल करने के लिए एक सार्वभौमिक दृष्टिकोण जो आप कई गतिविधि पर हल करने के लिए उपयोग किए जाते हैं
3. मानक व्यावसायिक कार्यों के उदाहरण
4. अड़चनें जहां कोड आमतौर पर ईमानदारी से सब कुछ करने के बजाय उलझा हुआ है

एकल-गतिविधि अधिकार क्यों है?

जीवन चक्र

सभी Android डेवलपर्स एप्लिकेशन की कोल्ड स्टार्ट स्कीम जानते हैं। सबसे पहले, OnCreate को एप्लिकेशन वर्ग पर बुलाया जाता है, फिर पहली गतिविधि का जीवन चक्र क्रिया में प्रवेश करता है।
यदि हमारे आवेदन में कई गतिविधि हैं (और इस तरह के अधिकांश अनुप्रयोग हैं), तो निम्न कार्य होते हैं:

App.onCreate() ActivityA.onCreate() ActivityA.onStart() ActivityA.onResume() ActivityA.onPause() ActivityB.onCreate() ActivityB.onStart() ActivityB.onResume() ActivityA.onStop() 

यह एक्टिवा से एब्सट्रैक्ट एक्टिविटी लॉन्च लॉग है। एक खाली रेखा वह क्षण है जब एक नई स्क्रीन का प्रक्षेपण कहा जाता था। पहली नज़र में, सब कुछ ठीक है। लेकिन अगर हम दस्तावेज़ीकरण की ओर मुड़ते हैं, तो यह स्पष्ट हो जाएगा: यह गारंटी देने के लिए कि स्क्रीन उपयोगकर्ता को दिखाई दे रही है और वह इसके साथ बातचीत कर सकता है, यह प्रत्येक स्क्रीन पर onResume बाद ही संभव है:

 App.onCreate() ActivityA.onCreate() ActivityA.onStart() ActivityA.onResume() <-------- ActivityA.onPause() ActivityB.onCreate() ActivityB.onStart() ActivityB.onResume() <-------- ActivityA.onStop() 

समस्या यह है कि इस तरह के लॉग से आवेदन के जीवन चक्र को समझने में मदद नहीं मिलती है। जब उपयोगकर्ता अभी भी अंदर है, और जब वह पहले से ही किसी अन्य एप्लिकेशन पर स्विच कर चुका है या हमारे और इसी तरह कम से कम। और यह आवश्यक है जब हम व्यापार तर्क को एप्लिकेशन के नियंत्रण रेखा से बांधना चाहते हैं, उदाहरण के लिए, उपयोगकर्ता के आवेदन में रहने के दौरान एक सॉकेट कनेक्शन रखें और बाहर निकलने पर इसे बंद करें

एकल गतिविधि अनुप्रयोग में, सब कुछ सरल है - LC गतिविधि एक LC अनुप्रयोग बन जाती है। किसी भी तर्क के लिए आपको जो कुछ भी चाहिए वह आवेदन की स्थिति में बांधना आसान है।

स्क्रीन लॉन्च करें

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

समस्या यह है कि एक गतिविधि शुरू करना पूरी तरह से अतुल्यकालिक प्रक्रिया है! तत्काल स्टार्ट-अप की कोई गारंटी नहीं है, और इससे भी बदतर, हम प्रक्रिया को नियंत्रित नहीं कर सकते हैं। निश्चित रूप से।

एकल-गतिविधि अनुप्रयोग में, खंड प्रबंधक के साथ काम करते हुए, हम प्रक्रिया को नियंत्रित कर सकते हैं।
transaction.commit() - स्क्रीन को एसिंक्रोनसली स्विच करेगा, जिससे आप एक साथ कई स्क्रीन खोल या बंद कर सकते हैं।
transaction.commitNow() - स्क्रीन को समकालिक रूप से स्विच करता है, अगर आपको इसे स्टैक में जोड़ने की आवश्यकता नहीं है।
fragmentManager.executePendingTransactions () `आपको सभी पहले लॉन्च किए गए लेनदेन को अभी निष्पादित करने की अनुमति देता है।

स्क्रीन स्टैक विश्लेषण

कल्पना करें कि आपके एप्लिकेशन का व्यावसायिक तर्क स्क्रीन की स्टैक की वर्तमान गहराई (उदाहरण के लिए, नेस्टिंग प्रतिबंध) पर निर्भर करता है। या, कुछ प्रक्रिया के अंत में, आपको एक निश्चित स्क्रीन पर लौटने की जरूरत है, और यदि कई समान हैं, तो जड़ के सबसे करीब (श्रृंखला की शुरुआत)।
एक्टिविटी स्टैक कैसे प्राप्त करें? स्क्रीन शुरू करते समय किन मापदंडों को निर्दिष्ट किया जाना चाहिए?

वैसे, गतिविधि लॉन्च विकल्पों के जादू के बारे में:

• आप इरादे में लॉन्च झंडे निर्दिष्ट कर सकते हैं (और उन्हें भी एक साथ मिला सकते हैं, और उन्हें विभिन्न स्थानों से बदल सकते हैं);
• आप प्रदर्शन में लॉन्च पैरामीटर जोड़ सकते हैं, क्योंकि सभी गतिविधि को वहां वर्णित किया जाना चाहिए;
• बाहरी ट्रिगर को संभालने के लिए यहां इंटेंट फिल्टर्स जोड़ें;
• और अंत में मल्टी टास्क के बारे में सोचें, जब गतिविधियां विभिन्न "कार्यों" में चल सकती हैं।

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

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

नोट: नवीनतम संस्करण में, समर्थन पुस्तकालयों ने खंड प्रबंधक के अंदर अंशों की पहुंच को अवरुद्ध कर दिया है, लेकिन यदि आप वास्तव में चाहते हैं, तो यह समस्या हमेशा हल हो सकती है।

स्क्रीन पर केवल एक गतिविधि

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

गतिविधियों को न रखें

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

विरासत

ऐतिहासिक रूप से, गतिविधि में अनावश्यक तर्क की एक बड़ी मात्रा है जो संभवतः आपके लिए उपयोगी नहीं है। उदाहरण के लिए, आपको actionBar , actionBar , action menu और इतने पर काम करने की आवश्यकता है। यह वर्ग को काफी विशाल और भारी बनाता है।

एनिमेशन

शायद, कोई भी गतिविधि के बीच स्विच करते समय एक सरल बदलाव एनीमेशन बना सकता है। यहाँ यह स्पष्ट है कि आपको गतिविधि लॉन्च की अतुल्यकालिकता पर छूट देने की आवश्यकता है, जिसके बारे में हमने पहले बात की थी।
यदि आपको कुछ और दिलचस्प चाहिए, तो आप संक्रमण एनिमेशन के ऐसे उदाहरणों को याद कर सकते हैं जो गतिविधि पर किए गए हैं:

लेकिन एक बड़ी समस्या है: इस एनीमेशन को अनुकूलित करना लगभग असंभव है। यह डिजाइनरों और ग्राहक को खुश करने की संभावना नहीं है।

टुकड़ों के साथ, सब कुछ अलग है। हम दृश्य के पदानुक्रम के स्तर तक सीधे जा सकते हैं और कोई भी एनीमेशन बना सकते हैं जिसकी आप कल्पना कर सकते हैं! यहाँ प्रत्यक्ष प्रमाण:

यदि आप स्रोत कोड को देखते हैं, तो आप पाएंगे कि यह एक नियमित लेआउट पर किया गया है। हां, वहां कोड सभ्य है, लेकिन एनीमेशन हमेशा काफी कठिन होता है, और ऐसा अवसर हमेशा एक प्लस होता है। यदि आपके पास दो गतिविधियां हैं, तो आवेदन में एक सामान्य कंटेनर नहीं है जहां आप इस तरह के बदलाव कर सकते हैं।

कॉन्फिगरेशन ऑन-द-फ्लाई कॉन्फिगर करें

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

एकल-गतिविधि एप्लिकेशन में, एप्लिकेशन संदर्भ में इंस्टॉल किए गए स्थान को बदलना और गतिविधि पर कॉल को recreate() करना पर्याप्त है, बाकी सिस्टम स्वयं ही सब कुछ कर देगा।

अंत में

Google के पास एक नेविगेशन समाधान है, जिसके प्रलेखन में स्पष्ट रूप से कहा गया है कि एकल-गतिविधि अनुप्रयोगों को लिखना उचित है।

इस बिंदु पर, मुझे आशा है कि आपको कोई संदेह नहीं है कि कई गतिविधियों के साथ क्लासिक दृष्टिकोण में कई कमियां हैं, जो कि एंड्रॉइड के असंतोष की सामान्य प्रवृत्ति के पीछे छिपाते हुए, एक अंधे आंख को मोड़ने की प्रथा है।

यदि ऐसा है, तो एकल-गतिविधि अभी तक विकास मानक क्यों नहीं है?

यहाँ मैं अपने अच्छे दोस्त को उद्धृत करूँगा:

एक नई गंभीर परियोजना शुरू करने, किसी भी लीड को दोष देने से डरते हैं और जोखिम भरे निर्णयों से बचते हैं। यह सही है। लेकिन मैं एकल-गतिविधि में परिवर्तन के लिए एक व्यापक योजना प्रदान करने का प्रयास करूंगा।

एकल गतिविधि पर स्विच करना

यदि आप इस एप्लिकेशन का अध्ययन करते हैं, तो आप विशेषता एनिमेशन और व्यवहार से निर्धारित कर सकते हैं कि यह कई गतिविधि पर लिखा गया है। मैं गलत हो सकता है, और सब कुछ कस्टम विचारों पर भी किया गया था, लेकिन यह हमारे तर्क को प्रभावित नहीं करेगा।

अब ध्यान! हम इसे इस तरह करते हैं:

हमने केवल दो परिवर्तन किए: हमने AppActivity क्लास को जोड़ा और FlowFragment के साथ सभी गतिविधि को बदल दिया। प्रत्येक परिवर्तन पर अधिक विस्तार से विचार करें।

क्या AppActivity के लिए जिम्मेदार है:

• टुकड़े के लिए केवल एक कंटेनर होता है
  
  • स्कोप UI ऑब्जेक्ट्स का आरंभीकरण बिंदु है (यह अनुप्रयोग में किया जाता था, जो गलत है, क्योंकि, उदाहरण के लिए, हमारे आवेदन में सेवा वस्तुओं को निश्चित रूप से ऐसी वस्तुओं की आवश्यकता नहीं है)
  • एक एप्लिकेशन प्रदाता है
  • एकल गतिविधि के सभी लाभ लाता है।

फ़्लोफ़्रेगमेंट क्या है:

• गतिविधि के समान ही कार्य करता है, जिसके बजाय इसे बनाया गया था।

नया नेविगेशन

पुराने दृष्टिकोण से मुख्य अंतर नेविगेशन है।

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

इसी तरह बैक बटन की प्रोसेसिंग के साथ। पहले, गतिविधि ने वर्तमान टुकड़े को घटना को पारित कर दिया, और अगर यह इसे संसाधित नहीं करता है, तो इसने स्वयं निर्णय लिया। अब AppActivity ईवेंट को वर्तमान फ़्लोफ़्रेग्मेंट में भेजता है, और वह बदले में, इसे वर्तमान फ़्रेग्मेंट में भेजता है।

स्क्रीन के बीच परिणाम स्थानांतरण

अनुभवहीन डेवलपर्स के लिए, स्क्रीन के बीच डेटा स्थानांतरित करने का मुद्दा नए दृष्टिकोण की मुख्य समस्या है, क्योंकि इससे पहले startActivityForResult () कार्यक्षमता का उपयोग करना संभव था!

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

फिर एक स्क्रीन को दूसरी स्क्रीन के लिए कैसे चुनें? तीन विकल्प हैं:

1. TargetFragment
2. EventBus
3. जेट मॉडल

टारगेटफ्रैगमेंट - एक विकल्प "बॉक्स से बाहर", लेकिन यूआई परत के किनारे एक ही डेटा स्थानांतरण। बुरा विकल्प।

EventBus - यदि आप एक टीम पर सहमत हो सकते हैं और - सबसे महत्वपूर्ण बात - व्यवस्था को नियंत्रित करते हैं, तो आप वैश्विक इंटरनेट बस पर स्क्रीन के बीच डेटा हस्तांतरण को लागू कर सकते हैं। लेकिन चूंकि यह एक खतरनाक कदम है, इसलिए निष्कर्ष एक बुरा विकल्प है।

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

परिणाम

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

दृष्टिकोण की सादगी दिखाने के लिए, मैंने खुद को खुले अनुप्रयोग को एकल-गतिविधि में बदल दिया , और इसमें केवल कुछ घंटे लगे (बेशक, यह विचार करने योग्य है कि यह एक प्राचीन विरासत नहीं है, और वहां वास्तुकला के साथ सब कुछ कम या ज्यादा अच्छा है)।

क्या हुआ था?

आइए देखें कि नए दृष्टिकोण में मानक समस्याओं को कैसे हल किया जाए।

बॉटमवेशनबेर और नेवीगेशनवेर

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

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

यह विकल्प GitFox में पाया जा सकता है।

यह दूसरों के भीतर बस कुछ अंशों के संयोजन की संभावना है जो किसी भी समस्या के बिना विभिन्न उपकरणों के लिए एक गतिशील यूआई बनाना संभव बनाता है: टैबलेट + स्मार्टफोन।

डि स्कोप

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

गहरी कड़ियाँ

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

मौत की प्रक्रिया

यदि एप्लिकेशन को कई गतिविधियों पर लिखा गया है, तो आपको पता होना चाहिए कि जब एप्लिकेशन की मृत्यु हो जाती है, और फिर जब प्रक्रिया को बहाल किया जाता है, तो उपयोगकर्ता अंतिम गतिविधि पर होगा, और पिछले सभी को केवल तभी बहाल किया जाएगा जब वे उन्हें वापस कर दिए जाएंगे।

यदि आप इसे पहले से ध्यान में नहीं रखते हैं, तो समस्याएं पैदा हो सकती हैं। उदाहरण के लिए, यदि पिछले पर खोली गई अंतिम गतिविधि पर आवश्यक गुंजाइश है, तो कोई भी इसे फिर से नहीं बनाएगा। क्या करें? इसे अनुप्रयोग वर्ग में लाएँ? क्या कई बिंदु खुले हैं?

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

हम टिप्पणियों में अन्य व्यावहारिक कार्यों पर चर्चा कर सकते हैं, क्योंकि अन्यथा एक मौका है कि लेख बहुत अधिक चमकदार हो जाएगा।

और अब सबसे दिलचस्प हिस्सा।

अड़चनें (आपको याद रखने और सोचने की जरूरत है)।

यहां उन महत्वपूर्ण चीजों को एकत्र किया जाता है जिनके बारे में आपको किसी भी परियोजना में सोचना चाहिए, लेकिन हर किसी को कई गतिविधियों पर परियोजनाओं में "उन्हें फाड़" करने के लिए उपयोग किया जाता है, जो कि नए दृष्टिकोण में उन्हें सही ढंग से हल करने के तरीके को याद करने और बताने के लायक है। और पहले सूची में

स्क्रीन रोटेशन

यह प्रशंसकों के लिए सबसे भयानक कहानी है कि स्क्रीन को घुमाए जाने पर Android गतिविधि को फिर से बनाता है। सबसे लोकप्रिय समाधान विधि पोर्ट्रेट ओरिएंटेशन को ठीक करना है। इसके अलावा, यह प्रस्ताव अब डेवलपर्स द्वारा नहीं बनाया गया है, लेकिन प्रबंधकों द्वारा इस तरह के वाक्यांशों से भयभीत होकर "जैसे कि एक मोड़ को बनाए रखना बहुत कठिन है और लागत कई गुना अधिक है ।"
हम इस तरह के निर्णय की शुद्धता के बारे में बहस नहीं करेंगे। एक और बात महत्वपूर्ण है: रोटेशन को ठीक करना गतिविधि की मृत्यु से छूट नहीं देता है! चूंकि एक ही प्रक्रिया कई अन्य घटनाओं के साथ होती है: स्प्लिट-मोड, जब स्क्रीन पर कई एप्लिकेशन प्रदर्शित होते हैं, बाहरी मॉनिटर को कनेक्ट करते हैं, मक्खी और इतने पर एप्लिकेशन कॉन्फ़िगरेशन बदलते हैं।

इसके अलावा, स्क्रीन का रोटेशन आपको लेआउट के सही "रबरनेस" की जांच करने की अनुमति देता है, इसलिए, हमारी सेंट पीटर्सबर्ग टीम में, हम सभी बिक्री विधानसभाओं में रोटेशन को बंद नहीं करते हैं, भले ही यह रिलीज़ संस्करण में न हो। उन विशिष्ट बगों का उल्लेख नहीं करना जो सत्यापन के दौरान अभी भी मिलेंगे।

मोड़ के लिए बहुत सारे समाधान पहले से ही लिखे गए हैं, जो मोक्सी से शुरू होते हैं और विभिन्न एमवीवीएम कार्यान्वयन के साथ समाप्त होते हैं। इसे और कुछ से कठिन नहीं बनाओ।

एक और दिलचस्प मामले पर विचार करें।
उत्पाद सूची एप्लिकेशन की कल्पना करें। हम इसे एकल गतिविधि में करते हैं। हर जगह पोर्ट्रेट मोड तय किया गया है, लेकिन ग्राहक एक ऐसी सुविधा चाहता है, जब फोटो गैलरी देखने के दौरान, उपयोगकर्ता उन्हें लैंडस्केप ओरिएंटेशन में देख सके। इसका समर्थन कैसे करें?

कोई पहली बैसाखी पेश करेगा:

 <activity android:name=".AppActivity" android:configChanges="orientation" /> 

 override fun onConfigurationChanged(newConfig: Configuration?) { if (newConfig?.orientation == Configuration.ORIENTATION_LANDSCAPE) { //ignore } else { super.onConfigurationChanged(newConfig) } } 

इस प्रकार, हम super.onConfigurationChanged(newConfig) नहीं कह सकते हैं, लेकिन इसे स्वयं संसाधित करें और स्क्रीन पर केवल आवश्यक दृश्य घुमाएं।
लेकिन एपीआई 23 के साथ, परियोजना एक SuperNotCalledException साथ दुर्घटनाग्रस्त हो SuperNotCalledException , इसलिए एक बुरा विकल्प ।

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

कोई दूसरा उपाय सुझा सकता है:

 <activity android:name=".AppActivity" android:screenOrientation="portrait" /> <activity android:name=".RotateActivity" /> 

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

यहाँ सही समाधान है:

 <activity android:name=".AppActivity" android:configChanges="orientation" /> 

 override fun onResume() { super.onResume() activity?.requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_SENSOR } override fun onPause() { super.onPause() activity?.requestedOrientation = ActivityInfo.SCREEN_ORIENTATION_PORTRAIT } 

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

यह वह जगह है जहां स्क्रीन मोड़ के लिए समय पर तैयारी में मदद मिलेगी।

पारदर्शी स्थिति पट्टी

केवल गतिविधि सिस्टम बार के साथ काम कर सकती है, लेकिन अब हमारे पास केवल एक है, इसलिए आपको हमेशा निर्दिष्ट करना चाहिए

 <item name="android:windowTranslucentStatus">true</item> 

लेकिन कुछ स्क्रीन पर इसके नीचे "क्रॉल" करने की आवश्यकता नहीं है, और आपको नीचे दी गई सभी सामग्री को प्रदर्शित करने की आवश्यकता है। झंडा बचाव के लिए आता है

 android:fitsSystemWindows="true" 

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

 <android.support.design.widget.CoordinatorLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" android:layout_width="match_parent" android:layout_height="match_parent" android:fitsSystemWindows="true"> </android.support.design.widget.CoordinatorLayout> 

एक बेहतर समाधान कीबोर्ड को भी संसाधित करने में मदद करता है।

कीबोर्ड दिखाई देने पर लेआउट बदलें

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

 android:windowSoftInputMode="adjustResize" 

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

शीर्षक पर ध्यान दें

क्या करें? प्रलेखन पढ़ें!और क्रिस बैन्स को WindowInsets के बारे में बात करते देखना सुनिश्चित करें ।

WindowInsets का उपयोग करने की अनुमति देगा

• सही बार स्थिति ऊंचाई ज्ञात करें (और 51dp हार्डकोड नहीं)
• नए स्मार्टफोन की स्क्रीन में किसी भी कटआउट के लिए एप्लिकेशन तैयार करें
• कीबोर्ड की ऊंचाई ज्ञात करें (यह वास्तविक है!)
• ईवेंट प्राप्त करें और कीबोर्ड की उपस्थिति पर प्रतिक्रिया दें।

हर कोई सीखता है WindowInsets!

स्पलैश स्क्रीन

यदि किसी और को पता नहीं है, तो कैनोनिकल स्प्लैश स्क्रीन एप्लिकेशन में पहली स्क्रीन नहीं है जो डेटा लोड करती है, लेकिन उपयोगकर्ता स्टार्टअप पर तब तक देखता है जब तक कि गतिविधि सामग्री को प्रस्तुत करने का समय न हो। इस विषय पर कई लेख हैं ।

, Single-Activity, Splash screen. , deep-link Splash screen .

, , , .

, . Single-Activity. - , , .
...
Intent, , ...
आगे क्या है? :

• , «». «», . , !
• , …

, . ? — «» «» .

क्या करें? , .

Activity!
, : , — .
— , ( Activity), .

Activity — . Activity, . .

निष्कर्ष

() , Activity, Android-. , .

: Google . — , , Activity .

, , , ! धन्यवाद!