Android एप्लिकेशन आर्किटेक्चर गाइड

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

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

मोबाइल ऐप उपयोगकर्ता अनुभव

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

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

उदाहरण के लिए, विचार करें कि जब आप अपने पसंदीदा सोशल मीडिया एप्लिकेशन में फोटो साझा करते हैं तो क्या होता है:

1. एप्लिकेशन कैमरा के इरादे को ट्रिगर करता है। Android अनुरोध को संसाधित करने के लिए एक कैमरा एप्लिकेशन लॉन्च करता है। फिलहाल, उपयोगकर्ता ने सामाजिक नेटवर्क के लिए आवेदन छोड़ दिया है, और उपयोगकर्ता के रूप में उसका अनुभव त्रुटिहीन है।
2. एक कैमरा एप्लिकेशन अन्य इरादों को ट्रिगर कर सकता है, जैसे कि फाइल पिकर लॉन्च करना, जो एक और एप्लिकेशन लॉन्च कर सकता है।
3. अंत में, उपयोगकर्ता सोशल नेटवर्क एप्लिकेशन पर वापस लौटता है और फोटो साझा करता है।

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

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

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

सामान्य स्थापत्य सिद्धांत

यदि आपको डेटा और एप्लिकेशन स्थिति को संग्रहीत करने के लिए एप्लिकेशन घटकों का उपयोग नहीं करना चाहिए, तो आपको अपना एप्लिकेशन कैसे विकसित करना चाहिए?

जिम्मेदारी का विभाजन

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

मॉडल से उपयोगकर्ता इंटरफ़ेस नियंत्रण

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

एक स्थायी मॉडल निम्नलिखित कारणों से आदर्श है:

• यदि Android OS संसाधनों को खाली करने के लिए आपके एप्लिकेशन को नष्ट कर देता है तो आपके उपयोगकर्ता डेटा नहीं खोएंगे।
• नेटवर्क कनेक्शन अस्थिर या अनुपलब्ध होने पर आपका एप्लिकेशन कार्य करना जारी रखता है।

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

अनुशंसित अनुप्रयोग वास्तुकला

यह खंड दर्शाता है कि आर्किटेक्चरल घटकों का उपयोग करके किसी एप्लिकेशन को कैसे तैयार किया जाए, जो एंड- टू- एंड यूसेज परिदृश्य में काम करता है ।

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

कल्पना करें कि हम एक उपयोगकर्ता इंटरफ़ेस बना रहे हैं जो एक उपयोगकर्ता प्रोफ़ाइल प्रदर्शित करता है। प्रोफ़ाइल डेटा पुनर्प्राप्त करने के लिए हम एक निजी API और REST API का उपयोग करते हैं।

सिंहावलोकन

शुरू करने के लिए, तैयार एप्लिकेशन आर्किटेक्चर के मॉड्यूल की इंटरैक्शन स्कीम पर विचार करें:



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

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

उपयोगकर्ता इंटरफ़ेस बनाएँ

उपयोगकर्ता इंटरफ़ेस में UserProfileFragment टुकड़ा और संबंधित user_profile_layout.xml लेआउट user_profile_layout.xml ।

उपयोगकर्ता इंटरफ़ेस का प्रबंधन करने के लिए, हमारे डेटा मॉडल में निम्नलिखित डेटा तत्व होने चाहिए:

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

हम इस जानकारी को संग्रहीत करने के लिए ViewModel वास्तुकला के एक घटक के आधार पर एक UserProfileViewModel उपयोग करते हैं।

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

अब हमने निम्नलिखित फाइलों की पहचान की है:

• user_profile.xml : परिभाषित यूजर इंटरफेस लेआउट।
• UserProfileFragment : उपयोगकर्ता इंटरफ़ेस नियंत्रक का वर्णन करता है जो उपयोगकर्ता को जानकारी प्रदर्शित करने के लिए जिम्मेदार है।
• UserProfileViewModel : उपयोगकर्ताप्रोफाइलफ्रैगमेंट में इसे प्रदर्शित करने और उपयोगकर्ता सहभागिता के लिए डेटा तैयार करने के लिए जिम्मेदार वर्ग।

