यदि आप एक मोबाइल ऐप डेवलपर हैं, तो शायद आपने लेआउट और तर्क परिवर्तन करने के लिए ऑनलाइन विकास के लचीलेपन का सपना देखा है और सेकंड में परिकल्पना परीक्षण चलाने की क्षमता और परिणाम को और भी तेज़ी से संसाधित किया है?

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

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

बैकएंड संचालित विकास क्या है?

बैकएंड-ड्रिवेन डेवलपमेंट (या बैकएंड-ड्रिवेन डेवलपमेंट, या बैकएंड-ड्रिवेन यूआई, या सर्वर-ड्रिवेन यूआई) सर्वर प्रतिक्रियाओं के आधार पर फ्रंट-एंड एप्लिकेशन विकसित करने की अवधारणा है। सर्वर की प्रतिक्रियाओं के आधार पर स्क्रीन और प्रवाह बदलते हैं।

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

स्क्रीन को लागू करने के पारंपरिक दृष्टिकोण में कुछ कमियां हैं, क्योंकि आवेदन पक्ष में बहुत सारे व्यावसायिक तर्क हो सकते हैं, और कोड को बनाए रखना अधिक कठिन हो जाता है:

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

इन समस्याओं को हल करने के लिए बैकएंड-ओरिएंटेड डेवलपमेंट आ गया है।

निम्नलिखित परिदृश्य पर विचार करें (जो नमूना आईओएस ऐप पर आधारित है लेकिन आसानी से किसी अन्य फ्रंट-एंड प्रोजेक्ट में अनुवादित किया जा सकता है):

Scenario for backend driven development

 {
    "पेजटाइटल" : "डिमॉन्स्ट्रेटिव टाइटल" ,
    "बक्से" : [
        {
            "टाइप ": "बिगब्लू" ,
            "शीर्षक" : "अच्छा बॉक्स" ,
            "उपशीर्षक" : "बॉक्स का उपशीर्षक"
        } ,
        {
            "टाइप ": "स्मॉलरेड" ,
            "शीर्षक" : "महान बॉक्स"
        } ,
        {
            "टाइप ": "आयताकार हरा" ,
            "शीर्षक" : "अतुल्य बॉक्स" ,
            "उपशीर्षक" : "बॉक्स का उपशीर्षक" ,
            "संख्या" : 10
        }
    ]
}

फ़ील्ड प्रदर्शित करने और टेक्स्ट और दृश्य जानकारी प्रदर्शित करने के लिए सभी व्यावसायिक तर्क सर्वर-साइड पर समेकित और सारगर्भित हैं, जिससे इस एपीआई को संसाधित करने के लिए एकाधिक इंटरफेस की आवश्यकता समाप्त हो जाती है। सर्वर तब व्यावसायिक तर्क लागू करता है और JSON प्रारूप में API प्रतिक्रिया उत्पन्न करने के लिए इसके परिणामों का उपयोग करता है।

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

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

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

Making changes to the interface in backend driven development

 {
    "पेजटाइटल" : "डिमॉन्स्ट्रेटिव टाइटल" ,
    "बक्से" : [
        {
            "टाइप ": "आयताकार हरा" ,
            "शीर्षक" : "एक और शीर्षक" ,
            "उपशीर्षक" : "एक और उपशीर्षक" ,
            "संख्या" : 100
        } ,
        {
            "टाइप ": "स्मॉलरेड" ,
            "शीर्षक" : "अलग शीर्षक"
        }
        {
            "टाइप ": "बिगब्लू" ,
            "शीर्षक" : "बैकएंड संचालित" ,
            "उपशीर्षक" : "विकास"
        }
    ]
}

दो बार सोचो

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

अनुभव और शोध के आधार पर, हम मध्यम लचीलेपन को इष्टतम मानते हैं।

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

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

एक सुपर ऐप निर्माण, मोबाइल टेक केस

