कोटलिन पर आधारित आधुनिक एमवीआई वास्तुकला

पिछले दो वर्षों में, Badoo पर एंड्रॉइड डेवलपर्स ने एमवीपी से आवेदन वास्तुकला के लिए एक पूरी तरह से अलग दृष्टिकोण के लिए एक लंबा, कांटेदार मार्ग आ गया है। ANublo और मैं अपने सहकर्मी Zsolt Kocsi द्वारा एक लेख का अनुवाद साझा करना चाहते हैं, जिसमें हमने उन समस्याओं और उनके समाधान का वर्णन किया है।

कोटलिन पर आधुनिक एमवीआई वास्तुकला के विकास के लिए समर्पित कई लेखों में से यह पहला है।

आइए शुरुआत से शुरू करें: राज्य की समस्याएं

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

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

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

लेकिन यह हमेशा भाग्यशाली है। यह प्रणाली जितनी जटिल है, उतनी ही अप्रत्याशित स्थिति का सामना करने की संभावना है, जिसमें से डीबगिंग बुरे सपने में लंबे समय तक एक सपना होगा।

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

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

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

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

खोज कहाँ से शुरू करें?

स्पॉयलर: यह क्लीन आर्किटेक्चर का दोष नहीं है - हमेशा की तरह, मानव कारक को दोष देना है। अंत में, निश्चित रूप से, हमने इन बगों को ठीक कर दिया, लेकिन इस पर बहुत समय और प्रयास किया। तब हमने सोचा: क्या इन समस्याओं से बचने का एक आसान तरीका है?

सुरंग के अंत में प्रकाश ...

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

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

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

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

Reducer = (State, Intent) -> State

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

• StartedLoading
  
• FinishedWithSuccess
  

फिर आप निम्नलिखित नियमों के साथ Reducer बना सकते हैं:

1. स्टार्टडेलडिंग के मामले में , पुराने की प्रतिलिपि बनाकर एक नया स्टेट ऑब्जेक्ट बनाएं और वैल्यू हैडिंग को सही पर सेट करें।
   
2. FinishWithSuccess के मामले में , एक नया स्टेट ऑब्जेक्ट बनाएं, पुराने को कॉपी करते हुए, जिसमें आइलिडिंग मान गलत पर सेट किया जाएगा, और पेलोड मान होगा
   मैच अपलोड किया गया।
   

यदि हम परिणामी राज्य श्रृंखला को लॉग में आउटपुट करते हैं, तो हम निम्नलिखित देखेंगे:

1. राज्य ( पेलोड = अशक्त, isLading = false) - प्रारंभिक अवस्था।
   
2. राज्य ( पेलोड = अशक्त, isLading = true) - शुरुआत के बाद।
   
3. राज्य ( पेलोड = डेटा, isLading = false) - फिनविथसाउट के बाद।
   

इन राज्यों को UI से जोड़कर, आप प्रक्रिया के सभी चरणों को देखेंगे: पहले एक रिक्त स्क्रीन, फिर एक लोडिंग स्क्रीन और अंत में, आवश्यक डेटा।

इस दृष्टिकोण के कई फायदे हैं।

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

या नहीं?

... शायद ट्रेन आप पर सवार हो

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

MVI फ्रेमवर्क आवश्यकताएँ

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

इसके अलावा:

• इसे आसानी से सिस्टम के अन्य घटकों के साथ बातचीत करनी चाहिए;
  
• इसकी आंतरिक संरचना में कर्तव्यों का स्पष्ट पृथक्करण होना चाहिए;
  
• घटक के सभी आंतरिक भागों को पूरी तरह से नियतात्मक होना चाहिए;
  
• इस तरह के एक घटक का मूल कार्यान्वयन केवल सरल और जटिल होना चाहिए, अगर अतिरिक्त तत्वों की आवश्यकता हो।
  

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

और फिर भी, चीजों की वर्तमान स्थिति सभी के लिए उपयुक्त है। हम आपको एमवीआईसी शुरू करने के लिए खुश हैं! लाइब्रेरी का स्रोत कोड GitHub पर खुला और उपलब्ध है ।

अच्छा एमवीआईसी क्या है

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

फ़ीचर का संक्षिप्त परिचय

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

फ़ीचर - फ्रेमवर्क का केंद्रीय तत्व जिसमें घटक के सभी व्यावसायिक तर्क शामिल हैं। फ़ीचर को तीन मापदंडों द्वारा परिभाषित किया गया है: इंटरफ़ेस फ़ीचर <विश, स्टेट, न्यूज़>

इच्छा मॉडल-व्यू-इंटेंट के इरादे से मेल खाती है - ये वे बदलाव हैं जो हम मॉडल में देखना चाहते हैं (चूंकि इंटेंट शब्द का Android डेवलपर्स के वातावरण में इसका अर्थ है, हमें एक अलग नाम खोजना होगा)। विश फीचर के लिए प्रवेश बिंदु है।

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

समाचार - प्रसंस्करण संकेतों के लिए एक घटक जो राज्य में नहीं होना चाहिए; निर्माण के दौरान एक बार समाचार का उपयोग किया जाता है ( SingleLiveEvent समस्या )। समाचार का उपयोग करना वैकल्पिक है (आप फ़ीचर हस्ताक्षर में कोटलिन से कुछ भी उपयोग नहीं कर सकते हैं)।

इसके अलावा फ़ीचर में Reducer मौजूद होना चाहिए।

फ़ीचर में निम्नलिखित घटक हो सकते हैं:

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

चित्र सरल लग सकता है:


या उपरोक्त सभी अतिरिक्त घटकों को शामिल करें:


सभी व्यावसायिक तर्क और उपयोग के लिए तैयार होने वाले फ़ीचर, कहीं आसान नहीं दिखते:

और क्या?

फ़ीचर, रूपरेखा की आधारशिला, वैचारिक स्तर पर काम करती है। लेकिन पुस्तकालय में बहुत कुछ है।

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

हमें उम्मीद है कि आप हमारे पुस्तकालय की कोशिश करेंगे और इसके उपयोग से आपको हमारे लिए बहुत खुशी मिलेगी - इसका निर्माण!

24 और 25 नवंबर को, आप अपना हाथ आज़मा सकते हैं और हमसे जुड़ सकते हैं! हम एक मोबाइल हायरिंग इवेंट आयोजित करेंगे: एक दिन में चयन के सभी चरणों से गुजरना और एक प्रस्ताव प्राप्त करना संभव होगा। आईओएस और एंड्रॉइड टीमों के मेरे सहयोगी मास्को में उम्मीदवारों के साथ संवाद करने के लिए आएंगे। यदि आप किसी दूसरे शहर से हैं, तो सगाई की यात्रा की लागत बढ़ जाती है। निमंत्रण पाने के लिए, लिंक पर स्क्रीनिंग टेस्ट से गुजरें । सौभाग्य है