एक वास्तविक "आईओएस" परियोजना में "समन्वयकों" का उपयोग करने का अनुभव

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

समस्या

अक्सर ऐसा होता है कि नियंत्रक बहुत अधिक लेना शुरू कर देते हैं: "कमांड कमांड दें" सीधे UINavigationController , "संचार" अपने "भाइयों" नियंत्रकों के साथ (यहां तक ​​कि उन्हें इनिशियलाइज़ करें और उन्हें नेविगेशन स्टैक पास करें) - सामान्य तौर पर, इसके बारे में बहुत कुछ करना है इससे भी उन्हें संदेह नहीं होना चाहिए।

इससे बचने के संभावित तरीकों में से एक "समन्वयक" ठीक है। इसके अलावा, जैसा कि यह निकला, यह काम करने के लिए काफी सुविधाजनक है और बहुत लचीला है: टेम्पलेट दोनों छोटे मॉड्यूल (प्रतिनिधित्व, शायद, केवल एक सिंगल स्क्रीन) की नेविगेशन घटनाओं का प्रबंधन करने में सक्षम है, और पूरे आवेदन (अपने स्वयं के "प्रवाह" को लॉन्च करते हुए, अपेक्षाकृत बोल, सीधे UIApplicationDelegate )।

कहानी

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

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

आगे देखते हुए, चर्चा का सबसे उल्लेखनीय विषय UINavigationController में बैक बटन की समस्या है, जिस पर क्लिक करने पर हमारे कोड द्वारा संसाधित नहीं किया जाता है, लेकिन हम केवल कॉलबैक प्राप्त कर सकते हैं।

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

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

पहला तरीका

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

जब हमने पहली बार टीम में समन्वयकों के साथ प्रयोग करना शुरू किया, तो हमारे पास इसके लिए बहुत समय और कार्रवाई की स्वतंत्रता नहीं थी: मौजूदा सिद्धांतों और नेविगेशन डिवाइस के साथ पुनर्मिलन करना आवश्यक था। समन्वयकों के लिए पहला कार्यान्वयन विकल्प एक सामान्य "राउटर" पर आधारित था, जो कि UINavigationController द्वारा स्वामित्व और संचालित है। वह जानता है कि नेविगेशन के संबंध में UIViewController सभी उदाहरणों के साथ क्या करना है - रूट नियंत्रक के साथ पुश / पॉप, वर्तमान / बर्खास्तगी और जोड़तोड़। ऐसे राउटर के इंटरफेस का एक उदाहरण:

 import UIKit protocol Router { func present(_ module: UIViewController, animated: Bool) func dismissModule(animated: Bool, completion: (() -> Void)?) func push(_ module: UIViewController, animated: Bool, completion: (() -> Void)?) func popModule(animated: Bool) func setAsRoot(_ module: UIViewController) func popToRootModule(animated: Bool) } 