आप शायद सुपर ऐप कॉन्सेप्ट से परिचित हैं और वीचैट जैसे ऐप के बारे में सुना होगा। WeChat चीन में विकसित एक मोबाइल मैसेजिंग प्लेटफॉर्म और सोशल नेटवर्क है और दुनिया भर में बेहद लोकप्रिय हो गया है।

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

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

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

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

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

Widgets that the MovilePay application

Widgets in MovilePay application

Widgets in MovilePay application

Widgets in MovilePay application

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

Parsing and creating a home screen

 [
    {
        "शीर्षक" : "सेक्शन 1" ,
        "विजेट" : [
            {
                "पहचानकर्ता" : "COLLECTION_WIDGET" ,
                "सामग्री" : [
                    {
                        "शीर्षक" : "शीर्षक ए" ,
                        "छवि" : "ए" ,
                        "रंग" : "पीला"
                    } ,
                    {
                        "शीर्षक" : "शीर्षक बी" ,
                        "छवि" : "बी" ,
                        "रंग" : "नीला"
                    } ,
                    {
                        "शीर्षक" : "शीर्षक सी" ,
                        "छवि" : "सी" ,
                        "रंग" : "लाल"
                    } ,
                    {
                        "शीर्षक" : "शीर्षक डी" ,
                        "छवि" : "डी" ,
                        "रंग" : "बैंगनी"
                    } ,
                    {
                        "शीर्षक" : "शीर्षक ई" ,
                        "छवि" : "ई" ,
                        "रंग" : "हरा"
                    }
                ]
            } ,
            {
                "पहचानकर्ता" : "IMAGES_WIDGET" ,
                "सामग्री" : [
                    {
                        "छवि" : "छवि" ,
                        "रंग" : "हरा"
                    } ,
                    {
                        "छवि" : "छवि" ,
                        "रंग" : "नीला"
                    } ,
                    {
                        "छवि" : "छवि" ,
                        "रंग" : "नारंगी"
                    }
                ]
            } ,
            {
                "पहचानकर्ता" : "COLLECTION_WIDGET" ,
                "सामग्री" : [
                    {"शीर्षक" : "शीर्षक ई" , "छवि" : "ई" , "रंग" : "हरा" } , { "शीर्षक" : "शीर्षक एफ" , "छवि" : "एफ" , "रंग" : "बैंगनी" " } , { "शीर्षक" : "शीर्षक जी" , "छवि" : "जी" , "रंग" : "लाल" } , { "शीर्षक" : "शीर्षक एच" , "छवि" : "एच" , "रंग" " : "नीला" } , { "शीर्षक" : "शीर्षक H" , "छवि" : "H" , "रंग" : "पीला" } ] } ] } , { "शीर्षक" : "धारा 2" , "विजेट्स" " : [ { "पहचानकर्ता" : "CELLS_WIDGET" , "सामग्री" : [ { "शीर्षक" : "सेल 1" , "रंग" : "लाल" } , { "शीर्षक" : "सेल 2" , "रंग" : "बैंगनी" } , { "शीर्षक" : "सेल 3" , "रंग" : "पीला" } , { "शीर्षक" : "सेल 4" , "रंग" : "नीला" } , { "शीर्षक" : "सेल 5" , "रंग" : "गहरा हरा" } ] } ] } ]

हम कुछ स्क्रीनों का भी अध्ययन करेंगे जिन्हें बैकएंड-संचालित विकास का उपयोग करके बनाया जा सकता है।

Home screens in backend-driven development

लचीला नेविगेशन

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

MovilePay ने Google Pay, Apple Pay, या VisaCheckout मॉडल के आधार पर एक भुगतान SDK विकसित करने का निर्णय लिया, जिसे किसी अन्य एप्लिकेशन के साथ एकीकृत किया जा सकता है।

हालांकि, चूंकि एसडीके पर काम करने का मतलब है कि विशिष्ट विकास पैटर्न का उपयोग करके परीक्षण करने की क्षमता बहुत कम है, स्वचालन आवश्यक है।

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

Optimizing the business process with BDD

MoviePay एप्लिकेशन स्क्रीन में से कोई भी नहीं जानता था कि कौन सी स्क्रीन आगे है। पिछली स्क्रीन के अपने कार्यों को पूरा करने के बाद, सर्वर यह वापस करने के लिए जिम्मेदार था कि कौन सी स्क्रीन आगे प्रदर्शित की जानी चाहिए।

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

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

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

एक ही लक्ष्य को प्राप्त करने के लिए कई वैकल्पिक तरीके हैं। हम आपको दिखाएंगे कि कैसे MoviePay ने iOS के लिए यह किया। यदि वांछित है, तो इस अवधारणा को किसी अन्य फ्रंट-एंड प्लेटफॉर्म पर लागू किया जा सकता है।

जब MovilePay ने इसे लागू किया, तो उन्होंने अतिरिक्त विजेट जोड़ने में आसानी, कोड पठनीयता और एकल जिम्मेदारी जैसी आवश्यकताओं पर विचार किया। चीजों को सरल और अधिक मूल बनाने के लिए, MovilePay ने क्रमांकन के लिए कोडेबल API का उपयोग करने का निर्णय लिया।

विजेट (आईओएस)

लचीलेपन के संदर्भ में, MovilePay ने महसूस किया कि सबसे अच्छा समाधान उन विजेट्स को सामान्यीकृत करना होगा जिन्हें प्रोटोकॉल के साथ पार्स करने की आवश्यकता होती है। MovilePay डेटा को पार्स करने के लिए कौन सी विजेट संरचना निर्धारित करने के लिए एक एनम भी सेट करता है।

 प्रोटोकॉल विजेट : डिकोडेबल { }

एनम विजेट आइडेंटिफ़ायर : स्ट्रिंग , डिकोडेबल {
    केस बैनर = "बैनर"
    केस संग्रह = "संग्रह"
    मामले की सूची = "सूची"

    वर मेटाटाइप : विजेट  टाइप करें {
        स्वयं स्विच करें {
        मामला  बैनर :
            बैनरविजेट लौटाएं  स्वयं
        मामला  संग्रह :
            संग्रह विजेट वापस करें  स्वयं
        मामला  सूची :
            सूची विजेट वापस करें  स्वयं
        }
    }
}

वे विजेट प्रोटोकॉल द्वारा कार्यान्वित डिकोडेबल प्रोटोकॉल के माध्यम से कोडेबल एपीआई का लाभ उठा रहे हैं। नीचे एक विजेट संरचना को परिभाषित करने का एक उदाहरण है।

 स्ट्रक्चर बैनरविजेट : विजेट {
    निजी चलो imageURLString : String
}

संरचना संग्रह विजेट : विजेट {

    स्ट्रक्चर आइटम : डिकोडेबल {
        चलो imageURLString : String
        शीर्षक दें : स्ट्रिंग
        उपशीर्षक दें : स्ट्रिंग
    }

    अनुभाग शीर्षक दें : स्ट्रिंग
    सूची दें : [ आइटम ]
}

स्ट्रक्चर लिस्टविजेट : विजेट {

    स्ट्रक्चर आइटम : डिकोडेबल {
        चलो imageURLString : String
        पाठ दें : स्ट्रिंग
    }

    अनुभाग शीर्षक दें : स्ट्रिंग
    सूची दें : [ आइटम ]
}

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

 फाइनल क्लास AnyWidget : डिकोडेबल {

    निजी एनम कोडिंगकी : कोडिंगकी {
        मामला पहचानकर्ता
    }

    विजेट चलो : विजेट ?

    आवश्यक init ( डिकोडर से : डिकोडर ) फेंकता है {
        करो {
            चलो कंटेनर = डिकोडर का प्रयास करें  कंटेनर ( keyedBy : CodingKeys . self )
            चलो टाइप करें = कंटेनर का प्रयास करें  डीकोड ( विजेटआइडेंटिफायर  स्वयं , फॉरकी : पहचानकर्ता )
            स्व . विजेट = कोशिश करें  मेटाटाइप  init ( से : डिकोडर )
        } पकड़ो {
            स्व . विजेट = शून्य
        }
    }
}

इस इरेज़र प्रकार का उपयोग विजेट के पहचानकर्ता और इसकी "मेटा-प्रकार" संपत्ति को डिक्रिप्ट करने के लिए किया जाता है ताकि यह निर्धारित किया जा सके कि शेष पार्स किए गए विजेट के डेटा को पार्स करने के लिए किस विजेट संरचना का उपयोग किया जाना चाहिए।

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

 स्ट्रक्चर होम रेस्पॉन्स : डिकोडेबल {

    निजी एनम कोडिंगकी : कोडिंगकी {
        केस विजेट
    }

    विजेट दें : [ विजेट ]

    init ( डिकोडर से : डिकोडर ) फेंकता है {
        चलो कंटेनर = डिकोडर का प्रयास करें  कंटेनर ( keyedBy : CodingKeys . self )
        स्व . विगेट्स = कंटेनर का प्रयास करें  डिकोड ( [ AnyWidget ] . self , forKey : . widgetsss = "टोकन विराम चिह्न">)  कॉम्पैक्ट मैप {$ 0. विजेट } } init ( विजेट : [ विजेट ] ) { self . विजेट्स = विजेट्स } }

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

नीचे एक संभावित JSON API प्रतिक्रिया है जिसे यह मॉडल पार्स करेगा।

 {
    "विजेट" : [
        {
            "पहचानकर्ता" : "बैनर" ,
            "imageURLString" : "url_image_to_be_downloaded"
        } ,
        {
            "पहचानकर्ता" : "संग्रह" ,
            " अनुभाग शीर्षक" : "अनुभाग शीर्षक" ,
            "सूची" : [
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "शीर्षक" : "शीर्षक आइटम 1" ,
                    "उपशीर्षक" : "उपशीर्षक आइटम 1"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "शीर्षक" : "शीर्षक आइटम 2" ,
                    "उपशीर्षक" : "उपशीर्षक आइटम 2"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "शीर्षक" : "शीर्षक आइटम 3" ,
                    "उपशीर्षक" : "उपशीर्षक आइटम 3"
                }
            ]
        } ,
        {
            "पहचानकर्ता" : "सूची" ,
            " अनुभाग शीर्षक" : "अनुभाग शीर्षक" ,
            "सूची" : [
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "पाठ" : "पाठ आइटम 1"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "पाठ" : "पाठ आइटम 2"
                } ,
                {
                    "imageURLString" : "url_image_to_be_downloaded" ,
                    "पाठ" : "पाठ आइटम 3"
                }
            ]
        } ,
        {
            "पहचानकर्ता" : "बैनर" ,
            "imageURLString" : "url_image_to_be_downloaded"
        }
    ]
}