निम्न कोड स्निपेट इन फ़ाइलों की प्रारंभिक सामग्री दिखाते हैं। (लेआउट फ़ाइल को सरलता के लिए छोड़ा गया है।)

 class UserProfileViewModel : ViewModel() { val userId : String = TODO() val user : User = TODO() } class UserProfileFragment : Fragment() { private val viewModel: UserProfileViewModel by viewModels() override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View { return inflater.inflate(R.layout.main_fragment, container, false) } } 

अब जब हमारे पास ये कोड मॉड्यूल हैं, तो हम उन्हें कैसे कनेक्ट करते हैं? उपयोगकर्ता फ़ील्ड UserProfileViewModel वर्ग में सेट होने के बाद, हमें उपयोगकर्ता इंटरफ़ेस को सूचित करने का एक तरीका चाहिए।

नोट। SavedStateHandle ViewModel को सहेजे गए स्थिति और संबद्ध फ़्रेग्मेंट या क्रिया के तर्कों को एक्सेस करने की अनुमति देता है।

 // UserProfileViewModel class UserProfileViewModel( savedStateHandle: SavedStateHandle ) : ViewModel() { val userId : String = savedStateHandle["uid"] ?: throw IllegalArgumentException("missing user id") val user : User = TODO() } // UserProfileFragment private val viewModel: UserProfileViewModel by viewModels( factoryProducer = { SavedStateVMFactory(this) } ... ) 

अब उपयोगकर्ता वस्तु प्राप्त होने पर हमें अपने फ्रैगमेंट को सूचित करना होगा। यह वह जगह है जहाँ LiveData वास्तुकला का घटक दिखाई देता है।

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

नोट। यदि आप पहले से ही RxJava या Agera जैसे पुस्तकालयों का उपयोग करते हैं, तो आप LiveData के बजाय उनका उपयोग जारी रख सकते हैं। हालांकि, पुस्तकालयों और इसी तरह के दृष्टिकोण का उपयोग करते समय, सुनिश्चित करें कि आप अपने आवेदन के जीवन चक्र को ठीक से संभालते हैं। विशेष रूप से, सुनिश्चित करें कि जब आप संबंधित लाइफ़साइकलर को रोक दिया जाता है, तो आप अपने डेटा स्ट्रीम को निलंबित कर देते हैं, और जब संबद्ध लाइफ़ साइकलर को नष्ट कर दिया गया हो तो इन धाराओं को नष्ट कर दें। आप आर्टवर्क android.arch.lifecycle: जेट स्ट्रीम को RxJava2 जैसे किसी अन्य जेट स्ट्रीम लाइब्रेरी के साथ LiveData का उपयोग करने के लिए भी जोड़ सकते हैं।

अपने एप्लिकेशन में LiveData घटक को शामिल करने के लिए, हम UserDrofileViewModel में LiveData में फ़ील्ड प्रकार बदलते हैं। UserProfileFragment अब डेटा अपडेट के बारे में सूचित किया UserProfileFragment । इसके अलावा, चूंकि यह LiveData फ़ील्ड जीवन चक्र का समर्थन करता है, यह स्वचालित रूप से लिंक को साफ़ करता है जब उन्हें अब आवश्यकता नहीं होती है।

 class UserProfileViewModel( savedStateHandle: SavedStateHandle ) : ViewModel() { val userId : String = savedStateHandle["uid"] ?: throw IllegalArgumentException("missing user id") val user : LiveData<User> = TODO() } 