एक विशिष्ट कार्यान्वयन UINavigationController एक उदाहरण के साथ शुरू किया गया है और इसमें कुछ भी विशेष रूप से मुश्किल नहीं है। केवल सीमा: आप UINavigationController अन्य उदाहरणों को इंटरफ़ेस विधियों के तर्क के रूप में पारित नहीं कर सकते हैं (स्पष्ट कारणों के लिए: UINavigationController अपने स्टैक में UINavigationController शामिल नहीं कर सकता है - यह एक UIKit प्रतिबंध है)।

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

 class Coordinator { private var childCoordinators = [Coordinator]() func add(dependency coordinator: Coordinator) { // ... } func remove(dependency coordinator: Coordinator) { // ... } } 

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

 protocol Presentable { func presented() -> UIViewController } 

फिर प्रत्येक विशिष्ट समन्वयक को Coordinator से विरासत में प्राप्त करना चाहिए और Presentable इंटरफ़ेस को लागू करना चाहिए, और राउटर इंटरफ़ेस को निम्न रूप में लेना चाहिए:

 protocol Router { func present(_ module: Presentable, animated: Bool) func dismissModule(animated: Bool, completion: (() -> Void)?) func push(_ module: Presentable, animated: Bool, completion: (() -> Void)?) func popModule(animated: Bool) func setAsRoot(_ module: Presentable) func popToRootModule(animated: Bool) } 

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

कार्रवाई में इस सब का एक संक्षिप्त उदाहरण:

 final class FirstCoordinator: Coordinator, Presentable { func presented() -> UIViewController { return UIViewController() } } final class SecondCoordinator: Coordinator, Presentable { func presented() -> UIViewController { return UIViewController() } } let nc = UINavigationController() let router = RouterImpl(navigationController: nc) // Router implementation. router.setAsRoot(FirstCoordinator()) router.push(SecondCoordinator(), animated: true, completion: nil) router.popToRootModule(animated: true) 

अगला सन्निकटन

और फिर एक दिन नेविगेशन के पूर्ण परिवर्तन और अभिव्यक्ति की पूर्ण स्वतंत्रता के लिए क्षण आया! वह क्षण जब कुछ भी हमें समन्वित start() विधि का उपयोग करके समन्वयकों पर नेविगेशन को लागू करने की कोशिश करने से नहीं रोकता था - एक ऐसा संस्करण जो मूल रूप से अपनी सादगी और संक्षिप्तता के साथ मोहित हो गया।

ऊपर वर्णित Coordinator विशेषताएं स्पष्ट रूप से शानदार नहीं होंगी। लेकिन एक ही विधि को सामान्य इंटरफ़ेस में जोड़ा जाना चाहिए:

 protocol Coordinator { func add(dependency coordinator: Coordinator) func remove(dependency coordinator: Coordinator) func start() } class BaseCoordinator: Coordinator { private var childCoordinators = [Coordinator]() func add(dependency coordinator: Coordinator) { // ... } func remove(dependency coordinator: Coordinator) { // ... } func start() { } } 

"स्विफ्ट" अमूर्त वर्गों को घोषित करने की क्षमता प्रदान नहीं करता है (क्योंकि यह एक अधिक शास्त्रीय, ऑब्जेक्ट-ओरिएंटेड की तुलना में प्रोटोकॉल-उन्मुख दृष्टिकोण के लिए अधिक उन्मुख है , इसलिए start() विधि एक खाली कार्यान्वयन या जोर के साथ छोड़ा जा सकता है fatalError(_:file:line:) (वारिस के साथ इस विधि को ओवरराइड करने के लिए मजबूर fatalError(_:file:line:) जैसी कोई चीज़ है। व्यक्तिगत रूप से, मैं पहला विकल्प पसंद करता हूं।

लेकिन स्विफ्ट में प्रोटोकॉल विधियों में डिफ़ॉल्ट कार्यान्वयन विधियों को जोड़ने का एक शानदार अवसर है, इसलिए पहला विचार, निश्चित रूप से, एक आधार वर्ग घोषित नहीं करना था, लेकिन ऐसा कुछ करना:

 extension Coordinator { func add(dependency coordinator: Coordinator) { // ... } func remove(dependency coordinator: Coordinator) { // ... } } 

लेकिन प्रोटोकॉल एक्सटेंशन संग्रहीत फ़ील्ड की घोषणा नहीं कर सकते हैं, और इन दो तरीकों का कार्यान्वयन स्पष्ट रूप से एक निजी संग्रहित प्रकार की संपत्ति पर आधारित होना चाहिए।

किसी विशेष समन्वयक का आधार इस तरह दिखेगा:

 final class SomeCoordinator: BaseCoordinator { override func start() { // ... } } 

समन्वयक के कार्य करने के लिए आवश्यक कोई भी निर्भरता इनिशियलाइज़र में जोड़ी जा सकती है। एक विशिष्ट मामले के रूप में, UINavigationController का एक उदाहरण है।

यदि यह रूट कोऑर्डिनेटर है जिसकी जिम्मेदारी रूट UIViewController को मैप करना है, तो समन्वयक, उदाहरण के लिए, खाली स्टैक के साथ UINavigationController का एक नया उदाहरण स्वीकार कर सकता है।

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

संभव इंटरफ़ेस में सुधार

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

 protocol CoordinatorDependencies { func add(dependency coordinator: Coordinator) func remove(dependency coordinator: Coordinator) } final class DefaultCoordinatorDependencies: CoordinatorDependencies { private let dependencies = [Coordinator]() func add(dependency coordinator: Coordinator) { // ... } func remove(dependency coordinator: Coordinator) { // ... } } final class SomeCoordinator: Coordinator { private let dependencies: CoordinatorDependencies init(dependenciesManager: CoordinatorDependencies = DefaultCoordinatorDependencies()) { dependencies = dependenciesManager } func start() { // ... } } 

उपयोगकर्ता-जनित घटनाओं को संभालना

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

मान लीजिए कि UIViewController का एक उपवर्ग है:

 final class SomeViewController: UIViewController { } 

और समन्वयक जो इसे स्टैक में जोड़ता है:

 final class SomeCoordinator: Coordinator { private let dependencies: CoordinatorDependencies private weak var navigationController: UINavigationController? init(navigationController: UINavigationController, dependenciesManager: CoordinatorDependencies = DefaultCoordinatorDependencies()) { self.navigationController = navigationController dependencies = dependenciesManager } func start() { let vc = SomeViewController() navigationController?.pushViewController(vc, animated: true) } } 

हम एक ही समन्वयक को संबंधित नियंत्रक घटनाओं के प्रसंस्करण को सौंपते हैं। यहाँ, वास्तव में, शास्त्रीय योजना का उपयोग किया जाता है:

 protocol SomeViewControllerRoute: class { func onSomeEvent() } final class SomeViewController: UIViewController { private weak var route: SomeViewControllerRoute? init(route: SomeViewControllerRoute) { self.route = route super.init(nibName: nil, bundle: nil) } required init?(coder aDecoder: NSCoder) { fatalError("init(coder:) has not been implemented") } @IBAction private func buttonAction() { route?.onSomeEvent() } } final class SomeCoordinator: Coordinator { private let dependencies: CoordinatorDependencies private weak var navigationController: UINavigationController? init(navigationController: UINavigationController, dependenciesManager: CoordinatorDependencies = DefaultCoordinatorDependencies()) { self.navigationController = navigationController dependencies = dependenciesManager } func start() { let vc = SomeViewController(route: self) navigationController?.pushViewController(vc, animated: true) } } extension SomeCoordinator: SomeViewControllerRoute { func onSomeEvent() { // ... } } 

रिटर्न बटन को संभालना

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

इस दृष्टिकोण में एक छोटी सी खामी है: केवल NSObject एक UINavigationController प्रतिनिधि हो सकता है।

तो, एक समन्वयक है जो दूसरे समन्वयक को जन्म देता है। यह अन्य, कॉलिंग start() UIVIVController के कुछ प्रकार को UINavigationController स्टैक में जोड़ता है। UINavigationBar पर बैक बटन पर क्लिक करके UINavigationBar आपको बस इतना करना चाहिए कि मूल समन्वयक को यह बताने दें कि उत्पन्न समन्वयक ने अपना काम ("प्रवाह") पूरा कर लिया है। ऐसा करने के लिए, हमने एक और प्रतिनिधि उपकरण पेश किया: प्रत्येक जनरेट किए गए समन्वयक को एक प्रतिनिधि आवंटित किया जाता है, जिसका इंटरफ़ेस जनरेटिंग समन्वयक द्वारा कार्यान्वित किया जाता है:

 protocol CoordinatorFlowListener: class { func onFlowFinished(coordinator: Coordinator) } final class MainCoordinator: NSObject, Coordinator { private let dependencies: CoordinatorDependencies private let navigationController: UINavigationController init(navigationController: UINavigationController, dependenciesManager: CoordinatorDependencies = DefaultCoordinatorDependencies()) { self.navigationController = navigationController dependencies = dependenciesManager super.init() } func start() { let someCoordinator = SomeCoordinator(navigationController: navigationController, flowListener: self) dependencies.add(someCoordinator) someCoordinator.start() } } extension MainCoordinator: CoordinatorFlowListener { func onFlowFinished(coordinator: Coordinator) { dependencies.remove(coordinator) // ... } } final class SomeCoordinator: NSObject, Coordinator { private weak var flowListener: CoordinatorFlowListener? private weak var navigationController: UINavigationController? init(navigationController: UINavigationController, flowListener: CoordinatorFlowListener) { self.navigationController = navigationController self.flowListener = flowListener } func start() { // ... } } extension SomeCoordinator: UINavigationControllerDelegate { func navigationController(_ navigationController: UINavigationController, didShow viewController: UIViewController, animated: Bool) { guard let fromVC = navigationController.transitionCoordinator?.viewController(forKey: .from) else { return } if navigationController.viewControllers.contains(fromVC) { return } if fromVC is SomeViewController { flowListener?.onFlowFinished(coordinator: self) } } } 

ऊपर के उदाहरण में, MainCoordinator कुछ भी नहीं करता है: यह बस एक और समन्वयक के प्रवाह को लॉन्च करता है - वास्तविक जीवन में, ज़ाहिर है, यह बेकार है। हमारे आवेदन में, MainCoordinator बाहर से डेटा प्राप्त करता है, जिसके अनुसार यह निर्धारित करता है कि आवेदन किस राज्य में है - अधिकृत, अधिकृत नहीं, आदि। - और किस स्क्रीन को दिखाना है। इसके आधार पर, यह संबंधित समन्वयक के प्रवाह को लॉन्च करता है। यदि मूल समन्वयक ने अपना काम पूरा कर लिया है, तो मुख्य समन्वयक को CoordinatorFlowListener माध्यम से इस बारे में एक संकेत मिलता CoordinatorFlowListener और एक अन्य समन्वयक के प्रवाह का शुभारंभ करता है।

निष्कर्ष

निश्चित रूप से, आदी समाधान में कई नुकसान हैं (जैसे किसी भी समस्या का समाधान)।

हां, आपको बहुत सारे प्रतिनिधिमंडल का उपयोग करना होगा, लेकिन यह सरल है और इसकी एक ही दिशा है: उत्पन्न से उत्पन्न (नियंत्रक से समन्वयक तक, उत्पन्न समन्वयक से उत्पन्न तक)।

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

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

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

इस जगह को पढ़ने के लिए धन्यवाद! मुझे आशा है कि उन्होंने अपने लिए कुछ उपयोगी सीखा। और अगर आप अचानक "मुझसे अधिक" चाहते हैं, तो यहां मेरे ट्विटर पर एक लिंक है ।