ICD मोबाइल बैंकिंग: विकास इतिहास

ओलेग इवानोव, दूरस्थ सेवा चैनल, आईटी विकास विभाग, सूचना प्रौद्योगिकी निदेशालय, मास्को क्रेडिट बैंक (ICD) की क्षमता के लिए केंद्र के प्रमुख

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

आगे आईओएस के लिए विकास पर जोर होगा। शुरू करने से पहले, आइए तय करें कि मोबाइल बैंक क्या है।

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

मोबाइल बैंक के मुख्य बैंकिंग परिचालन:

• बैंक उत्पादों (खातों, कार्ड, जमा, ऋण, सेवा पैकेज, आदि) का उपयोग
• खाता संतुलन देखें
• उद्धरण
• मोबाइल सेवाओं के बिलों का भुगतान
• आवास सेवाओं का भुगतान
• कार्ड से कार्ड में फंड ट्रांसफर करें
• नियमित भुगतान
• ऋणों का पुनर्भुगतान
• जमा करने के लिए धन का हस्तांतरण
• भुगतान कार्ड लॉक
• और अन्य।

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

स्रोत - MKBMobile 1.0

मोबाइल बैंक एप्लिकेशन परियोजना को हमारी टीम को तीसरे पक्ष की कंपनी से स्थानांतरित कर दिया गया था, यह उद्देश्य सी में लिखा गया था।

उपयोगकर्ता की आंखों के माध्यम से इस परियोजना को कैसे देखा जाता है:





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

कहाँ से शुरू करें? जब हम iOS के लिए विकसित होने के बारे में सोचते हैं, तो सबसे पहली चीज जो हमें चाहिए:

1. iMac की जरूरत है

Apple अपने उत्पादों की उच्च कीमत के लिए प्रसिद्ध है। लेकिन बचत इसके लायक नहीं है - यह आपके विकास की गति है!

एक अनुमानित, इष्टतम विन्यास जो हमें सूट करता है:

• 3.8 गीगाहर्ट्ज़ क्लॉक स्पीड (टर्बो बूस्ट 4.2 गीगाहर्ट्ज़ तक) के साथ सातवीं पीढ़ी का इंटेल कोर आई 5 प्रोसेसर
• 32 जीबी डीडीआर 4 2400 मेगाहर्ट्ज
• 2 टीबी फ्यूजन ड्राइव
• 8GB VRAM के साथ Radeon Pro 580 GPU है

ऐसी मशीन की अनुमानित लागत 190,000 रूबल है।

एक राय है - प्रोग्रामर के लिए iMac Pro की आवश्यकता है। यह ऐसा है :) लेकिन उनके लिए मूल्य काटता है, और यदि आपकी कंपनी उन्हें खरीदने के लिए तैयार है, तो इससे आपके विकास की गति बढ़ेगी, और निश्चित रूप से, आपके कार्यालय के सौंदर्य स्तर में वृद्धि होगी।

2. iOS उपकरणों की आवश्यकता है

"कितना और कौन सा?" - पहला सवाल उठता है। यह सब आपके आवेदन पर निर्भर करता है।
यदि आपका एप्लिकेशन केवल iPhone का समर्थन करता है, तो कम से कम 2 अलग-अलग आकार छोटे होते हैं (जैसे कि iPhone SE) और बड़े (जैसे - iPhone iPhone Plus)।

यदि आपका एप्लिकेशन भी iPad का समर्थन करता है, तो आपको एक iPad की आवश्यकता है।

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

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

यदि आप अपना स्वयं का डिवाइस फ़ार्म नहीं चाहते हैं, तो आप इस सेवा की पेशकश करने वाली कंपनियों के पक्ष में देख सकते हैं: AWS डिवाइस फ़ार्म, ज़मारिन टेस्ट क्लाउड, आदि।

जैसा कि पहले ही उल्लेख किया गया है, हमारे आवेदन iPhone और iPad दोनों के लिए समर्थित है। लेखन के समय, हमारा अपना (!) फार्म ओएस के विभिन्न प्रकारों और संस्करणों के लगभग 30 उपकरण हैं।

3. आपको आईओएस (देशी या वैकल्पिक) के लिए विकास के दृष्टिकोण पर निर्णय लेने की आवश्यकता है।

