एंड्रॉइड: क्या बेहतर है - कई गतिविधियां या मैन्युअल रूप से दृश्य स्विच करना?


115

मैंने Android के लिए कुछ एप्लिकेशन विकसित किए हैं, और यह प्रश्न हमेशा रहता है:

मुझे अपना UI कैसे बनाना चाहिए? क्या मुझे गतिविधि के बाद गतिविधि शुरू करनी चाहिए और "बैक" बटन बनाने के लिए फोन छोड़ना चाहिए, या क्या मुझे और अधिक अनुकूलित, लेकिन लागू करने के लिए अधिक जटिल चुनना चाहिए, मैन्युअल रूप से दृश्य स्विच करने के साथ तरीका और फिर मैन्युअल रूप से "बैक" बटन की कार्यक्षमता?

आपको क्या लगता है (या पता) बेहतर अभ्यास है?


4
नए पाठकों के लिए, कृपया ध्यान दें कि यह प्रश्न काफी पुराना है, और आज यह प्रश्न "कई विचारों या कई गतिविधियों" के बजाय "कई टुकड़े या कई गतिविधियाँ" होने की संभावना है। में अद्यतन देखें stackoverflow.com/a/10794086/199364 । इसके अलावा, टुकड़ों के बारे में अन्य स्टैकओवरफ्लो विषयों के लिए Google बनाम गतिविधियाँ - बहुत सारे अच्छे उत्तर।
टूलमेकरसेव

जवाबों:


99

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

मुझे यह कल्पना करने में परेशानी है कि वास्तव में गति एक मुद्दा है; यदि यह तब है तो जिस तरह से आप प्रत्येक गतिविधि को शुरू कर रहे हैं, उसमें कुछ गड़बड़ है। उदाहरण के लिए, मैंने गतिविधियों के बीच अनुक्रमिक वस्तुओं को पारित करने की कोशिश की, और यह अविश्वसनीय रूप से धीमा साबित हुआ; जब मैंने पासिंग ऑब्जेक्ट्स की एक तेज़ विधि पर स्विच किया, तो लॉन्चिंग एक्टिविटीज़ की गति बहुत बढ़ गई।

इसके अलावा, मुझे लगता है कि यह बता रहा है कि ऐक्टिविटी और टास्क डिज़ाइन के लिए एंड्रॉइड दिशा-निर्देश दृश्य बदलने का बिल्कुल भी उल्लेख नहीं करते हैं; यह एक गतिविधि-ए-व्यू डिज़ाइन के आसपास केंद्रित है।


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

3
मैं आपसे सहमत हूं, लेकिन कई दृश्य प्रभाव केवल दृश्य संक्रमणों के बीच उपलब्ध हैं, न कि उन गतिविधियों के बीच जो
इरगो

यह एक अत्यंत रोचक विषय है। मेरे पास इस बिंदु पर एक ऐप है जो अंततः 4 विचारों को लागू करेगा। मैं यह सब 1 गतिविधि के भीतर कर रहा हूं जिसके परिणामस्वरूप "मेगा गतिविधि" इस उत्तर में बताई गई है। मैं यह मुख्य रूप से अपने ऐप को देखने और महसूस करने के लिए कर रहा हूं जैसे कि यह आईओएस समकक्ष है। मैं इस बात से सहमत हूं कि यह भारीता इस बात पर निर्भर करती है कि आप क्या हासिल करना चाहते हैं। महान प्रश्न, और उत्तर +1 :-)
तुरही

IOS UI बनाना एक बुरा विचार है। अकेले Hvis कई गतिविधियों का उपयोग नहीं करने का गलत कारण है।
slott

3
@ डैनियल: जब मैंने पासिंग ऑब्जेक्ट्स की एक तेज़ विधि पर स्विच किया, तो लॉन्चिंग एक्टिविटीज़ की गति बहुत बढ़ गई। क्या आप कृपया इसके लिए कुछ अतिरिक्त विवरण या संदर्भ सामग्री प्रदान कर सकते हैं?
भार्गव झावेरी

21

मैं कुछ उदाहरणों को इंगित करना चाहता हूं जब एक Android एप्लिकेशन के लिए एक एकल गतिविधि बेहतर डिज़ाइन हो सकती है जिसमें एक से अधिक पूर्ण स्क्रीन हैं देखें:

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

  • यदि आप स्क्रीन के बीच कुछ वास्तव में अच्छा एनिमेशन चाहते हैं। हो सकता है कि आप एक पक्षी को एक स्क्रीन में उतारना चाहते हैं और दूसरी स्क्रीन में लैंड करना चाहते हैं। कोशिश करें कि जब प्रत्येक स्क्रीन एक गतिविधि हो!

दूसरी तरफ यदि आपकी किसी भी स्क्रीन को किसी भी अन्य एप्लिकेशन द्वारा दिखाया गया है तो उस स्क्रीन की अपनी गतिविधि होनी चाहिए।

अद्यतन मार्च 2014:

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

अपडेट 2018:

Google के कुछ देवता नए नेविगेशन आर्किटेक्चर घटक का उपयोग करके एकल गतिविधि ऐप्स की सिफारिश कर रहे हैं ।


Fragments के बारे में बात करने के लिए UPDATE जोड़ने के लिए धन्यवाद। पूरी तरह से सहमत हैं कि आज महत्वपूर्ण विकल्प यह है कि फ्रैगमेंट बनाम गतिविधि का उपयोग कैसे करें।
टूलमेकरसेव

11

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


4

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

इसका उपयोग करें जिस तरह से उपयोगकर्ता स्वाभाविक महसूस करेगा। और सब कुछ एक गतिविधि में रखने से यह जटिल हो जाएगा।


3

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

एकदम मेरे विचार।


1

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


3
StackOverflowError बहुत अधिक केवल जावा में होता है यदि आपके पास अनंत पुनरावृत्ति है, तो शायद आप OutOfMemoryError के बारे में सोच रहे हैं? एक जावा प्रोग्रामर के रूप में आपको वास्तव में इस बात की चिंता नहीं करनी चाहिए कि कचरा कलेक्टर कब या कहां ट्रिगर किया जाता है।
संतृप्तिन

2
एंड्रॉइड स्टैकओवरफ़्लो में तब होता है जब दृश्य पदानुक्रम बहुत गहरा होता है।
डेनियल

0

मैंने कई गतिविधि लेआउट के साथ बहुत सारी समस्याओं का अनुभव किया है कि मैं इसे दृढ़ता से हतोत्साहित करता हूं, जब तक कि इसे लेने का अच्छा कारण न हो।

कई गतिविधियों का नुकसान

कई गतिविधियों का उपयोग करते हुए गतिविधि से डेटा वापस करने के लिए कोड को रिफलेक्टर करना बहुत कठिन है।

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

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

संबंधित एप-स्टेट को संग्रहीत करने के लिए इसकी इतनी सफाई है, और मेरे मामले में, सबसे अधिक बार यदि वीएम को मार दिया जाता है, तो मैं उपयोगकर्ता को मुख्य-स्क्रीन पर वापस करना चाहता हूं, और उन्हें अपना सामान फिर से करने दूंगा, क्योंकि मैं डॉन 30-50 घंटे कोडिंग सेव / रिज्यूम कार्यक्षमता को खर्च नहीं करते हैं जो 0.1% उपयोगकर्ता कभी भी अनुभव करेंगे।

विकल्प

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

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

संभवतः प्रासंगिक: Reddit: यह आधिकारिक है: Google आधिकारिक तौर पर एकल गतिविधि ऐप आर्किटेक्चर की सिफारिश करता है

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.