🤙🏽 ⛈️ 👩🏿‍⚖️ गलतियों का मेरा अनुभव 🙎🏼 📺 👌🏿

गलतियों का मेरा अनुभव

त्रुटि सूची

सर्वव्यापी वर्ग MCManager
स्क्रीन के बीच हमारे नेविगेशन का आविष्कार
कभी बहुत अधिक विरासत नहीं होती है
हमारे अपने उत्पादन की वास्तुकला या साइकिल बनाना जारी रखें
MVVM आत्मा MVP के साथ
नेविगेशन या राउटर और नेविगेशन की वक्रता के साथ दूसरा प्रयास
लगातार प्रबंधक

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

सर्वव्यापी वर्ग MCManager

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

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

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

चूंकि यह एक नमूना था और पहली बार में कार्यक्षमता सरल थी, मैंने फैसला किया कि एक प्रबंधक वर्ग पर्याप्त होगा। कार्यशीलता, जैसा कि मैंने पहले उल्लेख किया है, जिसमें प्रारंभ / स्टॉप विकल्पों के साथ एक वीडियो टुकड़ा रिकॉर्ड करना और इन टुकड़ों को एक पूरे वीडियो में जोड़ना शामिल है। और उसी क्षण मैं अपनी पहली गलती को नाम दे सकता हूं - MCManager वर्ग का नाम। MCManager, कार्ल! एक वर्ग का नाम अन्य डेवलपर्स को इसके उद्देश्य, इसकी क्षमताओं और इसके उपयोग के बारे में क्या कहना चाहिए? ठीक है, बिल्कुल कुछ भी नहीं! और यह परिशिष्ट में है, जिसके नाम में M और, उसकी माँ, C. अक्षर भी शामिल नहीं हैं। हालाँकि, यह मेरी मुख्य गलती नहीं है, क्योंकि वर्ग नाम के साथ वर्ग ने सब कुछ किया, शब्द से सब कुछ बिल्कुल सब कुछ है, जो महत्वपूर्ण गलती थी।

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

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

स्क्रीन के बीच हमारे नेविगेशन का आविष्कार

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

नमूने में केवल तीन स्क्रीन थे: रिकॉर्ड किए गए वीडियो की एक तालिका, एक रिकॉर्डिंग स्क्रीन और पोस्ट-प्रोसेसिंग स्क्रीन के साथ एक मेनू। नेविगेशन स्टैक में डुप्लिकेट व्यू कॉन्ट्रोलर्स शामिल नहीं हैं, इसकी परवाह नहीं करने के लिए, मैंने UINavigationController का उपयोग नहीं करने का फैसला किया। मैंने RootViewcontroller को जोड़ा, चौकस पाठकों ने पहले ही अनुमान लगाया है कि यह MCRootViewController था, जो परियोजना सेटिंग्स में मुख्य एक के रूप में सेट किया गया था। उसी समय, रूट नियंत्रक एप्लिकेशन स्क्रीन में से एक नहीं था, यह सिर्फ वांछित UIViewController प्रस्तुत करता है। जैसे कि यह पर्याप्त नहीं था, इसलिए रूट नियंत्रक भी प्रतिनिधित्व किए गए सभी नियंत्रकों का एक प्रतिनिधि था। नतीजतन, समय पर प्रत्येक क्षण में पदानुक्रम में केवल दो वीसी थे, और सभी नेविगेशन को प्रतिनिधि पैटर्न का उपयोग करके लागू किया गया था।

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

जैसा कि आप अनुमान लगा सकते हैं, अगर आपको वीडियो रिकॉर्डिंग स्क्रीन से वापस मुख्य मेनू में जाने की आवश्यकता है, तो विधि को बुलाया गया था:

- (void)cancel;

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

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

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

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

कभी बहुत अधिक विरासत नहीं है

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

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

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

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

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

हमारे अपने उत्पादन की वास्तुकला या साइकिल बनाना जारी रखें

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

स्विफ्ट के आगमन से पहले यह लंबे समय तक नहीं था, इसलिए मैंने ऑब्जेक्टिव-सी की संभावनाओं पर ध्यान दिया। मैंने भाषा की विशेषताओं का उपयोग करके डिपेंडेंसी इंजेक्शन करने का निर्णय लिया। मैं विस्तार विस्तार उपकरण से प्रेरित था, मुझे इसका नाम भी याद नहीं है।

