एक गतिविधि और अन्य सभी टुकड़े [बंद]

Question

मैं एक स्क्रीन के साथ Activityऔर अन्य सभी साग के साथ Fragmentsऔर लागू करने के बारे में सोच रहा हूं managing all the fragments thru the activity।

क्या यह एक अच्छा विचार है? और मेरा जवाब नहीं है, लेकिन फिर भी मैं इस विचार के बारे में अधिक स्पष्ट रूप से जानना चाहता हूं।

विचार के पक्ष और विपक्ष क्या हैं?

ध्यान दें:

कृपया मुझे टुकड़ा और गतिविधि के लिए लिंक न दें।

संपादित करें:

यहाँ Fragments और गतिविधि पर कुछ है:

पेशेवरों:

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

विपक्ष:

1. हमें टुकड़ों से डेटा प्राप्त करने के लिए इंटरफ़ेस को लागू करने की आवश्यकता है।
2. संवाद के लिए हमें इसे दिखाने के लिए एक लंबा रास्ता तय करना होगा।

यदि हम गोलियों पर विचार नहीं कर रहे हैं तो हमें टुकड़ों का उपयोग क्यों करना चाहिए? गतिविधि और टुकड़े के बीच शुरुआती समय का अंतर क्या है?

Comments

क्या आप इस बारे में विस्तार से सोच सकते हैं कि उत्तर क्यों नहीं है? मैं असहमत हूं, लेकिन अगर आप जानते हैं कि उन चिंताओं के बारे में क्या पता है, तो उन चिंताओं के बारे में पता करना आसान हो सकता है।

— अलेक्जेंडर लुकास

@AlexanderLucas मैंने ऐसा करने का जवाब दिया क्योंकि ऐसा करने से आपका कोड कम मॉड्यूलर हो जाता है, जटिलता बढ़ जाती है।

— विनीत शुक्ला

@Ski आप अपने उत्तर को स्वीकार करने पर अधिक ध्यान केंद्रित कर रहे हैं, plz इस पर ध्यान केंद्रित किया जा रहा है कि क्या पूछा जा रहा है और सबसे अच्छा उत्तर क्या होना चाहिए जो आप प्रदान कर सकते हैं।

— विनीत शुक्ला

किसी को भी जो यह पाता है, मैंने रिफ्लेक्टर को बंद कर दिया क्योंकि चीजें वास्तव में बहुत जटिल हो गईं।

— दिबांग

यह एक अच्छा सवाल है और इसे बंद नहीं किया जाना चाहिए था।

— जिम इन टेक्सास

Answer 1

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

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

अरविंद एक Activityप्रकार से अटक जाने के बारे में जो कहते हैं वह भी सच है लेकिन वास्तव में सीमित नहीं है। आपकी गतिविधि एक FragmentActivity होगी और जब तक आपको जरूरत नहीं है MapViewतब तक कोई वास्तविक सीमाएं नहीं हैं। यदि आप मानचित्र प्रदर्शित करना चाहते हैं, तो यह किया जा सकता है, लेकिन आपको सार्वजनिक रूप से उपलब्ध Android-support-v4-googlemaps काFragmentActivity विस्तार MapActivityया उपयोग करने के लिए Android संगतता लाइब्रेरी को संशोधित करना होगा ।

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

- संपादित करें -

Google ने आखिरकार MapFragmentसंगतता लाइब्रेरी के लिए जारी कर दिया है ताकि अब आपको android-support-v4-googlemaps हैक का उपयोग न करना पड़े। अपडेट के बारे में यहां पढ़ें: Google मैप्स Android API v2

- EDIT 2 -

मैंने टुकड़ों के आधुनिक (2017) राज्य के बारे में इस महान पोस्ट को पढ़ा और इस पुराने उत्तर को याद किया। सोचा था कि मैं साझा करूँगा: टुकड़े: Android की समस्याओं का समाधान

Comments

वहाँ है settargetfragmentऔर आप startforresultप्रक्रिया की तरह गतिविधि को संभाल सकता है ।

— ललित बी

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

— Ixx

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

— Ixx

Answer 2

मैं एक परियोजना (विकास में 5 महीने) खत्म करने वाला हूं, जिसमें 1 गतिविधि है, और 17 टुकड़े हैं, सभी पूर्ण स्क्रीन हैं। यह मेरी दूसरी खंड आधारित परियोजना है (पिछले 4 महीने थी)।

पेशेवरों

