software - android windows 7




डेटा लोडिंग के लिए एंड्रॉइड गतिविधि/खंड जिम्मेदारियां (3)

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

  • कोड जटिलता को सीमित करना।
  • किनारे के मामलों को संभालना (जैसे स्क्रीन रोटेशन, स्क्रीन गोइंग पावर सेव, कनेक्टिविटी की हानि, आदि)

विकल्प 1 - गतिविधि डेटा और खंड को लोड करती है जो इसे प्रदर्शित करती है

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

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

यह MVC आर्किटेक्चर का एक प्रकार है जहां गतिविधि नियंत्रक है और टुकड़े दृश्य हैं।

विकल्प 2 - गतिविधि खंडों को व्यवस्थित करती है और अंश डेटा को लाने के लिए जिम्मेदार होते हैं

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

गतिविधियाँ केवल स्क्रीन पर टुकड़ों को व्यवस्थित करने और अनुप्रयोग गतिविधियों के बीच संक्रमणों को समन्वयित करने का एक तरीका है।


मेरे पास एक उदाहरण है: आपके एप्लिकेशन में 2 विशेषताएँ A और B हैं। 2 सुविधाएँ एक-दूसरे से स्वतंत्र हैं। और प्रत्येक सुविधा में बहुत अधिक स्क्रीन है। आपको ए और बी 2 गतिविधियों का निर्माण करना चाहिए क्योंकि जब ए गतिविधि का उपयोग किया जाता है, तो गतिविधि बी को ऐप की मेमोरी को कम करने के लिए जारी किया जाना चाहिए। और जब बी का उपयोग किया जाता है, तो वही जारी किया जाना चाहिए। प्रसंग A और B की स्मृति स्वतंत्र हैं, यदि आप गतिविधि A से B तक डेटा भेजना चाहते हैं तो आपको अभिप्राय का उपयोग करना चाहिए या अनुप्रयोग प्रसंग में वैश्विक चर का उपयोग करना चाहिए। आशय ओएस द्वारा प्रबंधित किया जाता है, आवेदन द्वारा नहीं। जब A, B को आशय भेज देता है, यदि A नष्ट हो जाता है, तो ख के लिए कोई समस्या नहीं है। बी को भेजें गतिविधि App मॉड्यूल है, यह अन्य अनुप्रयोगों द्वारा कॉल कर सकता है (टुकड़ा असंभव है)।

उदाहरण के लिए: फीचर A में बहुत सारी स्क्रीन है (उदा: Fragment1, Fragment2)। वे समान डेटा का उपयोग करते हैं और एक दूसरे पर निर्भर होते हैं। प्रत्येक स्क्रीन एक टुकड़ा होना चाहिए। और जब डेटा के साथ प्रक्रिया आप फ़ंक्शन getActivity () को कॉल करके डेटा का संदर्भ प्राप्त कर सकते हैं और फिर इसे लिखने या पढ़ने के लिए गतिविधि के संदर्भ के चर (या गतिविधि मेमोरी) का संदर्भ प्राप्त कर सकते हैं। Fragment1 और Fragment2 गतिविधि A Context.it से तात्पर्य है कि Fragment 1 और Fragment 2 गतिविधि संदर्भ के चर के माध्यम से एक दूसरे के साथ डेटा स्थानांतरित कर सकते हैं, यह करना आसान है। ध्यान दिया कि Intent OS द्वारा प्रबंधित किया जाता है, यह Intent के माध्यम से डेटा भेजने पर इतना महंगा होता है।


मैं पसंद करता हूं और हमेशा विकल्प -1 से अधिक विकल्प -2 को लागू किया है।

विकल्प -1 का चयन न करने के कारण:

  1. फ्रेगमेंट्स में ट्रिगर की गई घटनाओं के लिए हमारे पास श्रोता होना चाहिए और डेटा को लोड करने, उसे संसाधित करने और इसे वापस खंडन में धकेलने के लिए गतिविधि में पास करें, जो काम को और अधिक जटिल बनाता है।

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

  3. जैसा कि @Ved प्रकाश ने उल्लेख किया है, यदि अभिविन्यास को सक्रियता द्वारा नियंत्रित किया जाता है तो हैंडलिंग स्क्रीन ओरिएंटेशन जटिल हो जाता है।


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

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

UPD : कॉन्फ़िगरेशन परिवर्तन से निपटने के लिए अब एक बेहतर तरीका है: Google के आर्किटेक्चर घटकों से ViewModel । यहाँ एक अच्छा उदाहरण है







android