लब्बोलुआब यह है: BaseViewController बेस क्लास में, मैंने एक BaseViewModel क्लास फ़ील्ड जोड़ा। तदनुसार, प्रत्येक स्क्रीन के लिए मैंने अपना स्वयं का नियंत्रक बनाया, जो कि बुनियादी लोगों को विरासत में मिला, और नियंत्रक के लिए एक प्रोटोकॉल जोड़ा गया जो व्यूमॉडल के साथ बातचीत कर सके। फिर जादू आया। मैंने viewModel गुणों को फिर से परिभाषित किया और वांछित प्रोटोकॉल के लिए समर्थन जोड़ा। बदले में, मैंने इस प्रोटोकॉल को लागू करने वाली एक विशेष स्क्रीन के लिए एक नया ViewModel वर्ग बनाया। परिणामस्वरूप, ViewDidLoad विधि में BaseViewController में, मैंने मॉडल के प्रोटोकॉल के प्रकार की जाँच की, BaseViewModel के सभी वंशजों की सूची की जाँच की, मुझे वह वर्ग मिला जिसकी मुझे ज़रूरत थी और जिस प्रकार के दृश्यमॉडल की मुझे आवश्यकता थी।

मूल ViewController उदाहरण

 #import <UIKit/UIKit.h> // MVC model #import "BaseMVCModel.h" @class BaseViewController; @protocol BaseViewControllerDelegate <NSObject> @required - (void)backFromNextViewController:(BaseViewController *)aNextViewController withOptions:(NSDictionary *)anOptionsDictionary; @end @interface BaseViewController : UIViewController <BaseViewControllerDelegate> @property (nonatomic, weak) BaseMVCModel *model; @property (nonatomic, assign) id<BaseViewControllerDelegate> prevViewController; - (void)backWithOptions:(NSDictionary *)anOptionsDictionary; + (void)setupUIStyle; @end import "BaseViewController.h" // Helpers #import "RuntimeHelper.h" @interface BaseViewController () @end @implementation BaseViewController + (void)setupUIStyle { } #pragma mark - #pragma mark Life cycle - (void)viewDidLoad { [super viewDidLoad]; self.model = [BaseMVCModel getModel:FindPropertyProtocol(@"model", [self class])]; } #pragma mark - #pragma mark Navigation - (void)backWithOptions:(NSDictionary *)anOptionsDictionary { if (self.prevViewController) { [self.prevViewController performSelector:@selector(backFromNextViewController:withOptions:) withObject:self withObject:anOptionsDictionary]; } } #pragma mark - #pragma mark Seque - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { if ([segue.destinationViewController isKindOfClass:[BaseViewController class]] { ((BaseViewController *)segue.destinationViewController).prevViewController = self; } } #pragma mark - #pragma mark BaseViewControllerDelegate - (void)backFromNextViewController:(BaseViewController *)aNextViewController withOptions:(NSDictionary *)anOptionsDictionary { [self doesNotRecognizeSelector:_cmd]; } @end

मूल ViewModel उदाहरण

 #import <Foundation/Foundation.h> @interface BaseMVCModel : NSObject @property (nonatomic, assign) id delegate; + (id)getModel:(NSString *)someProtocol; @end #import "BaseMVCModel.h" // IoC #import "IoCContainer.h" @implementation BaseMVCModel + (id)getModel:(NSString *)someProtocol { return [[IoCContainer sharedIoCContainer] getModel:NSProtocolFromString(someProtocol)]; } @end