हमने iOS के लिए निम्नलिखित वैकल्पिक विकास विकल्पों की कोशिश की:

फोनगैप / कोर्डोवा

PhoneGap मूल रूप से Nitobi द्वारा बनाया गया था। 2011 में, Adobe ने Nitobi और PhoneGap ब्रांड का अधिग्रहण किया। Adobe तब PhoneGap के एक संस्करण को स्थानांतरित करता है, इसे Cordache कहते हुए, Apache Foundation को, PhoneGap ब्रांड और उत्पाद को छोड़कर। नतीजतन, कॉर्डोवा को फोनगैप के हुड के तहत एक इंजन के रूप में देखा जा सकता है (साथ ही कुछ अन्य हाइब्रिड फ्रेमवर्क)। फोनगैप, बदले में, कॉर्डोवा की क्षमताओं के लिए अपनी अतिरिक्त सुविधाएँ जोड़ता है।

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

काश, PhoneGap WebView (जो iOS पर बहुत धीमा है) का उपयोग करता है, इसलिए इस ढांचे के आधार पर निर्मित अनुप्रयोगों की गति के साथ चीजें हमेशा शानदार नहीं होती हैं।

Xamarin

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

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

लेकिन इस तरह के दृष्टिकोण तथाकथित "हाइब्रिड" अनुप्रयोग देते हैं।

वैकल्पिक विकल्पों के प्लस:

• क्रॉस-प्लेटफ़ॉर्म (एक आवेदन किया, यह किसी भी ओएस के लिए निर्यात किया जा सकता है);
• विकास का समय देशी से कम है।

विकल्पों की विपक्ष:

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

और हमने अपनी परियोजना के "मूल" विकास को जारी रखने का फैसला किया।

Apple का मूल तरीका

4. सबसे पहले, हमें कोड विकसित करने और लिखने के लिए एक उपकरण की आवश्यकता है - हमें एक IDE Xcode की आवश्यकता है

Xcode macOS, iOS, watchOS, और Apple द्वारा विकसित TVOS प्लेटफार्मों के लिए एक एकीकृत सॉफ्टवेयर डेवलपमेंट एनवायरनमेंट (IDE) है। पहला संस्करण 2001 में लॉन्च किया गया था। स्थिर संस्करण मैक ऐप स्टोर के माध्यम से नि: शुल्क वितरित किए जाते हैं। पंजीकृत डेवलपर्स के पास Apple डेवलपर वेबसाइट के माध्यम से बीटा बिल्ड तक भी पहुंच है।

इस तरह से Xcode में सिंगल व्यू ऐप जैसे साधारण एप्लिकेशन पर यह बनाना और काम करना कैसा दिखता है:





Xcode के बारे में कुछ रोचक बाते:

UI (उपयोगकर्ता इंटरफ़ेस) - स्टोरीबोर्ड बनाने के लिए Xcode एक बहुत ही सुविधाजनक टूलकिट प्रदान करता है।





लेकिन iOS के लिए अधिकांश प्रोजेक्ट्स (एप्लिकेशन) एक डेवलपर द्वारा नहीं, बल्कि कई (डेवलपमेंट टीम) द्वारा दिए जाते हैं, और वितरित एप्लिकेशन कंट्रोल सिस्टम (SVN, Mercurial, GIT, आदि) का उपयोग करते समय सभी एप्लिकेशन स्क्रीन के लिए एक स्टोरीबोर्ड का उपयोग करते हुए, घटनाक्रम का विलय हो जाता है। असली नरक।

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

Segue का उपयोग करते समय स्टोरीबोर्ड में लोड को कम करने के लिए, आप 'Refactor to स्टोरीबोर्ड' फ़ंक्शन का उपयोग कर सकते हैं। स्टोरीबोर्ड का यह पुन: संयोजन पैरेंट स्टोरीबोर्ड में एक लिंक बनाता है, जो एक नए, अलग स्टोरीबोर्ड की ओर जाता है, जहां वांछित ViewController कार्यान्वित किया जाता है।

इसके अलावा ध्यान देने योग्य Xcode - ब्रेकपॉइंट से डिबगिंग टूल है।
ब्रेकपॉइंट एक डिबगिंग टूल है जो आपको एक निश्चित बिंदु तक प्रोग्राम निष्पादन को रोकने की अनुमति देता है। यह प्रोग्राम कोड की जांच करने की अनुमति देगा (इस समय चर के मूल्यों का पता लगाएं, कुछ गणनाएं, आदि करें) यह पता लगाने के लिए कि त्रुटियां कहां हैं।



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



