सी के बिना एमवीसी: एप्लीकेशन आर्किटेक्चर में स्विफ्टयूआई को क्या बदलेगा?

एमवीसी आईओएस एप्लिकेशन लिखने के लिए उपयोग किए जाने वाले डिजाइन पैटर्न में एक लंबे समय से मानक रहा है। IOS एप्लिकेशन की संरचना जो पहले बनाई गई थी, एक मूल घटक पर आधारित थी, जो हर जगह मौजूद है, और इसे नियंत्रक कहा जाता है। SwiftUI , जिसके पास ऐसा कोई घटक नहीं है, को WWDC19 में पेश किया गया था।

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

अप्रत्यक्ष और द्विदिश आर्किटेक्चर

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

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

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

स्विफ्टयूआई में डेटा प्रवाह

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

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


यदि आप MVC डालते हैं और एक चार्ट में संग्रहीत करते हैं, तो वे कुछ इस तरह दिख सकते हैं।

पहली नज़र में, कंबाइन SwiftUI में इस्तेमाल किया जाने वाला वास्तुशिल्प पैटर्न प्रतीत हो सकता है। लेकिन कंबाइन समय के साथ प्रसंस्करण मूल्यों के लिए सिर्फ एक उपकरण है। इसी तरह, RxSwift का उपयोग करने वाला MVVM अभी भी MVVM है, परतों के बीच की एक कड़ी है, जिसे कई तरह से लागू किया जाता है।

घोषणात्मक उपयोगकर्ता इंटरफेस के लिए घोषणात्मक वास्तुकला

स्विफ्टयूआई को कुछ शब्दों में संक्षेपित किया जा सकता है, जैसे कि एक घोषणात्मक उपयोगकर्ता इंटरफ़ेस । मेरा मानना ​​है कि अधिक प्राप्त किया जा सकता है यदि आप बॉक्स के बाहर सोचते हैं और " घोषणात्मक " शब्द पर ध्यान केंद्रित करते हैं। फ्रंट-एंड एप्लिकेशन डेवलपमेंट में सबसे उन्नत घोषणात्मक वास्तु उदाहरण पाए जा सकते हैं। ELM, Redux और Flux जैसी अवधारणाओं का उपयोग आसानी से SwiftUI और Combine बुनियादी ढांचे के साथ किया जा सकता है। स्विफ्ट में पहले से ही कई पुन: कार्यान्वयन थे जैसे कि ReSwift , लेकिन फिर भी इन कार्यान्वयनों को कॉम्बिनेशन में संयोजित करना आवश्यक होगा।


WWDC19 से स्विफ्टयूआई में थोड़ा संशोधित डेटा फ्लो

मैं किसी भी निर्भरता के बिना शुरुआत से ही स्विफ्टयूआई के साथ खेलना चाहूंगा, और मैं वर्तमान में स्विफ्ट में ईएलएम वास्तुकला के एक सरल कार्यान्वयन के साथ प्रयोग कर रहा हूं। यह आर्किटेक्चर एप्पल द्वारा WWDC में दिखाए गए आरेखों से बेहतर मेल खाता है।

हम इन वास्तु पैटर्न के माध्यम से आवेदन का वर्णन कर सकते हैं:

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

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


स्टेट, एक्ट्स और एक साधारण स्विफ्ट एप्लिकेशन के लिए अपडेट करें।

अतुल्यकालिक संचालन के लिए, हम Redux या CommM में ELM में एक मिडलवेयर ऑब्जेक्ट की तरह कुछ पेश कर सकते हैं।

निष्कर्ष

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

यदि आप निकट भविष्य में SwiftUI का उपयोग करके किसी एप्लिकेशन को विकसित करने के बारे में सोचते हैं, तो मैं कुछ बिंदुओं पर ध्यान देने की सलाह दूंगा:

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

मेरे प्रयोग खेल के मैदान स्विफ्ट में पाए जा सकते हैं (तुलना के लिए, यह UIKit और SwiftUI के कार्यान्वयन और उपयोग को प्रस्तुत करता है, वही अनुप्रयोग)।

अगले चरण

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

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