सहायक वर्ग

 #import <Foundation/Foundation.h> @interface IoCContainer : NSObject + (instancetype)sharedIoCContainer; - (id)getModel:(Protocol *)someProtocol; @end #import "IoCContainer.h" // Helpers #import "RuntimeHelper.h" // Models #import "BaseMVCModel.h" @interface IoCContainer () @property (nonatomic, strong) NSMutableSet *models; @end @implementation IoCContainer #pragma mark - #pragma mark Singleton + (instancetype)sharedIoCContainer { static IoCContainer *_sharedIoCContainer = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ _sharedIoCContainer = [IoCContainer new]; }); return _sharedIoCContainer; } - (id)getModel:(Protocol *)someProtocol { if (!someProtocol) { return [BaseMVCModel new]; } NSArray *modelClasses = ClassGetSubclasses([BaseMVCModel class]); __block Class currentClass = NULL; [modelClasses enumerateObjectsUsingBlock:^(Class class, NSUInteger idx, BOOL *stop) { if ([class conformsToProtocol:someProtocol]) { currentClass = class; } }]; if (currentClass == nil) { return [BaseMVCModel new]; } __block BaseMVCModel *currentModel = nil; [self.models enumerateObjectsUsingBlock:^(id model, BOOL *stop) { if ([model isKindOfClass:currentClass]) { currentModel = model; } }]; if (!currentModel) { currentModel = [currentClass new]; [self.models addObject:currentModel]; } return currentModel; } - (NSMutableSet *)models { if (!_models) { _models = [NSMutableSet set]; } return _models; } @end #import <Foundation/Foundation.h> NSString * FindPropertyProtocol(NSString *propertyName, Class class); NSArray * ClassGetSubclasses(Class parentClass); #import "RuntimeHelper.h" #import <objc/runtime.h> #pragma mark - #pragma mark Functions NSString * FindPropertyProtocol(NSString *aPropertyName, Class class) { unsigned int propertyCount; objc_property_t *properties = class_copyPropertyList(class, &propertyCount); for (unsigned int i = 0; i < propertyCount; i++) { objc_property_t property = properties[i]; const char *propertyName = property_getName(property); if ([@(propertyName) isEqualToString:aPropertyName]) { const char *attrs = property_getAttributes(property); NSString* propertyAttributes = @(attrs); NSScanner *scanner = [NSScanner scannerWithString: propertyAttributes]; [scanner scanUpToString:@"<" intoString:NULL]; [scanner scanString:@"<" intoString:NULL]; NSString* protocolName = nil; [scanner scanUpToString:@">" intoString: &protocolName]; return protocolName; } } return nil; } NSArray * ClassGetSubclasses(Class parentClass) { int numClasses = objc_getClassList(NULL, 0); Class *classes = NULL; classes = (Class *)malloc(sizeof(Class) * numClasses); numClasses = objc_getClassList(classes, numClasses); NSMutableArray *result = [NSMutableArray array]; for (NSInteger i = 0; i < numClasses; i++) { Class superClass = classes[i]; do { superClass = class_getSuperclass(superClass); } while(superClass && superClass != parentClass); if (superClass == nil) { continue; } [result addObject:classes[i]]; } free(classes); return result; }

लॉगिन स्क्रीन उदाहरण

 #import "BaseViewController.h" @protocol LoginProtocol <NSObject> @required - (void)login:(NSString *)aLoginString password:(NSString *)aPasswordString completionBlock:(DefaultCompletionBlock)aCompletionBlock; @end @interface LoginVC : BaseViewController @end #import "LoginVC.h" #import "UIViewController+Alert.h" #import "UIViewController+HUD.h" @interface LoginVC () @property id<LoginProtocol> model; @property (weak, nonatomic) IBOutlet UITextField *emailTF; @property (weak, nonatomic) IBOutlet UITextField *passTF; @end @implementation LoginVC @synthesize model = _model; #pragma mark - #pragma mark IBActions - (IBAction)loginAction:(id)sender { [self login]; } #pragma mark - #pragma mark UITextFieldDelegate - (BOOL)textFieldShouldReturn:(UITextField *)textField { if (textField == self.emailTF) { [self.passTF becomeFirstResponder]; } else { [self login]; } return YES; } #pragma mark - #pragma mark Login - (void)login { NSString *email = self.emailTF.text; NSString *pass = self.passTF.text; if (email.length == 0 || pass.length == 0) { [self showAlertOkWithMessage:@"Please, input info!"]; return; } __weak __typeof(self)weakSelf = self; [self showHUD]; [self.model login:self.emailTF.text password:self.passTF.text completionBlock:^(BOOL isDone, NSError *anError) { [weakSelf hideHUD]; if (isDone) { [weakSelf backWithOptions:nil]; } }]; } @end

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

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