• मुख्य गतिविधि कोड की 700 लाइनें है, बस टुकड़े के नेविगेशन के क्रम को अच्छी तरह से प्रबंधित करना है।
• प्रत्येक टुकड़ा अच्छी तरह से अपनी कक्षा में अलग हो जाता है, और अपेक्षाकृत छोटा होता है (~ ui सामान की सौ जोड़ी लाइनें)।
• प्रबंधन कह सकता है, "अरे, हम उन स्क्रीन के क्रम को कैसे बदलते हैं", और मैं इसे बहुत आसानी से कर सकता हूं, क्योंकि वे टुकड़े एक-दूसरे पर निर्भर नहीं करते हैं, वे सभी गतिविधि के माध्यम से संवाद करते हैं। मुझे व्यक्तिगत गतिविधियों के माध्यम से खुदाई करने की ज़रूरत नहीं है, यह पता लगाने के लिए कि वे एक-दूसरे को कहां बुलाते हैं।
• मेरा ऐप बहुत ही भारी ग्राफिक्स है, और 1 स्क्रीन 1 गतिविधि के रूप में कभी काम नहीं करेगा। स्मृति में उन सभी उप गतिविधियों, एप्लिकेशन को हर समय स्मृति से बाहर कर देगा, इसलिए मुझे finish()सभी गैर-दृश्य गतिविधियों को करना होगा , और नेविगेशन के लिए एक ही नियंत्रण तर्क बनाना होगा, जैसा कि मैं टुकड़ों के साथ करूंगा। शायद सिर्फ इस वजह से इसे टुकड़ों के साथ किया जाए।
• अगर हम कभी टैबलेट ऐप करते हैं, तो हमारे पास एक आसान समय फिर से फैक्टरिंग सामान होगा, क्योंकि सब कुछ पहले से ही अलग है।

विपक्ष

• आपको सीखना होगा कि टुकड़ों का उपयोग कैसे करें

Comments

बहुत सारे टुकड़े होने और केवल अब गतिविधि होने के बारे में निश्चित नहीं था ... उत्पादन पर कोई भी मुद्दा, और दोष आप पर है !! :)

— शाहर

@ दिनाश ने ओएस को आपकी गतिविधि को फिर से शुरू नहीं करने दिया। अभिविन्यास को अपने आप को बदलें। यहाँ और अधिक पढ़ें: stackoverflow.com/questions/5913130/…

— तमस

@ टामस क्या आपके पास कोई मल्टी-फ़्रेग्मेंट स्क्रीन (उदा। मास्टर-डिटेल) है और यदि ऐसा है तो आपने उसे कैसे हैंडल किया?

— theblang

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

— तेओडोर

700 लाइनें !!!! "अच्छी तरह से"???? कक्षाएं निःशुल्क हैं।

— बीपला

Answer 3

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

क्रियाएँ और टुकड़े वास्तव में क्या प्रदान करते हैं?

1. जीवन चक्र की घटनाओं और बैकस्टैक
2. प्रसंग और संसाधन

इसलिए, उन्हें केवल उसी के लिए उपयोग करें । उनके पास पर्याप्त जिम्मेदारी है, उन्हें जटिल न करें। मैं यह दलील दूंगा कि किसी गतिविधि या फ्रैगमेंट में टेक्स्टव्यू से डरना भी बुरा व्यवहार है। सार्वजनिक दृश्य findViewById (int id) PUBLIC जैसी कुछ विधियां हैं ।

अब प्रश्न सरल हो जाता है: क्या मुझे कई, स्वतंत्र जीवन चक्र की घटनाओं और बैकस्ट की आवश्यकता है? यदि आपको लगता है कि शायद हाँ, तो टुकड़ों का उपयोग करें। अगर आपको लगता है कि कभी नहीं, तो टुकड़े का उपयोग न करें।

अंत में, आप अपने स्वयं के बैकस्टैक और जीवन चक्र बना सकते हैं। लेकिन, पहिया को फिर से क्यों बनाया जाए?

संपादित करें: क्यों नीचे वोट यह? एकल उद्देश्य वर्ग के लोग! प्रत्येक गतिविधि या टुकड़े को एक प्रस्तुतकर्ता को त्वरित करने में सक्षम होना चाहिए जो एक दृश्य को त्वरित करता है। प्रस्तुतकर्ता और दृश्य एक मॉड्यूल है जिसे आपस में जोड़ा जा सकता है। एक गतिविधि या टुकड़े को एक प्रस्तुतकर्ता की जिम्मेदारी क्यों होनी चाहिए ??

Comments

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

— आईकेसी