अब हम ViewModel में डेटा का निरीक्षण करने और परिवर्तनों के अनुसार उपयोगकर्ता इंटरफ़ेस को अपडेट करने के लिए UserProfileFragment को संशोधित करते हैं:

 override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) viewModel.user.observe(viewLifecycleOwner) { //  UI } } 

हर बार जब उपयोगकर्ता प्रोफ़ाइल डेटा अपडेट किया जाता है, तो ऑनचेंज () कॉलबैक कहा जाता है और उपयोगकर्ता इंटरफ़ेस अपडेट किया जाता है।

यदि आप अवलोकन योग्य कॉलबैक का उपयोग करने वाले अन्य पुस्तकालयों से परिचित हैं, तो आप महसूस कर सकते हैं कि हमने डेटा के अवलोकन को रोकने के लिए टुकड़े के onStop () विधि को फिर से परिभाषित नहीं किया है। यह चरण LiveData के लिए वैकल्पिक है क्योंकि यह जीवन चक्र का समर्थन करता है, जिसका अर्थ है कि यह onChanged() कॉलबैक नहीं करेगा यदि टुकड़ा निष्क्रिय अवस्था में है; यही है, उन्होंने onStart () को कॉल प्राप्त किया, लेकिन अभी तक onStop() ) प्राप्त नहीं किया है। LiveData भी स्वचालित रूप से पर्यवेक्षक को निकालता है जब टुकड़े पर onDestroy () विधि को बुलाता है।

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

डेटा पुनर्प्राप्ति

अब जब हमने UserProfileViewModel को UserProfileFragment से कनेक्ट करने के लिए LiveData का उपयोग किया है, तो हम उपयोगकर्ता प्रोफ़ाइल डेटा कैसे प्राप्त कर सकते हैं?

इस उदाहरण में, हम मानते हैं कि हमारा बैकएंड एक REST API प्रदान करता है। हम अपने बैकएंड को एक्सेस करने के लिए रेट्रोफिट लाइब्रेरी का उपयोग करते हैं, हालांकि आप एक ही उद्देश्य के लिए एक अलग लाइब्रेरी का उपयोग कर सकते हैं।

यहाँ एक Webservice की परिभाषा है जो हमारे बैकएंड से जुड़ती है:

 interface Webservice { /** * @GET declares an HTTP GET request * @Path("user") annotation on the userId parameter marks it as a * replacement for the {user} placeholder in the @GET path */ @GET("/users/{user}") fun getUser(@Path("user") userId: String): Call<User> } 

ViewModel को लागू करने के लिए एक पहला विचार डेटा को पुनः प्राप्त करने के लिए Webservice कॉल करना और उस डेटा को हमारी LiveData ऑब्जेक्ट पर असाइन करना हो सकता है। यह डिज़ाइन काम करता है, लेकिन इसका उपयोग करते हुए हमारे एप्लिकेशन को इसे बनाए रखने के लिए कठिन बना देता है। यह UserProfileViewModel वर्ग को बहुत अधिक जिम्मेदारी देता है, जो हितों के पृथक्करण के सिद्धांत का उल्लंघन करता है। इसके अलावा, ViewModel का दायरा एक्टिविटी या फ्रैगमेंट लाइफ साइकल से जुड़ा होता है, जिसका अर्थ है कि संबंधित यूजर इंटरफेस ऑब्जेक्ट का जीवन चक्र समाप्त होने पर Webservice डेटा खो Webservice है। यह व्यवहार एक अवांछनीय उपयोगकर्ता अनुभव बनाता है।

इसके बजाय, हमारा ViewModel डेटा को एक नए संग्रहण मॉड्यूल में पुनः प्राप्त करने की प्रक्रिया को दर्शाता है।

रिपोजिटरी मॉड्यूल डेटा संचालन को संभालते हैं। वे एक साफ एपीआई प्रदान करते हैं ताकि बाकी एप्लिकेशन को यह डेटा आसानी से मिल सके। उन्हें पता है कि डेटा को कहाँ से प्राप्त करना है और डेटा को अपडेट करते समय एपीआई क्या करना है। आप विभिन्न डेटा स्रोतों, जैसे लगातार मॉडल, वेब सेवाओं और कैश के बीच बिचौलियों के रूप में रिपॉजिटरी के बारे में सोच सकते हैं।