यह दृष्टिकोण सुपर ऐप के विकास के बहुत करीब है, जिसने MovilePay को अलग-अलग उपयोगकर्ताओं को अलग-अलग सेवाएं पेश करने, कई प्रदर्शन विकल्पों का परीक्षण करने, परिकल्पना तैयार करने और यह निर्धारित करने की अनुमति दी कि किस सेवा के लिए किस विजेट का उपयोग किया जाएगा। स्क्रीन सॉर्टिंग और सर्विस ग्रुपिंग में बदलाव MovilePay द्वारा पहले किए गए बदलाव के करीब था।

नेविगेशन (आईओएस)

विजेट समस्या को ठीक करने के बाद, MoviePay ने इसी तरह नेविगेशन में सुधार करने का प्रयास किया। उन्होंने एक्शन प्रोटोकॉल बनाया, जो विजेट प्रोटोकॉल के समान था।

एक क्रिया एक संरचित वस्तु है जो कुछ MovilePay एपीआई के JSON प्रतिक्रिया में एक आईडी और किसी भी पैरामीटर के साथ लौटा दी जाती है जिसे उस दृश्य में प्रदर्शित किया जाना चाहिए जो इसे दर्शाता है। नतीजतन, एक्शन प्रोटोकॉल संरचित वस्तु के पुनर्निर्माण में मदद करने के लिए जिम्मेदार है।

 प्रोटोकॉल क्रिया : डिकोडेबल {
    func दृश्य ( ) - > UIViewController
}