IMHO: यदि आप अपने दृश्य और प्रस्तुतकर्ता में एक एक्टिविटी को पास करते हैं (2 को एक "मॉड्यूल" कहते हैं), तो आप उस मॉड्यूल का पुनः उपयोग अन्य गतिविधियों के साथ करते हैं। अगर यह मदद करता है, तो यह सबसे अच्छा है कि गतिविधि को एक अंतःक्रियात्मक के रूप में पारित किया जाए जो नेक्ससरी थिंग्स को उजागर करता है। यदि आप अधिनियम के बाहर के विचारों को देखने से नफरत करते हैं, तो आप उस intrface के माध्यम से, pres./view में allthe विचारों को इंजेक्ट कर सकते हैं। मुख्य बिंदु यह है कि मुझे विश्वास है कि एंड्रॉइड कोडिंग को एक्टविटीज़ और फ्रैग्स की अवधारणा को पूरा करना चाहिए, सोथेट स्वाचिंग द बीट्न द 2 आसान है। फिर, यह स्पष्ट हो जाता है कि यह बीटी है और आप एक वेब के अंदर एक या दूसरे के साथ अटक नहीं रहे हैं। कोड।

— बेपला

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

— स्ट्रै जूल

Answer 4

पेशेवरों

आप किसी एकल गतिविधि से अपने टुकड़ों को नियंत्रित कर सकते हैं, सभी टुकड़ों को एक दूसरे से स्वतंत्र कर सकते हैं। टुकड़े एक जीवन चक्र (है onPause, onCreate, onStartउनकी खुद की ...)। जीवनचक्र होने से, टुकड़े घटनाओं पर स्वतंत्र रूप से प्रतिक्रिया कर सकते हैं, उनके राज्य को बचा सकते हैं onSaveInstanceState, और वापस लाया जा सकता है (जैसे कि किसी आने वाले कॉल के बाद फिर से शुरू होने पर या जब उपयोगकर्ता बैक बटन पर क्लिक करता है)।

विपक्ष

1. अपनी गतिविधि के कोड में जटिलता पैदा करें।
2. आपको टुकड़ों के क्रम का प्रबंधन करना होगा।

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

Answer 5

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

Answer 6

पेशेवरों:

• एक से अधिक स्क्रीन आकार और xml लेआउट के माध्यम से अभिविन्यास द्वारा प्रयोग करने योग्य एक इंटरफ़ेस बनाने के लिए इस्तेमाल किया जा सकता है।

विपक्ष:

• आपकी गतिविधि में अधिक जटिल कोड की आवश्यकता है।

मेरा मानना ​​है कि यह एक अच्छा विचार है, क्योंकि वर्तमान स्क्रीन आकार और अभिविन्यास के आधार पर अलग-अलग xml लेआउट का उपयोग करने से ऐप अधिक उपयोगी हो सकता है और यदि आप अपने ऐप को फोन और टैबलेट दोनों के लिए जारी करने की योजना बनाते हैं तो अपने ऐप के कई संस्करणों को रिलीज़ करने की आवश्यकता को कम कर सकते हैं। यदि आपका ऐप कभी भी टैबलेट और फोन दोनों द्वारा उपयोग नहीं किया जाएगा, तो यह संभवतः परेशानी के लायक नहीं है।

Comments

अभिविन्यास के लिए विभिन्न xml- आधारित लेआउट का उपयोग करना आवश्यक नहीं है।

— विनीत शुक्ला

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

— स्की

Answer 7

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

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

Comments

"मुझे लगता है कि टैब को या स्लाइड आउट मेनू को तब पेश किया जाता है जब टैब या मेनू नेविगेशन के बाद से पूरी तरह से नई स्क्रीन पर परिणाम होता है, तो फोन कार्यान्वयन के लिए यह एक बुरा विचार है।" -> यह समझ में नहीं आता है कि वास्तव में आपका क्या मतलब है, लेकिन, न तो टैब या साइड मेनू एकल-एक्टीविटी ऐप (टैबलेट / फोन) में एक समस्या है।

— आईकेसी

Answer 8

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

Comments

मुझे विश्वास नहीं होता कि यह सच है। फ्रैगमेंट लाइफ़साइकल डॉक्यूमेंटेशन ( developer.android.com/guide/compenders/fragments.html#Lifecycle ) से: "जिस एक्टिविटी का जीवनचक्र सीधे फ्रैगमेंट के जीवनचक्र को प्रभावित करता है, वह गतिविधि के लिए प्रत्येक जीवनचक्र कॉलबैक को प्रभावित करता है। प्रत्येक टुकड़े के लिए एक समान कॉलबैक में परिणाम। उदाहरण के लिए, जब गतिविधि ऑनपॉज़ () प्राप्त करती है, तो गतिविधि में प्रत्येक टुकड़ा ऑनपॉज़ () प्राप्त करता है। "

— स्की