समन्वयक पैटर्न समस्याओं और क्या करता है। इसके साथ क्या करना है

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

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

मैंने पहले से ही स्टैक पर नियंत्रकों के दृष्टिकोण को बनाने के तरीके के विखंडन का सवाल उठाया है, और पुनरावृत्ति से बचने के लिए, आप बस इसके बारे में यहां पढ़ सकते हैं ।

चलो ईमानदार हो। कुछ बिंदु पर, एपोल ने महसूस किया कि एप्लिकेशन डेवलपमेंट सेंटर में नियंत्रकों को डालकर, उसने उनके बीच डेटा बनाने या स्थानांतरित करने के लिए कोई भी समझदार तरीका नहीं पेश किया, और डेवलपर्स को इस समस्या का समाधान सौंपा, यह Xcode से स्वतः पूर्ण था, और शायद UISearchConnroller डेवलपर्स के लिए। कुछ बिंदुओं पर स्टोरीबोर्ड पेश किए गए और हमसे बहस हुई। फिर, एपोलस ने महसूस किया कि उसने 2 स्क्रीन से युक्त अनुप्रयोगों को केवल स्वयं लिखा है, और अगले पुनरावृत्ति में उसने स्टोरीबोर्ड को कई घटकों में तोड़ने की संभावना का सुझाव दिया, क्योंकि स्टोरीबोर्ड एक निश्चित आकार में पहुंचने पर Xcode दुर्घटनाग्रस्त हो गया। इस अवधारणा के साथ, कई पुनरावृत्तियों में तर्क बदल गए हैं जो एक दूसरे के साथ बहुत संगत नहीं हैं। उनके समर्थन को बड़े पैमाने पर UIViewController वर्ग में सिल दिया गया है, और अंत में, हमें वही मिला जो हमें मिला था। यहाँ यह है:

 override func prepare(for segue: UIStoryboardSegue, sender: Any?) { if segue.identifier == "showDetail" { if let indexPath = tableView.indexPathForSelectedRow { let object = objects[indexPath.row] as! NSDate let controller = (segue.destination as! UINavigationController).topViewController as! DetailViewController controller.detailItem = object controller.navigationItem.leftBarButtonItem = splitViewController?.displayModeButtonItem controller.navigationItem.leftItemsSupplementBackButton = true } } } 

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

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

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

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

मैं संक्षेप में बताऊंगा कि आगे बढ़ने से पहले इसमें क्या है।

सभी व्याख्याओं में समन्वयक पैटर्न लगभग इस तस्वीर में फिट बैठता है:

यही है, समन्वयक एक प्रोटोकॉल है

 protocol Coordinator { func start() } 

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

हालाँकि, बहुत जल्द ही निर्जीव शुरू हो जाते हैं:

1. कुछ कार्यान्वयन समन्वयक को कुछ अधिक उचित पैटर्न में मोड़ने का प्रस्ताव देते हैं, जो नियंत्रकों के ढेर को देखते हैं और इसे कंटेनर का एक प्रतिनिधि बनाते हैं , उदाहरण के लिए, UINavigationController बैक बटन पर क्लिक करने या वापस स्वाइप करने और बच्चे के समन्वयक को हटाने की प्रक्रिया के लिए। प्राकृतिक कारणों के लिए, केवल एक वस्तु एक प्रतिनिधि हो सकती है, जो कंटेनर के नियंत्रण को सीमित करता है और इस तथ्य की ओर जाता है कि यह तर्क या तो समन्वयक के पास है, या इस तर्क को आगे किसी और को सूची में नीचे लाने की आवश्यकता पैदा करता है।
2. अक्सर अगला नियंत्रक बनाने का तर्क व्यावसायिक तर्क पर निर्भर करता है । उदाहरण के लिए, अगली स्क्रीन पर जाने के लिए, उपयोगकर्ता को सिस्टम में लॉग इन होना चाहिए। स्पष्ट रूप से, यह एक अतुल्यकालिक प्रक्रिया है, जिसमें लॉगिन फॉर्म के साथ कुछ मध्यवर्ती स्क्रीन उत्पन्न करना शामिल है, लॉगिन प्रक्रिया स्वयं सफलतापूर्वक समाप्त हो सकती है या नहीं। समन्वयक को एक बड़े समन्वयक (बड़े पैमाने पर देखने वाले नियंत्रक के समान) में बदलने से बचने के लिए, हमें अपघटन की आवश्यकता होती है। यही है, वास्तव में, आपको एक समन्वयक समन्वयक बनाने की आवश्यकता है।
3. समन्वयकों के सामने एक और समस्या यह है कि वे आवश्यक रूप से कंटेनर व्यू कंट्रोलर्स जैसे कि UINavigationController , UITabBarController और इसी तरह के लिए रैपर हैं। और किसी को इन नियंत्रकों को लिंक प्रदान करना चाहिए। यदि बाल समन्वयकों के साथ सब कुछ कम स्पष्ट है, तो श्रृंखला के प्रारंभिक समन्वयकों के साथ, सब कुछ इतना सरल नहीं है। इसके अलावा, जब नेविगेशन बदलते हैं, उदाहरण के लिए ए / बी परीक्षण के लिए, ऐसे संयोजकों के रिफैक्टिंग और अनुकूलन के परिणामस्वरूप एक अलग सिरदर्द होता है। खासकर अगर कंटेनर का प्रकार बदलता है।
4. यह सब तब और अधिक जटिल हो जाता है जब अनुप्रयोग बाहरी घटनाओं का समर्थन करना शुरू कर देता है जो दृश्य नियंत्रक उत्पन्न करते हैं। जैसे पुश नोटिफिकेशन या यूनिवर्सल लिंक (उपयोगकर्ता पत्र में लिंक पर क्लिक करता है और संबंधित एप्लिकेशन स्क्रीन में जारी रहता है)। यहां अन्य अनिश्चितताएं उत्पन्न होती हैं जिनके लिए समन्वयक पैटर्न का सटीक उत्तर नहीं है। आपको यह जानने की आवश्यकता है कि वर्तमान में उपयोगकर्ता किस स्क्रीन पर है ताकि उसे बाहरी घटना द्वारा अनुरोध की गई अगली स्क्रीन दिखाई जा सके।
   सबसे सरल उदाहरण एक चैट एप्लिकेशन है जिसमें 3 स्क्रीन हैं - एक चैट सूची, वह चैट जो कि चैट सूची नियंत्रक के नेविगेशन में धकेल दी जाती है और सेटिंग्स स्क्रीन को सामान्य रूप से दिखाया जाता है। उपयोगकर्ता इन स्क्रीन में से एक पर हो सकता है जब वह एक धक्का अधिसूचना प्राप्त करता है और उस पर टैप करता है। और यहां अनिश्चितता शुरू होती है, यदि वह चैट सूची में है, तो आपको इस विशिष्ट उपयोगकर्ता के साथ एक चैट शुरू करने की आवश्यकता है, यदि वह पहले से ही चैट में है, तो आपको इसे स्विच करने की आवश्यकता है, और यदि वह इस उपयोगकर्ता के साथ चैट में है, तो कुछ भी न करें और अपडेट न करें, यदि उपयोगकर्ता चालू है सेटिंग्स स्क्रीन - यह, जाहिरा तौर पर आपको पिछले चरणों को बंद करने और पालन करने की आवश्यकता है। या शायद बंद न हो और सिर्फ सेटिंग्स पर चैट को मामूली रूप से दिखाएं? और अगर सेटिंग्स दूसरे टैब में हैं, और मोडल नहीं है? ये if/else समन्वयकों पर फैलने लगते हैं या स्पेगेटी के एक टुकड़े के रूप में किसी अन्य मेगा-समन्वयक के पास जाते हैं। साथ ही, यह नियंत्रकों पर या तो सक्रिय पुनरावृत्तियों को स्टैक देखता है और यह निर्धारित करने का प्रयास करता है कि उपयोगकर्ता इस समय कहां है, या किसी प्रकार का एप्लिकेशन बनाने का प्रयास है जो उसके राज्य की निगरानी करता है, लेकिन यह एक आसान काम नहीं है, बस व्यू कंट्रोलर्स की प्रकृति के आधार पर ही स्टैक होता है।