MVVM आत्मा MVP के साथ

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

मैंने तुरंत आर्किटेक्चर के सार और ViewModel और View (ViewController) के बीच संबंध को नहीं समझा, लेकिन जैसा मैंने समझा था वैसा करना शुरू कर दिया। आंखें डरती हैं, और हाथ जमकर कोड टाइप कर रहे हैं।

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

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

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

 import UIKit class RootViewController: UIViewController { var viewModel: RootViewModel? override func viewDidLoad() { super.viewDidLoad() let router = (UIApplication.shared.delegate as? AppDelegate)!.router viewModel = RootViewModel(with: self, router: router) viewModel?.setup() } } import UIKit protocol ViewModelProtocol: class { func setup() func backAction() } class RootViewModel: NSObject, ViewModelProtocol { unowned var router : RootRouter unowned var view: RootViewController init(with view: RootViewController, router: RootRouter) { self.view = view self.router = router } // MARK: - ViewModelProtocol func setup() { if AccountManager.shared.isLoggedIn() { router.route(to: RootRoutes.launch.rawValue, from: view, parameters: nil) } else { router.route(to: RootRoutes.loginregistartion.rawValue, from: view, parameters: nil) } } func backAction() { } }

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

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

नेविगेशन या राउटर और नेविगेशन की वक्रता के साथ दूसरा प्रयास

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

एमवीवीएम के बारे में पढ़ना, मुझे राउटर जैसे पैटर्न में दिलचस्पी थी। फिर से विवरण की समीक्षा करने के बाद, मैंने अपनी परियोजना में समाधान को लागू करना शुरू कर दिया।

राउटर उदाहरण

 import UIKit protocol Router: class { func route(to routeID: String, from view: UIViewController, parameters: Any?) func back(from view: UIViewController, parameters: Any?) } extension Router { func back(from view: UIViewController, parameters: Any?) { let navigationController: UINavigationController = checkNavigationController(for: view) navigationController.popViewController(animated: false) } } enum RootRoutes: String { case launch = "Launch" case loginregistartion = "LoginRegistartionRout" case mainmenu = "MainMenu" } class RootRouter: Router { var loginRegistartionRouter: LoginRegistartionRouter? var mainMenuRouter: MainMenuRouter? // MARK: Router func route(to routeID: String, from view: UIViewController, parameters: Any?) { var rootView = view if view is EPLaunchViewController { rootView = (view.navigationController?.viewControllers.first)! view.navigationController?.popViewController(animated: false) } if routeID == RootRoutes.loginregistartion.rawValue { loginRegistartionRouter = LoginRegistartionRouter(with: self) loginRegistartionRouter?.route(to: LRRouteID.phoneNumber.rawValue, from: rootView, parameters: nil) } else if routeID == RootRoutes.mainmenu.rawValue { if mainMenuRouter == nil { mainMenuRouter = MainMenuRouter(with: self) } mainMenuRouter?.route(to: MMRouteID.start.rawValue, from: rootView, parameters: nil) } else if routeID == RootRoutes.launch.rawValue { let storyboard = UIStoryboard(name: "RootStoryboard", bundle: nil) let launchView = storyboard.instantiateViewController(withIdentifier: "LaunchViewController") as! LaunchViewController let navigationController: UINavigationController = checkNavigationController(for: view) launchView.viewModel = LaunchViewModel(with: launchView, router: self) navigationController.pushViewController(launchView, animated: false) } } }

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

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

लगातार प्रबंधक

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

समस्या का सार यह है, आवेदन में ऐसी सेवाएं हैं जो लगातार लटकाए जाने चाहिए और एक ही समय में कई स्थानों पर उपलब्ध होनी चाहिए।

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

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

लेकिन यहां वह क्षण आता है कि मेरे आवेदन में एक से अधिक ऐसी सेवा जमा हो गई है। मैं इस परियोजना में 100500 एकल भी नहीं बनाना चाहता।

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

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

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

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

परिणाम

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

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

गलतियों का मेरा अनुभव