हम अतिरिक्त अभिव्यक्ति (गुण और यहां तक ​​कि गणना!) जोड़ सकते हैं।

5. आपको प्रोग्रामिंग भाषा ऑब्जेक्टिव-सी या नई स्विफ्ट पर निर्णय लेने की आवश्यकता है

हमें जो प्रोजेक्ट मिला वह ऑब्जेक्टिव-सी में लिखा गया था, लेकिन नई स्विफ्ट प्रोग्रामिंग भाषा पहले से ही क्षितिज पर थी।

ये प्रोग्रामिंग लैंग्वेज क्या हैं?

ऑब्जेक्टिव-सी एक संकलित, ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग लैंग्वेज है जिसका उपयोग Apple द्वारा किया गया है, जो C लैंग्वेज और स्मॉलटॉक प्रतिमान के आधार पर बनाया गया है। विशेष रूप से, ऑब्जेक्ट मॉडल स्मॉलटॉक शैली में बनाया गया है - अर्थात, ऑब्जेक्ट्स को संदेश भेजे जाते हैं।

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

यह सब स्विफ्ट प्रोग्रामिंग भाषा के निर्माण के लिए आवश्यक शर्तें बन गया।

Apple ने 2010 में स्विफ्ट का विकास शुरू किया। 2 जून 2014 को, इस भाषा का आधिकारिक तौर पर Apple वर्ल्डवाइड डेवलपर कॉन्फ्रेंस (WWDC) में अनावरण किया गया था। इसका उपयोग करने के लिए एक मुफ्त 500-पृष्ठ गाइड iBook स्टोर पर उपलब्ध था।

स्विफ्ट 1.0 को iOS के लिए Xcode 6.0 के गोल्ड मास्टर संस्करण के साथ 9 सितंबर 2014 को जारी किया गया था।
8 जून 2015 को, Apple ने बेहतर प्रदर्शन के साथ Swift 2.0 का एक नया संस्करण और एपीआई को संभालने में एक नई त्रुटि जारी की। भाषा सिंटैक्स में सुधार हुआ है, लक्ष्य ओएस के लिए स्विफ्ट फ़ंक्शन की उपलब्धता की जांच करने के लिए एक फ़ंक्शन दिखाई दिया है।

3 दिसंबर, 2015 को, स्विफ्ट 3.0 का एक बीटा संस्करण ओएस एक्स, आईओएस और लिनक्स के लिए समर्थन के साथ जारी किया गया था, जो ओपन सोर्स अपाचे 2.0 लाइसेंस के तहत लाइसेंस प्राप्त था।

19 सितंबर 2017 को, स्विफ्ट 4.0 जारी किया गया था।

सितंबर 2018 में, आईओएस 12 के नए संस्करण के साथ, स्विफ्ट 4.2 भाषा का एक नया स्थिर संस्करण जारी किया गया था, और स्विफ्ट 5.0 का एक बीटा संस्करण दिखाई दिया। संस्करण 5.0 ने अंततः मानक पुस्तकालयों (स्विफ्ट डायनामिक लाइब्रेरी) के साथ एबीआई के स्थिर संचालन की घोषणा की, नियमित अभिव्यक्ति के लिए समर्थन और एसिंक्स / वेट प्रोसेसिंग मोड के साथ समानांतर डेटा प्रोसेसिंग के लिए एक प्रथम श्रेणी समाधान।

पूर्वगामी के आधार पर, हमने नए रूपों में केवल स्विफ्ट का उपयोग करने का फैसला किया, पुराने रूपों का समर्थन करने के लिए, धीरे-धीरे उन्हें फिर से लिखना।

6. इसके बाद, आपको परियोजना की वास्तुकला को समझने की आवश्यकता है - हमने Apple से MVC वास्तुकला छोड़ने का फैसला किया