5. और केक पर चेरी UIKit glitches हैं । एक तुच्छ उदाहरण: एक UITabBarController दूसरे UIViewController साथ दूसरे टैब में एक UINavigationController साथ। पहले टैब में उपयोगकर्ता एक निश्चित घटना का कारण बनता है जिसके लिए टैब को स्विच करने और किसी अन्य दृश्य नियंत्रक को अपने UINavigationController में UINavigationController आवश्यकता होती है। यह सब सिर्फ एक ऐसे अनुक्रम में किया जाना चाहिए। यदि उपयोगकर्ता ने इससे पहले कभी दूसरा टैब नहीं खोला है और UINavigationController नहीं बुलाया गया है viewDidLoad तो push विधि काम नहीं करेगी, केवल कंसोल में एक अप्रत्यक्ष संदेश छोड़कर। अर्थात्, समन्वयक केवल इस उदाहरण में घटनाओं के श्रोता नहीं बनाए जा सकते, उन्हें एक निश्चित क्रम में काम करना चाहिए। इसलिए उन्हें एक दूसरे का ज्ञान होना चाहिए। और यह पहले से ही समन्वयक पैटर्न के पहले बयान का खंडन करता है, कि समन्वयक उत्पन्न करने वाले समन्वयकों के बारे में कुछ भी नहीं जानते हैं और केवल बच्चों के साथ जुड़े हुए हैं। और उनकी विनिमेयता को भी सीमित करता है।

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

यह ध्यान देने योग्य है कि इस पैटर्न पर आधारित पुस्तकालय हैं, जो एक तरह से या किसी अन्य के साथ, उपरोक्त नुकसानों को आंशिक रूप से कम करने की अनुमति देते हैं। मैं XCoordinator और RxFlow का उल्लेख करूंगा ।

हमने क्या किया है?

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

यह दृष्टिकोण क्या है? इसमें, स्टैक (पेड़) पर भरोसा करने के लिए मैं नियंत्रकों को मोड़ देता हूं जैसा कि यह है। अनावश्यक संस्थाओं का निर्माण न करने के लिए जिनकी निगरानी की आवश्यकता है। स्थितियों को बचाने या ट्रैक न करें।

आइए UIKit संस्थाओं को अधिक बारीकी से देखें और यह जानने की कोशिश करें कि हमारे पास नीचे की पंक्ति में क्या है और हम इसके साथ क्या काम कर सकते हैं:

1. नियंत्रक ढेर एक पेड़ है। एक रूट व्यू कंट्रोलर है जिसमें चाइल्ड व्यू कंट्रोलर्स हैं। नियमित रूप से प्रस्तुत किए गए व्यू कंट्रोलर चाइल्ड व्यू कंट्रोलर्स का एक विशेष मामला है, क्योंकि उनके पास जेनरेट किए गए व्यू कंट्रोलर के लिए बाइंडिंग भी है। यह सभी बॉक्स से बाहर उपलब्ध है।
2. मुझे नियंत्रकों की इकाइयाँ बनाने की आवश्यकता है। उन सभी के पास अलग-अलग निर्माता हैं, उन्हें Xib फ़ाइलों या स्टोरीबोर्ड का उपयोग करके बनाया जा सकता है। उनके पास अलग-अलग इनपुट पैरामीटर हैं। लेकिन वे एकजुट हैं कि उन्हें बनाने की आवश्यकता है। इसलिए, यहां हम फ़ैक्टरी पैटर्न का उपयोग कर सकते हैं, जो जानता है कि वांछित दृश्य नियंत्रक कैसे बनाया जाए। प्रत्येक कारखाने को व्यापक इकाई परीक्षणों के साथ कवर करना आसान है और यह दूसरों से स्वतंत्र है।
3. हम व्यू कंट्रोलर्स को 2 वर्गों में विभाजित करते हैं: 1. बस कंट्रोलर देखें, 2. कंटेनर व्यू कंट्रोलर (कंटेनर व्यू कंट्रोलर) । कंटेनर दृश्य नियंत्रक सामान्य लोगों से भिन्न होते हैं, जिसमें वे बाल दृश्य नियंत्रक शामिल कर सकते हैं - कंटेनर या सरल वाले भी। इस तरह के दृश्य नियंत्रक बॉक्स से बाहर उपलब्ध हैं: UINavigationController , UITabBarController और इसी तरह, लेकिन उपयोगकर्ता द्वारा भी बनाया जा सकता है। यदि हम इसे अनदेखा करते हैं, तो हम सभी कंटेनरों में निम्नलिखित गुण पा सकते हैं: 1. उनके पास उन सभी नियंत्रकों की एक सूची है जो उनके पास हैं। 2. वर्तमान में एक या अधिक नियंत्रक दिखाई दे रहे हैं। 3. उन्हें इन नियंत्रकों में से एक को दृश्यमान बनाने के लिए कहा जा सकता है। यह सब UIKit कंट्रोलर कर सकते हैं । इसके लिए उनके पास अलग-अलग तरीके हैं। लेकिन केवल 3 कार्य हैं।
4. एक फैक्ट्री-निर्मित व्यू कंट्रोलर को एम्बेड करने के लिए, कंट्रोलर की पैरेंट व्यू विधि UINavigationController.pushViewController(...) , UITabBarController.selectedViewController = ... , UIViewController.present(...) और इसी तरह की है। आप देख सकते हैं कि 2 दृश्य नियंत्रक हमेशा आवश्यक होते हैं, एक पहले से ही स्टैक पर, और एक जिसे स्टैक पर एम्बेड करने की आवश्यकता होती है। इसे एक रैपर में लपेटें और इसे एक्शन (लड़ाई) कहें। प्रत्येक क्रिया को व्यापक इकाई परीक्षणों के साथ कवर करना आसान है और प्रत्येक दूसरों से स्वतंत्र है।
5. ऊपर से, यह पता चला है कि तैयार संस्थाओं का उपयोग करके, आप कॉन्फ़िगरेशन श्रृंखला का निर्माण कर सकते हैं फैक्टरी -> कार्रवाई -> कारखाना -> कार्रवाई -> कारखाना और इसे पूरा करने के बाद, आप किसी भी जटिलता के नियंत्रकों के एक दृश्य पेड़ का निर्माण कर सकते हैं। आपको केवल प्रवेश बिंदु निर्दिष्ट करने की आवश्यकता है। ये इनपुट पॉइंट आम तौर पर या तो UIWindow या वर्तमान दृश्य नियंत्रक के स्वामित्व वाले रूट व्यू कंट्रोलर होते हैं, जो कि पेड़ की सबसे चरम शाखा है। यही है, इस तरह के कॉन्फ़िगरेशन को सही तरीके से लिखा गया है: ViewController शुरू करना -> कार्रवाई -> कारखाना -> ... -> कारखाना ।
6. कॉन्फ़िगरेशन के अलावा, आपको कुछ इकाई की आवश्यकता होगी जो प्रदान किए गए कॉन्फ़िगरेशन को शुरू करना और बनाना जानता है। हम इसे राउटर कहेंगे। इसकी कोई अवस्था नहीं है, इसमें कोई लिंक नहीं है। इसकी एक विधि है जिसके लिए कॉन्फ़िगरेशन पास किया जाता है और यह क्रमिक रूप से कॉन्फ़िगरेशन चरणों को पूरा करता है।
7. कॉन्फ़िगरेशन श्रृंखला में इंटरसेप्टर कक्षाएं जोड़कर राउटर के लिए जिम्मेदारी जोड़ें। इंटरसेप्टर 3 प्रकार के होते हैं: 1. नेविगेशन शुरू करने से पहले लॉन्च किया गया। हम सिस्टम में उपयोगकर्ता प्रमाणीकरण के कार्यों और उनमें अन्य अतुल्यकालिक कार्यों को हटा देते हैं। 2. मान सेट करने के लिए व्यू कंट्रोलर के निर्माण के समय चलाएँ। 3. नेविगेशन के बाद प्रदर्शन किया और विभिन्न विश्लेषणात्मक कार्यों का प्रदर्शन किया। प्रत्येक इकाई को आसानी से इकाई परीक्षणों द्वारा कवर किया जाता है और यह नहीं जानता कि यह कॉन्फ़िगरेशन में कैसे उपयोग किया जाएगा। उसकी एक ही जिम्मेदारी है और वह उसे पूरा करती है। यही है, जटिल नेविगेशन के लिए कॉन्फ़िगरेशन [प्री-नेविगेशन टास्क ...] -> व्यू व्यूकंट्रोलर -> एक्शन -> (फैक्ट्री + [कॉन्सेप्टटैस्क ...]) -> ... -> (फैक्ट्री + [कॉन्टेक्टटैस्क) ...] -> [पोस्ट नेविगेशनटैस्क की तरह लग सकता है। ...] । यही है, सभी कार्यों को राउटर द्वारा क्रमिक रूप से किया जाएगा, बदले में छोटे, आसानी से पठनीय, परमाणु संस्थाओं में प्रदर्शन किया जाएगा।
8. अंतिम कार्य जो कॉन्फ़िगरेशन द्वारा हल नहीं किया जा सकता है - यह इस समय एप्लिकेशन की स्थिति है। क्या होगा यदि हमें संपूर्ण कॉन्फ़िगरेशन श्रृंखला का निर्माण करने की आवश्यकता नहीं है, लेकिन इसका केवल एक हिस्सा है, क्योंकि उपयोगकर्ता ने इसे आंशिक रूप से पारित किया है? इस सवाल को हमेशा दृश्य नियंत्रकों के पेड़ द्वारा स्पष्ट रूप से उत्तर दिया जा सकता है। क्योंकि अगर श्रृंखला का हिस्सा पहले से ही बनाया गया है, तो यह पहले से ही पेड़ में है। इसका मतलब यह है कि यदि श्रृंखला का प्रत्येक कारखाना इस प्रश्न का उत्तर दे सकता है कि वह निर्मित है या नहीं, तो राउटर यह समझने में सक्षम होगा कि श्रृंखला के किस भाग को पूरा करने की आवश्यकता है। बेशक, यह कारखाने का कार्य नहीं है, इसलिए एक और परमाणु इकाई की शुरुआत की गई है - खोजक, और कोई भी कॉन्फ़िगरेशन इस तरह दिखता है: [पूर्व-नेविगेशन कार्य ...] - ViewController शुरू करना -> कार्रवाई -> (खोजक / कारखाना + / ContextTask ...) -> ... -> (खोजक / फैक्टरी + [प्रसंगवश ...]) -> [पोस्ट नेविगेशनटैस्क ...] । यदि राउटर इसे अंत से पढ़ना शुरू कर देता है, तो खोजकर्ताओं में से एक उसे बताएगा कि यह पहले से ही बनाया गया है, और इस बिंदु से राउटर वापस श्रृंखला का निर्माण करना शुरू कर देगा। यदि उनमें से कोई खुद को पेड़ में नहीं पाता है, तो आपको प्रारंभिक नियंत्रक से पूरी श्रृंखला बनाने की आवश्यकता है।
   