हमारा UserRepository वर्ग, जो निम्न कोड स्निपेट में दिखाया गया है, उपयोगकर्ता डेटा को पुनः प्राप्त करने के लिए WebService एक उदाहरण का उपयोग करता है:

 class UserRepository { private val webservice: Webservice = TODO() // ... fun getUser(userId: String): LiveData<User> { //    .    . val data = MutableLiveData<User>() webservice.getUser(userId).enqueue(object : Callback<User> { override fun onResponse(call: Call<User>, response: Response<User>) { data.value = response.body() } //     . override fun onFailure(call: Call<User>, t: Throwable) { TODO() } }) return data } } 

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

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

घटकों के बीच निर्भरता का प्रबंधन

उपयोक्ता UserRepository वर्ग उपयोक्ता डेटा को पुनः प्राप्त करने के लिए Webservice का एक उदाहरण चाहिए। वह सिर्फ एक उदाहरण बना सकता है, लेकिन इसके लिए उसे Webservice वर्ग की निर्भरता को भी जानना होगा। इसके अलावा, UserRepository शायद एकमात्र वर्ग नहीं है जिसे वेब सेवा की आवश्यकता है। इस स्थिति के लिए हमें कोड को डुप्लिकेट करने की आवश्यकता है, क्योंकि हर वर्ग जिसे Webservice लिंक की आवश्यकता होती है, उसे और उसके आश्रितों को कैसे बनाना चाहिए, यह पता होना चाहिए। यदि प्रत्येक वर्ग एक नया WebService बनाता है, तो हमारा एप्लिकेशन बहुत संसाधन गहन हो सकता है।

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

• निर्भरता इंजेक्शन (DI) । निर्भरता इंजेक्शन कक्षाओं को बनाए बिना उनकी निर्भरता को परिभाषित करने की अनुमति देता है। रन टाइम में, एक और वर्ग इन निर्भरताओं को प्रदान करने के लिए जिम्मेदार है। हम Android अनुप्रयोगों में निर्भरता इंजेक्शन को लागू करने के लिए डैगर 2 लाइब्रेरी की सलाह देते हैं। डैगर 2 स्वचालित रूप से वस्तुओं को बनाता है, निर्भरता के पेड़ को दरकिनार करता है, और निर्भरता के लिए संकलन-समय की गारंटी प्रदान करता है।
• (सेवा स्थान) सेवा लोकेटर: सेवा लोकेटर टेम्पलेट एक रजिस्ट्री प्रदान करता है जिसमें कक्षाएं उनके निर्माण के बजाय उनकी निर्भरता प्राप्त कर सकती हैं।

DI का उपयोग करने की तुलना में सेवा रजिस्ट्री को लागू करना आसान है, इसलिए यदि आप DI में नए हैं, तो इसके बजाय टेम्पलेट का उपयोग करें: सेवा स्थान।

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

हमारा नमूना आवेदन वेबर सेवा की निर्भरता को प्रबंधित करने के लिए डैगर 2 का उपयोग करता है।

कनेक्ट ViewModel और संग्रहण

अब हम UserRepository ऑब्जेक्ट का उपयोग करने के लिए अपने UserProfileViewModel को संशोधित करते हैं:

 class UserProfileViewModel @Inject constructor( savedStateHandle: SavedStateHandle, userRepository: UserRepository ) : ViewModel() { val userId : String = savedStateHandle["uid"] ?: throw IllegalArgumentException("missing user id") val user : LiveData<User> = userRepository.getUser(userId) } 

कैशिंग

UserRepository कार्यान्वयन Webservice ऑब्जेक्ट के आह्वान को अमूर्त करता है, लेकिन चूंकि यह केवल एक डेटा स्रोत पर निर्भर करता है, इसलिए यह बहुत लचीला नहीं है।

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

यह डिज़ाइन निम्नलिखित कारणों से इष्टतम नहीं है:

• यह बहुमूल्य यातायात संसाधनों को खर्च करता है।
• यह उपयोगकर्ता को एक नए अनुरोध के पूरा होने की प्रतीक्षा करता है।

इन कमियों को दूर करने के लिए, हम अपने UserRepository एक नया डेटा स्रोत जोड़ते हैं, जो मेमोरी में User ऑब्जेक्ट्स को कैश करता है:

 // Dagger,        . @Singleton class UserRepository @Inject constructor( private val webservice: Webservice, //    .    . private val userCache: UserCache ) { fun getUser(userId: String): LiveData<User> { val cached = userCache.get(userId) if (cached != null) { return cached } val data = MutableLiveData<User>() userCache.put(userId, data) //     ,  ,  . //      . webservice.getUser(userId).enqueue(object : Callback<User> { override fun onResponse(call: Call<User>, response: Response<User>) { data.value = response.body() } //     . override fun onFailure(call: Call<User>, t: Throwable) { TODO() } }) return data } } 

लगातार डेटा

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

हालाँकि, एंड्रॉइड ओएस की प्रक्रिया पूरी होने के कुछ घंटों बाद यदि कोई उपयोगकर्ता एप्लिकेशन छोड़ता है और क्या करता है? इस स्थिति में हमारे वर्तमान कार्यान्वयन पर भरोसा करते हुए, हमें फिर से नेटवर्क से डेटा प्राप्त करने की आवश्यकता है। यह अपग्रेड प्रक्रिया केवल एक बुरा उपयोगकर्ता अनुभव नहीं है; यह बेकार भी है क्योंकि यह मूल्यवान मोबाइल डेटा की खपत करता है।

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

इस स्थिति से निपटने का सही तरीका एक निरंतर मॉडल का उपयोग करना है। कक्ष स्थायी डेटा लाइब्रेरी (DB) हमारी सहायता के लिए आता है।

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

नोट। यदि आपका एप्लिकेशन पहले से ही किसी अन्य समाधान का उपयोग करता है, जैसे कि SQLite ऑब्जेक्ट रिलेशनल मैपिंग (ORM), तो आपको मौजूदा समाधान को रूम से बदलने की आवश्यकता नहीं है। हालाँकि, यदि आप एक नया एप्लिकेशन लिख रहे हैं या किसी मौजूदा एप्लिकेशन को पुनर्गठित कर रहे हैं, तो हम आपके एप्लिकेशन डेटा को बचाने के लिए रूम का उपयोग करने की सलाह देते हैं। इस प्रकार, आप पुस्तकालय और क्वेरी सत्यापन के अमूर्त लाभ उठा सकते हैं।

कक्ष का उपयोग करने के लिए, हमें अपने स्थानीय लेआउट को परिभाषित करने की आवश्यकता है। सबसे पहले, हम अपने User डेटा मॉडल क्लास में @PrimaryKey एनोटेशन और क्लास id फील्ड में @PrimaryKey एनोटेशन @PrimaryKey । ये एनोटेशन हमारे डेटाबेस में तालिका के रूप में User को चिह्नित करते हैं, और तालिका की प्राथमिक कुंजी के रूप में id करते हैं:

 @Entity data class User( @PrimaryKey private val id: String, private val name: String, private val lastName: String ) 

फिर हम अपने आवेदन के लिए RoomDatabase को कार्यान्वित करके डेटाबेस वर्ग बनाते हैं:

 @Database(entities = [User::class], version = 1) abstract class UserDatabase : RoomDatabase() 

ध्यान दें कि UserDatabase सार है। कक्ष पुस्तकालय स्वचालित रूप से इसे लागू करता है। विवरण के लिए कक्ष के लिए दस्तावेज़ देखें।

अब हमें डेटाबेस में उपयोगकर्ता डेटा डालने का एक तरीका चाहिए। इस कार्य के लिए, हम एक डेटा एक्सेस ऑब्जेक्ट (DAO) बनाते हैं।

 @Dao interface UserDao { @Insert(onConflict = REPLACE) fun save(user: User) @Query("SELECT * FROM user WHERE id = :userId") fun load(userId: String): LiveData<User> } 

ध्यान दें कि load विधि LiveData के प्रकार का ऑब्जेक्ट लौटाती है। कक्ष जानता है कि डेटाबेस कब बदला गया है, और डेटा परिवर्तनों के सभी सक्रिय पर्यवेक्षकों को स्वचालित रूप से सूचित करता है। चूंकि कक्ष LiveData का उपयोग करता है, यह ऑपरेशन कुशल है; यह डेटा को केवल तभी अपडेट करता है जब कम से कम एक सक्रिय पर्यवेक्षक हो।

नोट: टेबल संशोधनों के आधार पर अमान्य होने के लिए कमरे की जाँच, जिसका अर्थ है कि यह झूठी सकारात्मक सूचनाएं भेज सकता है।

हमारे UserDao वर्ग को परिभाषित करने के बाद, हम अपने डेटाबेस वर्ग से DAO का संदर्भ देते हैं:

 @Database(entities = [User::class], version = 1) abstract class UserDatabase : RoomDatabase() { abstract fun userDao(): UserDao } 

अब हम कक्ष डेटा स्रोत को शामिल करने के लिए अपनी UserRepository को बदल सकते हैं:

 //  Dagger,         . @Singleton class UserRepository @Inject constructor( private val webservice: Webservice, //    .    . private val executor: Executor, private val userDao: UserDao ) { fun getUser(userId: String): LiveData<User> { refreshUser(userId) //   LiveData    . return userDao.load(userId) } private fun refreshUser(userId: String) { //    . executor.execute { // ,      . val userExists = userDao.hasUser(FRESH_TIMEOUT) if (!userExists) { //  . val response = webservice.getUser(userId).execute() //    . //   .  LiveData  , //        . userDao.save(response.body()!!) } } } companion object { val FRESH_TIMEOUT = TimeUnit.DAYS.toMillis(1) } } 

कृपया ध्यान दें कि यदि हमने UserRepository में डेटा स्रोत को बदल दिया है, तब भी हमें अपने UserProfileViewModel या UserProfileFragment को बदलने की आवश्यकता नहीं है। यह छोटा सा अपडेट हमारे एप्लिकेशन आर्किटेक्चर के लचीलेपन को प्रदर्शित करता है। यह परीक्षण के लिए भी बहुत अच्छा है क्योंकि हम एक नकली UserRepository प्रदान कर सकते हैं और एक ही समय में हमारे उत्पादन UserProfileViewModel परीक्षण कर सकते हैं।

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

सत्य का एकमात्र स्रोत।

आमतौर पर, अलग-अलग REST API समापन बिंदु एक ही डेटा वापस करते हैं। उदाहरण के लिए, यदि हमारे बैकएंड में एक और एंडपॉइंट है जो दोस्तों की सूची लौटाता है, तो एक ही उपयोगकर्ता ऑब्जेक्ट दो अलग-अलग एपीआई एंडपॉइंट्स से आ सकता है, संभवतः यहां तक ​​कि विस्तार के विभिन्न स्तरों का उपयोग भी कर सकता है। यदि हमने UserRepositoryअनुरोध Webserviceको प्रतिक्रिया के रूप में वापस लिया है, तो स्थिरता के लिए जाँच किए बिना, हमारे उपयोगकर्ता इंटरफ़ेस भ्रामक जानकारी दिखा सकते हैं, क्योंकि भंडारण से डेटा का संस्करण और प्रारूप अंतिम कहा जाने वाले बिंदु पर निर्भर करेगा।

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

ऑपरेशन की प्रगति दिखाएं

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

उपयोगकर्ता इंटरफ़ेस में सहमत डेटा अपडेट की स्थिति प्रदर्शित करने के लिए हम निम्नलिखित रणनीतियों में से एक का उपयोग कर सकते हैं, चाहे डेटा अपडेट अनुरोध कहां से आया हो:

• getUser () , LiveData . . , NetworkBoundResource GitHub android-Architecture-components .
• UserRepository , . , , , pull-to-refresh.

हितों के पृथक्करण पर खंड में, हमने उल्लेख किया कि इस सिद्धांत का पालन करने का एक मुख्य लाभ परीक्षणनीयता है।

निम्नलिखित सूची से पता चलता है कि हमारे विस्तारित उदाहरण से प्रत्येक कोड मॉड्यूल का परीक्षण कैसे करें:

• यूजर इंटरफेस और इंटरेक्शन : एंड्रॉइड यूआई टेस्ट टूलकिट का उपयोग करें । इस परीक्षण को बनाने का सबसे अच्छा तरीका एस्प्रेसो पुस्तकालय का उपयोग करना है । आप एक टुकड़ा बना सकते हैं और इसे एक लेआउट प्रदान कर सकते हैं UserProfileViewModel। चूंकि टुकड़ा केवल के साथ जुड़ा हुआ है UserProfileViewModel, केवल इस वर्ग का मजाक (नकल) आपके आवेदन के उपयोगकर्ता इंटरफ़ेस का पूरी तरह से परीक्षण करने के लिए पर्याप्त है।
• ViewModel: UserProfileViewModel JUnit . , UserRepository .
• UserRepository: UserRepository JUnit. Webservice UserDao . :
  
  
  • -.
  • .
  • , .
  
  
• Webservice , UserDao , .
• UserDao: DAO . - , . , , , …
  
  : Room , DAO, JSQL SupportSQLiteOpenHelper . , SQLite SQLite .
• -: . , -, . , MockWebServer , .
• : maven . androidx.arch.core : JUnit:
  
  
  • InstantTaskExecutorRule: .
  • CountingTaskExecutorRule: . Espresso .
  
  

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

हालाँकि, निम्नलिखित अनुशंसाओं की आवश्यकता नहीं है, हमारे अनुभव से पता चलता है कि उनका कार्यान्वयन आपके कोड आधार को अधिक विश्वसनीय, परीक्षण योग्य और लंबे समय में समर्थित बनाता है:

आपके एप्लिकेशन के प्रवेश बिंदुओं जैसे - क्रियाओं, सेवाओं और प्रसारण रिसीवर - डेटा स्रोतों के रूप में डिज़ाइन करने से बचें।

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

अपने एप्लिकेशन के विभिन्न मॉड्यूल के बीच जिम्मेदारी की स्पष्ट रेखाएं बनाएं।

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

प्रत्येक मॉड्यूल से जितना संभव हो उतना कम एक्सपोज़ करें।

एक "सिर्फ एक" लेबल बनाने के प्रलोभन का विरोध करें जो एक मॉड्यूल से आंतरिक कार्यान्वयन के विवरण को प्रकट करता है। आप अल्पावधि में कुछ समय प्राप्त कर सकते हैं, लेकिन तब आपका कोड आधार विकसित होने पर आप कई बार तकनीकी ऋण ले लेंगे।

अलगाव में प्रत्येक मॉड्यूल को परीक्षण योग्य बनाने के बारे में सोचें।

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

अन्य एप्लिकेशन से बाहर खड़े होने के लिए अपने एप्लिकेशन के अद्वितीय कोर पर ध्यान दें।

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

जितना संभव हो उतना प्रासंगिक और ताजा डेटा रखें।

इस प्रकार, उपयोगकर्ता आपके एप्लिकेशन की कार्यक्षमता का आनंद ले सकते हैं, भले ही उनका डिवाइस ऑफ़लाइन हो। याद रखें कि आपके सभी उपयोगकर्ता लगातार उच्च गति वाले कनेक्शन का उपयोग नहीं करते हैं।

एकल डेटा स्रोत को केवल सही स्रोत के रूप में नामित करें।

जब भी आपके एप्लिकेशन को डेटा के इस टुकड़े तक पहुंच की आवश्यकता होती है, तो इसे हमेशा सत्य के इस एकल स्रोत से आना चाहिए।

परिशिष्ट: नेटवर्क की स्थिति का खुलासा

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

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

निम्नलिखित कोड स्निपेट एक उदाहरण कार्यान्वयन प्रदान करता हैResource:

 //  ,         . sealed class Resource<T>( val data: T? = null, val message: String? = null ) { class Success<T>(data: T) : Resource<T>(data) class Loading<T>(data: T? = null) : Resource<T>(data) class Error<T>(message: String, data: T? = null) : Resource<T>(data, message) } 

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

निम्नलिखित आरेख के लिए निर्णय ट्री दिखाता है NetworkBoundResource:



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

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

. . , .

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

इसके अलावा, नेटवर्क से प्राप्त परिणाम न भेजें, क्योंकि यह सत्य के एकल स्रोत के सिद्धांत का उल्लंघन करता है। अंत में, यह संभव है कि डेटाबेस में ट्रिगर्स होते हैं जो सहेजने के दौरान डेटा मानों को बदलते हैं। इसी तरह, नए डेटा के बिना `SUCCESS` न भेजें, क्योंकि तब क्लाइंट को डेटा का गलत संस्करण प्राप्त होगा।

निम्न कोड स्निपेट NetworkBoundResourceअपने उपवर्गों के लिए कक्षा द्वारा प्रदान की गई खुली एपीआई दिखाता है :

 // ResultType:   . // RequestType:   API. abstract class NetworkBoundResource<ResultType, RequestType> { //      API   . @WorkerThread protected abstract fun saveCallResult(item: RequestType) //      ,  ,    //     . @MainThread protected abstract fun shouldFetch(data: ResultType?): Boolean //        . @MainThread protected abstract fun loadFromDb(): LiveData<ResultType> //     API. @MainThread protected abstract fun createCall(): LiveData<ApiResponse<RequestType>> // ,    .   //    ,    . protected open fun onFetchFailed() {} //   LiveData,  , //    . fun asLiveData(): LiveData<ResultType> = TODO() } 

कक्षा की परिभाषा के निम्नलिखित महत्वपूर्ण विवरणों पर ध्यान दें:

• यह दो प्रकार के मापदंडों को परिभाषित करता है, ResultTypeऔर RequestTypeचूंकि एपीआई से लौटाए गए डेटा प्रकार स्थानीय स्तर पर उपयोग किए जाने वाले डेटा प्रकार के अनुरूप नहीं हो सकते हैं।
• यह ApiResponseनेटवर्क अनुरोधों के लिए एक वर्ग का उपयोग करता है । ApiResponseएक वर्ग के लिए एक सरल आवरण Retrofit2.Callहै जो प्रतिक्रियाओं को उदाहरणों में परिवर्तित करता है LiveData।

कक्षा का पूर्ण कार्यान्वयन GitHub Android-Architecture-ComponentsNetworkBoundResource परियोजना के भाग के रूप में दिखाई देता है । एक बार बनाने के बाद, हम इसका उपयोग कक्षा में हमारी डिस्क और नेटवर्क से जुड़े कार्यान्वयन को लिखने के लिए कर सकते हैं :

NetworkBoundResourceUserUserRepository

 //  Dagger2,         . @Singleton class UserRepository @Inject constructor( private val webservice: Webservice, private val userDao: UserDao ) { fun getUser(userId: String): LiveData<User> { return object : NetworkBoundResource<User, User>() { override fun saveCallResult(item: User) { userDao.save(item) } override fun shouldFetch(data: User?): Boolean { return rateLimiter.canFetch(userId) && (data == null || !isFresh(data)) } override fun loadFromDb(): LiveData<User> { return userDao.load(userId) } override fun createCall(): LiveData<ApiResponse<User>> { return webservice.getUser(userId) } }.asLiveData() } }