एनम एक्शन आइडेंटिफ़ायर : स्ट्रिंग , डिकोडेबल {
    केस होम = "होम"
    केस स्क्रीनऑन = "SCREEN_ONE"
    केस स्क्रीनटू = "SCREEN_TWO"

    वर मेटाटाइप : क्रिया  टाइप करें {
        स्वयं स्विच करें {
        मामला  घर :
            होमएक्शन वापस करें  स्वयं
        मामला  स्क्रीनवनओकेन ऑपरेटर " > : स्क्रीनऑनएक्शन लौटाएं  सेल्फ केस

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

 स्ट्रक्चर होमएक्शन : एक्शन {
    func दृश्य ( ) - > UIViewController {
        होम कोऑर्डिनेटर को लौटें  दृश्य ( )
    }
}

स्ट्रक्चर स्क्रीनऑनएक्शन : एक्शन {
    शीर्षक दें : स्ट्रिंग

    func दृश्य ( ) - > UIViewController {
        ScreenOneCoordinator वापस करें  दृश्य ( शीर्षक : स्वयं शीर्षक )
    }
}

स्ट्रक्चर स्क्रीनटूएक्शन : एक्शन {
    शीर्षक दें : स्ट्रिंग
    उपशीर्षक दें : स्ट्रिंग

    func दृश्य ( ) - > UIViewController {
        ScreenTwoCoordinator लौटाएं  दृश्य ( शीर्षक : स्वयं  शीर्षक , उपशीर्षक : स्वयं  उपशीर्षक )
    }
}

उपरोक्त उदाहरण से पता चलता है कि, जब बनाया जाता है, तो क्रियाओं में उनके दृश्य को प्रारंभ करने के लिए सभी आवश्यक गुण होने चाहिए और UIViewController को तत्काल करने के लिए समन्वयक विधि को कॉल करना चाहिए। समन्वयक संरचनाएं हैं जो UIViewController प्रदान करती हैं। यहाँ उल्लेख करने के लिए कुछ है: MovilePay कोऑर्डिनेटर स्ट्रक्चर्स में एक डिज़ाइन पैटर्न का उपयोग करता है, जिसे एक स्थिर दृश्य () विधि द्वारा दर्शाया जाता है, जिसे प्रत्येक चरण के लिए UIViewController इंस्टेंस बनाने का काम सौंपा जाता है।

 अंतिम श्रेणी गृह समन्वयक : समन्वयक {
    स्टैटिक फंक सीन ( ) - > UIViewController {
        // इस दृश्य के व्यू कंट्रोलर और सभी आर्किटेक्चर घटकों को बनाएं ...
        वापसी निर्मित दृश्य नियंत्रक
    }
}

फाइनल क्लास ScreenOneCoordinator : कोऑर्डिनेटर {
    स्टैटिक फंक सीन ( ) - > UIViewController {
        // इस दृश्य के व्यू कंट्रोलर और सभी आर्किटेक्चर घटकों को बनाएं ...
        वापसी निर्मित दृश्य नियंत्रक
    }
}

फाइनल क्लास स्क्रीन टू कोऑर्डिनेटर : कोऑर्डिनेटर {
    स्टैटिक फंक सीन ( ) - > UIViewController {
        // इस दृश्य के व्यू कंट्रोलर और सभी आर्किटेक्चर घटकों को बनाएं ...
        वापसी निर्मित दृश्य नियंत्रक
    }
}

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

Actions MovilePay संदर्भ के लिए, हमने थोड़े से अनुकूलन के साथ, विजेट्स के लिए उसी प्रकार के इरेज़र का उपयोग किया है।

 अंतिम वर्ग AnyAction : डिकोडेबल {

    निजी एनम कोडिंगकी : कोडिंगकी {
        मामला पहचानकर्ता
    }

    कार्रवाई करने दो : कार्रवाई ?

    आवश्यक init ( डिकोडर से : डिकोडर ) फेंकता है {
        करो {
            चलो कंटेनर = डिकोडर का प्रयास करें  कंटेनर ( keyedBy : CodingKeys . self )
            चलो टाइप करें = कंटेनर का प्रयास करें  डीकोड ( एक्शनआइडेंटिफायर  स्वयं , फॉरकी : पहचानकर्ता )
            स्व . क्रिया = प्रयास प्रकार  मेटाटाइप  init ( से : डिकोडर )
        } पकड़ो {
            स्व . क्रिया = शून्य
        }
    }
}

यहां एक प्रासंगिक नोट यह है कि MovilePay डुप्लिकेट प्रकार के इरेज़र कोड से बचने के लिए जेनेरिक डिज़ाइन पैटर्न का उपयोग कर सकता है। हालांकि, उन्होंने नहीं चुना। निम्नलिखित एक संरचना का एक उदाहरण है जिसमें एक क्रिया है।

 संरचना ResponseModelForActions : डिकोडेबल {
    निजी एनम कोडिंग कीज़"टोकन ऑपरेटर">: कोडिंगकी { केस एक्शन , टेक्स्ट } एक्शन दें : एक्शन ? पाठ दें : स्ट्रिंग इनिट ( डिकोडर से : डिकोडर ) फेंकता है { कंटेनर = डिकोडर का प्रयास करें  कंटेनर ( keyedBy : CodingKeys . self ) self . पाठ = कंटेनर का प्रयास करें  डिकोड ( स्ट्रिंग  स्व , forKey :। पाठ ) किसी भी क्रिया को करने दें = कोशिश करें ? कंटेनर  डिकोड ( AnyAction . self , forKey : . action ) self . क्रिया = कोई क्रिया ?। क्रिया } }

यह एक एपीआई द्वारा प्रदान किया गया JSON हो सकता है, उदाहरण के लिए, स्क्रीन पर UIButton बनाने के लिए। उपयोगकर्ता द्वारा इस बटन को टैप करने के बाद संभाली गई क्रिया वस्तु प्रदान की गई क्रिया को निष्पादित कर सकती है, जिससे एप्लिकेशन होम स्क्रीन प्रदर्शित कर सकता है।

 {
    "पाठ" : "प्रदर्शनकारी पाठ" ,
    "कार्रवाई" : {
        "पहचानकर्ता" : "HOME_SCREEN"
    }
}

सभी समन्वयकों को क्रिया वस्तु के माध्यम से एक नया दृश्य प्राप्त करने की अनुमति देने के लिए समन्वयक प्रोटोकॉल का विस्तार करके इसे आसानी से प्राप्त किया गया था।

यह समन्वयक को कार्य करने की अनुमति देता है, अर्थात, उस क्रिया के लिए अगला UIViewController उदाहरण उत्पन्न करता है और फिर उसे प्रदर्शित करता है।

 विस्तार समन्वयक {
    func दृश्य ( कार्रवाई का उपयोग : क्रिया ) - > UIViewController {
        वापसी कार्रवाई  दृश्य ( )
    }
}

सर्वर कार्यान्वयन पर एक संकेत

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

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

निष्कर्ष

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

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

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