9. कॉन्फ़िगरेशन को दृढ़ता से टाइप किया जाना चाहिए। इसलिए, प्रत्येक इकाई केवल एक प्रकार के नियंत्रक दृश्य के साथ काम करती है; एक प्रकार का डेटा और कॉन्फ़िगरेशन पूरी तरह से संबद्धता के साथ काम करने के लिए स्विफ्ट की क्षमता पर टिकी हुई है। हम संकलक पर भरोसा करना चाहते हैं, रनटाइम पर नहीं। एक डेवलपर जानबूझकर टाइपिंग को कमजोर कर सकता है, लेकिन इसके विपरीत नहीं।

ऐसे विन्यास का एक उदाहरण:

 let productScreen = StepAssembly(finder: ProductViewControllerFinder(), factory: ProductViewControllerFactory()) .add(LoginInterceptor<UUID>()) // Have to specify the context type till https://bugs.swift.org/browse/SR-8719 is fixed .add(ProductViewControllerContextTask()) .add(ProductViewControllerPostTask(analyticsManager: AnalyticsManager.sharedInstance)) .using(UINavigationController.push()) .from(NavigationControllerStep()) .using(GeneralActions.presentModally()) .from(GeneralStep.current()) .assemble() 

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

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

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

अधिक विवरण पिछले लेखों में पाए जा सकते हैं:
UIViewControllers की संरचना और उनके बीच नेविगेशन (और न केवल) / geek पत्रिका
रूटव्यूपर / geek पत्रिका का उपयोग करके UIViewControllers के कॉन्फ़िगरेशन उदाहरण

आपका ध्यान के लिए धन्यवाद। मुझे टिप्पणियों में सवालों के जवाब देने में खुशी होगी।