मॉडल-व्यू-कंट्रोलर (एमवीसी) किसी एप्लिकेशन में तीन भूमिकाओं में से एक को असाइन करता है: मॉडल, व्यू या कंट्रोलर। आर्किटेक्चर न केवल उन भूमिकाओं को परिभाषित करता है जो ऑब्जेक्ट अनुप्रयोग में निभाते हैं, बल्कि वस्तुओं को एक दूसरे के साथ बातचीत करने के तरीके से भी। तीन प्रकार की वस्तुओं में से प्रत्येक को अन्य सीमाओं से अलग किया जाता है और इन सीमाओं (https://developer.apple.com/library/archive/documentation/General/Conceptual -DevPedia-CocoaCore/MVC.html) के माध्यम से अन्य प्रकार की वस्तुओं के साथ सहभागिता करता है।



लेकिन, इस दृष्टिकोण को लागू करते हुए, हमें निम्नलिखित समस्याओं का सामना करना पड़ा, जिन्हें हम MKBM मोबाइल 3.0 में केवल नए आर्किटेक्चर पर स्विच करके हल करने में सक्षम थे:

• MVC स्पष्ट निर्देश प्रदान नहीं करता है कि आपको किन संस्थाओं और वर्गों को बनाने की आवश्यकता है और कौन सी नहीं। मॉडल की संरचना और वास्तुकला, साथ ही नियंत्रक के साथ इसकी बातचीत, पूरी तरह से डेवलपर (नों) के विवेक और कल्पना पर बनी हुई है।
• डोमेन क्षेत्र की खराब समझ। यानी जब कोई डेवलपर नई कार्यक्षमता जोड़ता है, तो नई इकाइयां बनाने और मौजूदा वास्तुकला को फिर से सक्रिय करने के बजाय, व्यूकार्रोलर में नई कार्यक्षमता जोड़ी जाती है। जिससे निम्नलिखित समस्या उत्पन्न हुई: मैसिव व्यू कंट्रोलर - व्यूकंट्रोलर के अंदर बहुत से कोड।

7. और सबसे प्यारी चीज है iOS SDK (https://developer.apple.com/documentation/)

IOS SDK बड़ी संख्या में चौखटे प्रदान करता है।

हमने बैंकिंग एप्लिकेशन में विशेष उत्साह के साथ फ्रेमवर्क की निम्न सूची का उपयोग किया है:

• पुश नोटिफिकेशन के साथ काम करने के लिए PushKit और UserNotifications;
• Apple वेतन के साथ काम करने के लिए PassKit;
• वीओआईपी सेवाओं के साथ काम करने के लिए CallKit (WebRTC के साथ संयोजन के रूप में);
• ऑडियो संसाधनों के साथ काम करने के लिए AVFoundation;
• उपयोगकर्ता संपर्कों तक पहुंच प्राप्त करने के लिए संपर्क;
• क्रिप्टोग्राफिक कार्यों के साथ काम करने के लिए कॉमन क्रिप्टोकरंसी।

इसलिए, हमने आवश्यक निर्णय लिया है, हम पर आरोप लगाए गए हैं और उपलब्धियों के लिए तैयार हैं ...

कुछ समय के लिए, नई सुविधाओं (कार्यक्षमता - नए स्थानान्तरण, भुगतान, बैंक उत्पाद (कार्ड, ऋण, आदि) को अच्छी तरह से आवेदन में बनाया गया था।

लेकिन फिर आवेदन बोझिल और असुविधाजनक हो गया ।

तो MKBMobile 2.0 परियोजना एक साहसिक इंटरफ़ेस विचार के साथ दिखाई दी - ट्रेलो पेज।

ट्रेलो पेज दृष्टिकोण, वास्तव में, हमारे संस्करण में स्क्रीन के शीर्ष पर, हमारे संस्करण में शीर्ष नेविगेशन बार से जुड़ा हुआ है। दृष्टिकोण आपको बोर्डों (पृष्ठों) के बीच त्वरित नेविगेशन करने की अनुमति देता है।




इस दृष्टिकोण के लाभ:

• स्केलेबिलिटी, अनंत स्थान बाएं / दाएं और नीचे;
• पृथक्करण, प्रत्येक प्रकार की कार्यक्षमता को एक अलग पृष्ठ पर रखा गया था;
• IPad और iPhone दोनों के लिए बिल्कुल सही।

लेकिन इस विचार के कुछ नुकसान भी थे:

• शीर्ष नेविगेशन मेनू आइटम मुश्किल पहुंच में थे;
• इनकमिंग पुश नोटिफिकेशन और एसएमएस नोटिफिकेशन ने टॉप नेविगेशन मेनू के साथ काम करने में अतिरिक्त मुश्किलें पैदा कीं;
• इस दृष्टिकोण ने Apple के मानव इंटरफ़ेस दिशानिर्देशों का पालन नहीं किया।

तो ICD मोबाइल बैंक, MKBMobile 3.0 का वर्तमान संस्करण पैदा हुआ था।

इस संस्करण में, हमने Apple HIG (मानव इंटरफ़ेस दिशानिर्देश) कम टैबबार से क्लासिक नेविगेशन मॉडल को अपनाया है।





इस संस्करण में आगे बढ़ते हुए, हमने Apple के क्लासिक MVC आर्किटेक्चर का उपयोग करते हुए बहुत सारे नकारात्मक अनुभव प्राप्त किए हैं।

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

इन सभी आवश्यकताओं के परिणामस्वरूप एक नया वास्तुशिल्प दृष्टिकोण - VIPER का उपयोग किया गया।
क्लासिक VIPER मॉडल:



लेकिन, आईओएस के लिए VIPER को लागू करने में कई दृष्टिकोणों पर ध्यान देने के बाद, हम अपनी पचड़ों के साथ Rambler & Co समाधान पर आ गए।

एक आधार के रूप में हमने रामबलर एंड कंपनी की एक पुस्तक रखी।



VIPER ने जिन मुख्य कार्यों को हल करने में हमारी मदद की:

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

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

हमारी परियोजना क्या दिखना शुरू हुई:



हमारे कार्यान्वयन में VIPER मॉड्यूल की संरचना:

1. सबसे "मुख्य" एक मॉड्यूल वर्ग है, यह हर किसी के बारे में सब कुछ जानता है, सहभागिता के लिए आवश्यक सेवाओं की वस्तुओं को बनाता है, एक दूसरे के सभी हिस्सों को व्यू, राउटर, प्रस्तुतकर्ता, आदि से जोड़ना जानता है।



यह इनपुट और आउटपुट प्रोटोकॉल ModuleInput और ModuleOutput के माध्यम से अन्य VIPER-मॉड्यूल के साथ संचार भी प्रदान करता है।

इसी तरह के इनपुट और आउटपुट प्रोटोकॉल में VIPER- मॉड्यूल (व्यू, राउटर, प्रस्तुतकर्ता, आदि) के सभी भाग हैं।

हम सहमत हुए: यदि VIPER मॉड्यूल के प्रोटोकॉल या भागों की कोई आवश्यकता नहीं है, तो हम उनका उपयोग नहीं करते हैं और उनके लिए खाली कक्षाएं आरक्षित नहीं करते हैं।

2. इंटरेक्टर्स (इंटरेक्टर) - व्यावसायिक तर्क को छिपाते हैं।

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

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

4. राउटर - मॉड्यूल के बीच नेविगेशन के लिए जिम्मेदार है।

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

हमारे मॉड्यूल समग्र हो सकते हैं।

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

ये सभी भाग स्वतंत्र हैं और अपना स्वयं का जीवन जी सकते हैं - बैंक सर्वर के साथ उनका अपना एपीआई है, उनके पास स्वतंत्र डेटा मॉडल हैं। मुख्य पृष्ठ पर उन्हें प्रदर्शित करने के लिए, कंटेनर (पेरेंट व्यू) तैयार किए जाते हैं, जहाँ ये विजेट (देखें) डाले जाते हैं।





IOS के लिए हमारा मोबाइल एप्लिकेशन लगातार बढ़ रहा है और विकसित हो रहा है। इसका उपयोग हमारे अधिक से अधिक ग्राहकों द्वारा किया जाता है।




निम्नलिखित उपकरण क्या हैं जिन्हें हम शुरू करने की योजना बना रहे हैं:

• स्विफ्टलिफ्ट, स्विफ्ट कोड के स्वचालित सत्यापन के लिए दायरे डेवलपर्स से एक उपयोगिता;
• फास्टलेन पर आधारित पूर्ण सीआई;
• Xcode से उपकरणों का पूर्ण उपयोग (आवंटन, लीक्स, लाश, आदि)

हमारे लेख का पालन करें! आपको देखें और आपका ध्यान के लिए धन्यवाद!