मॉड्यूलर विकास या वहाँ रास्ता, वापस नहीं

हम RaiffeisenBank iOS एप्लिकेशन में मॉड्यूल के साथ काम करने के लिए एक नए दृष्टिकोण पर कैसे आए।

समस्या

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

हमें किन कठिनाइयों का सामना करना पड़ा:

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

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

हाइलाइटिंग रूटिंग लॉजिक
दृश्य इकाई के रूप में एक मॉड्यूल को यह नहीं पता होना चाहिए कि उसे कहां और कैसे दिखाया गया है। एक और एक ही मॉड्यूल को किसी भी स्क्रीन पर या एक रचना के रूप में एक स्वतंत्र इकाई के रूप में लागू किया जाना चाहिए। इसके लिए जिम्मेदार को मॉड्यूल पर ही दोषी नहीं ठहराया जा सकता है।

पिछला समाधान: // बुरा व्यवसाय

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

यह एक कदम आगे था, लेकिन नई कठिनाइयाँ उत्पन्न हुईं:

• प्रॉक्सी इंटरफ़ेस ने इनपुट प्रोटोकॉल के कार्यान्वयन की गारंटी नहीं दी;
• आउटपुट का वर्णन किया जाना था, भले ही इसकी आवश्यकता न हो;
• इनपुट इंटरफ़ेस में आउटपुट प्रॉपर्टी को जोड़ना आवश्यक था।

NSProxy के अलावा , हमने ViperMcFlurry के विचार को देखते हुए रूटिंग को भी लागू किया: हमने ViewController पर एक श्रेणी बनाई, जो स्क्रीन पर मॉड्यूल प्रदर्शित करने के लिए विभिन्न विकल्पों के रूप में विकसित होने लगी। बेशक, हमने श्रेणी को विभाजित किया, लेकिन यह अभी भी एक अच्छे समाधान से दूर था।

सामान्य तौर पर ... पहला पैनकेक लम्पट होता है, यह स्पष्ट हो गया कि आपको समस्या को अलग तरीके से हल करने की आवश्यकता है।

हल: // अंतिम

यह महसूस करते हुए कि NSProxy के साथ आगे कुछ नहीं था, हमने मार्करों को लिया और ड्रा करने गए। परिणामस्वरूप, हमने RFModule प्रोटोकॉल को अलग किया:

@objc protocol RFModule { var view: ViewController { get } var input: AnyObject? { get } var output: AnyObject? { get set } var transition: Transitioning { get set } } 

हमने प्रोटोकॉल स्तर पर संबद्ध प्रकारों को जानबूझकर छोड़ दिया, और इसका एक अच्छा कारण था: उस समय, 90% कोड ऑब्जेक्टिव-सी में था। ObjC मॉड्यूल के बीच अंतर ← → स्विफ्ट संभव नहीं होगा।

अभी भी जेनरिक का उपयोग करने और मॉड्यूल के टाइप किए गए उपयोग को सुनिश्चित करने के लिए, हमने प्रोटोकॉल को संतुष्ट करने वाले मॉड्यूल वर्ग को पेश किया
RFModule :

 final class Module<I: Any, O: Any>: RFModule { public typealias Input = I public typealias Output = O public var setOutput: ((O?) -> Void)? //... public var input: I? { get { return inputObjc as? I} set { inputObjc = newValue as AnyObject } } public var output: O? { get { return outputObjc as? O} set { outputObjc = newValue as AnyObject } } @objc(input) public weak var inputObjc: AnyObject? @objc(moduleOutput) public weak var outputObjc: AnyObject? { didSet{ setOutput?(output) } } } @objc protocol RFModule { var view: ViewController { get } @objc(input) var inputObjc: AnyObject? { get } @objc(moduleOutput) var outputObjc: AnyObject? { get set } var transition: Transitioning { get set } } public extension RFModule { public var input: AnyObject? { return inputObjc } public var output: AnyObject? { get { return outputObjc } set { outputObjc = newValue} } } 

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

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

 class SomeViewController: UIViewController, ModuleInput { weak var delegate: ModuleOutput } class Assembly { func someModule() -> Module<ModuleInput, ModuleOutput> { let view = SomeViewController() let module = Module<ModuleInput, ModuleOutput>(view: view, input: view) { [weak view] output in view?.delegate = output } return module } } ... let assembly: Assembly let module = assembly.someModule() module.output = self 

संक्रमण एक प्रोटोकॉल है जिसका कार्यान्वयन, जैसा कि नाम से पता चलता है, मॉड्यूल को दिखाने और छिपाने के तर्क के लिए जिम्मेदार हैं।

 protocol Transitioning { var destination: ViewController? { get } // should be weak func perform(_ completion: (()->())?) // present func reverse(_ completion: (()->())?) // dissmiss } 

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

 class PresentTransition: Transitioning { weak var source: ViewController? weak var destination: ViewController? ... func perform(_ completion: (()->())?) { source.present(viewController: self.destinaton) } } 

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

क्या वह सब है?

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

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