#⃣ 🎍 🔱 HandsAppMVP: स्टूडियो विकास आउटसोर्सिंग के लिए iOS आर्किटेक्चर 💅 🤰🏿 📜

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

IOS के विकास में, वास्तुकला मुख्य रूप से एक विशिष्ट ViewController के लिए कक्षाओं और निर्भरता के संगठन को निर्धारित करता है। हालांकि, केंद्रीय घटक न केवल वह हो सकता है, बल्कि केवल यूआईवीईवाई भी हो सकता है। चुनाव विशिष्ट कार्य पर निर्भर करता है।

वास्तुकला की तुलना

IOS के लिए कई मानक वास्तुशिल्प टेम्पलेट हैं: MVC, MVP, MVVM, VIPER (प्रत्येक के विवरण के लिंक लेख के अंत में पाए जा सकते हैं)।

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

आउटसोर्सिंग टीम के लिए, विकास की गति विशेष रूप से महत्वपूर्ण है। VIPER सबसे जटिल और "धीमा" आर्किटेक्चर है, शुद्ध MVP या MVVM का उपयोग करके विकास तेजी से होता है, क्योंकि उनके पास कम घटक होते हैं।

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

और अंतिम पैरामीटर जिसे हमने माना है कि प्रवेश सीमा है। यह दिखाता है कि नए डेवलपर्स (सबसे पहले, जोनों) वास्तुकला में कैसे प्रवेश करते हैं। यहां एमवीवीएम तीसरे पक्ष के प्रतिक्रियाशील पुस्तकालयों (RxSwift, PromiseKit, आदि) का उपयोग करके स्पष्ट कारणों के लिए एक सम्मानजनक अंतिम स्थान लेता है। बड़ी संख्या में घटकों के कारण VIPER भी एक जटिल संरचना है। एमवीपी में सबसे कम प्रवेश सीमा है।

पेशेवरों और विपक्षों के वजन के बाद, हम इस निष्कर्ष पर पहुंचे कि हमें एमवीपी के रूप में सरल और वीआईपी के रूप में लचीले रूप में कुछ चाहिए। तो विचार उनके आधार पर अपनी खुद की वास्तुकला बनाने के लिए पैदा हुआ था - HandsAppMVP।

MVP का विस्तार करें

हमारी वास्तुकला के मुख्य घटक मॉडल, दृश्य, प्रस्तुतकर्ता हैं। वे प्रसिद्ध एमवीपी की तरह ही प्रसिद्ध योजना के अनुसार कार्य करते हैं:

[शास्त्रीय एमवीपी की योजना]

यहां और नीचे, आरेख में प्रत्येक इंटरैक्शन घटक (नीला वर्ग) एक वर्ग है जिसका जीवनकाल दृश्य के जीवनकाल के साथ मेल खाता है। एक ठोस तीर किसी अन्य ऑब्जेक्ट के स्वामित्व, एक मजबूत लिंक और एक बिंदीदार तीर से कमजोर लिंक को इंगित करता है। कमजोर संदर्भों के साथ, हम परिपत्र निर्भरता और मेमोरी लीक को रोकते हैं।

इंटरफेस

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

[व्यूइनपुट और व्यूऑटपुट इंटरफेस को जोड़ना] एक

छोटी आयत एक इंटरफ़ेस है।

एक चौकस डेवलपर पूछेगा, मॉडल के लिए इंटरफेस कहाँ हैं? अब हम उनकी ओर मुड़ते हैं।

डेटा के साथ काम करें

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

वह वर्ग जो किसी विशेष प्रकार के डेटा कंटेनर के साथ बातचीत के लिए जिम्मेदार है, हम डेटा सेवा को कॉल करते हैं। प्रत्येक कंटेनर के लिए (दूरस्थ डेटाबेस, स्थानीय डेटाबेस, UserDefaults, आदि), एक सेवा वर्ग हैंड्सऐपएमवीपी में जोड़ा जाता है जो प्रस्तुतकर्ता के साथ बातचीत करता है। अब आप प्रत्येक डेटा सेवा के लिए इनपुट / आउटपुट इंटरफेस भी जोड़ सकते हैं:

[डेटा के साथ काम करने के लिए सेवाएं जोड़ना]

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

यह उदाहरण एक नियम से अधिक अपवाद है, और दिखाता है कि एसओएलआईडी का पालन हमेशा सबसे अच्छा समाधान नहीं है।

पथ प्रदर्शन

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

[नेविगेशन (राउटर) के लिए एक घटक जोड़ना]

घटक विधानसभा

क्लासिक एमवीपी का अंतिम जोड़ जो हम उपयोग करते हैं वह असेंबली, एक कलेक्टर वर्ग है। इसका उपयोग हैंड्सएपएमवीपी के दृश्य और अन्य घटकों को शुरू करने के लिए किया जाता है, साथ ही साथ निर्भरता को लागू करने के लिए भी। असेंबली में एकमात्र सार्वजनिक विधि होती है - `असेंबल () -> UIViewController`, जिसका परिणाम आवश्यक निर्भरता ग्राफ के साथ वांछित UIViewController (या UIView) है।

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

कोड जनरेशन

समय बचाने के लिए, हमने Generamba का उपयोग करके HandsAppMVP क्लासेस बनाने की प्रक्रिया को स्वचालित किया। Generamba के लिए उपयोग किए जाने वाले टेम्प्लेट हमारी रिपॉजिटरी में पाए जा सकते हैं। जेनम्बा के लिए एक उदाहरण विन्यास डेमो प्रोजेक्ट में है।

एक विशिष्ट स्क्रीन उत्पन्न करने के परिणामस्वरूप, हमें उन कक्षाओं का एक सेट मिलता है जो हैंड्सऐपएमवीपी योजना से मेल खाते हैं, जो घटकों को बनाने और कार्यान्वित करने के लिए यूनिट परीक्षणों का एक समूह है, और प्रस्तुतकर्ता परीक्षणों के लिए एक टेम्पलेट वर्ग भी है।

क्या हुआ

यदि आप Head-to-Head HandsAppMVP और VIPER की तुलना करते हैं, तो आप देखेंगे कि वे बहुत समान हैं और पहले केवल इंटरएक्टर घटक की अनुपस्थिति द्वारा प्रतिष्ठित है। लेकिन, सेवाओं और वर्तमान (इंटरेक्टर) के बीच की परत से छुटकारा पाने के साथ-साथ मोया का उपयोग कर नेटवर्क के साथ बातचीत को सरल बनाना, हमें विकास की गति में एक उल्लेखनीय वृद्धि मिली।

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

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

निष्कर्ष में, हम आईओएस अनुप्रयोगों की वास्तुकला पर कुछ अच्छे लेखों की सलाह देते हैं जो हमें पेचीदगियों को समझने और हमारी पसंद बनाने में मदद करते हैं:

SurfStudio का ओपन-सोर्स प्रलेखन भी बहुत सहायक और प्रेरित था ।

अंत में, हम हैंड्सएपएमवीपी में लिखे DEMO प्रोजेक्ट पर एक लिंक डाल रहे हैं , जिसका हमने लेख में बार-बार उल्लेख किया है।

HandsAppMVP: स्टूडियो विकास आउटसोर्सिंग के लिए iOS आर्किटेक्चर