एक तैयार उत्पाद, अमूल्य अनुभव और एक महान व्यापार समाधान प्राप्त करके मोबाइल एप्लिकेशन के विकास को कैसे बचाया जाए

प्रस्तावना:

लेख एक आउटसोर्सिंग यूएस-यूक्रेनी कंपनी के सफल समाधान के लिए खोज के इतिहास का वर्णन करता है। घटनाएँ काल्पनिक नहीं हैं, संयोग यादृच्छिक नहीं हैं।

1. हमने सबसे अच्छा समाधान कैसे खोजा

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





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

• प्रत्येक नए प्लेटफ़ॉर्म के लिए पोर्टिंग या डेवलपमेंट के लिए कोड लिखने के लिए समान समय की आवश्यकता होती है;
• विकास में शामिल डेवलपर्स की संख्या बढ़ रही है;
• नतीजतन, विकास की लागत काफी बढ़ जाती है।

बेशक, ऐसी स्थितियां हैं जब यह मूल एप्लिकेशन लिखने के लायक है:

• बहुत उच्च उत्पादकता की जरूरत है;
• समाधान के लिए ग्राहक की ओर से बड़ी मात्रा में डेटा संसाधित करना आवश्यक है;
• हार्डवेयर या ऑपरेटिंग सिस्टम के लिए उपयोगिताओं को लिखते समय;
• वीडियो या गेम परिदृश्यों, अतिरिक्त वास्तविकता के आधार पर समाधान बनाते समय।

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

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

एक मानक के रूप में, हमने देशी अनुप्रयोगों की सर्वोत्तम विशेषताओं को लिया:

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

नीचे दिए गए तालिका 1 मुख्य कारकों को निर्धारित करता है जो सबसे अच्छा विकल्प निर्धारित करने के लिए महत्वपूर्ण हैं:

हमें अन्य मुख्य लोकप्रिय समाधानों के बीच एक विकल्प का सामना करना पड़ा:

• स्वच्छ क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन (उदाहरण के लिए, फोन गैप का उपयोग करके कार्यान्वित);
• हाइब्रिड क्रॉस-प्लेटफ़ॉर्म समाधान (प्रत्येक प्लेटफ़ॉर्म के लिए मोबाइल साइट + रैपर);
• HTML5 मोबाइल फोन साइट।

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

फोन गैप का उपयोग करके ऐसे मोबाइल एप्लिकेशन के विकास में समस्याएं पहले से ही शुरुआती दौर में शुरू हुई थीं:

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

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

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

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

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

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

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

2. हम गूगल क्लोजर में कैसे आए

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

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

• jQuery मोबाइल ने संरचना (DOM) में बहुत अधिक परिवर्तन किए हैं;
• सर्वर साइड पर बहुत सारे एपीआई अनुरोध किए गए थे;
• सर्वर और ASP.NET वेब एप्लिकेशन के बीच डेटा ट्रांसफर के कारण डेटा का दोहरा क्रमीकरण और डिसेरलाइज़ेशन हुआ;
• सर्वर साइड पर कोड का कोई संपीड़न और अनुकूलन नहीं था;
• क्लाइंट पर, एप्लिकेशन में समस्याओं का मुख्य अभिव्यक्ति स्क्रीन के बीच संक्रमण में "विचारशीलता" थी।

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

इस स्थिति में, आउटपुट पर हमें एक वेबसाइट एप्लिकेशन प्राप्त हुई है:

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

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

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

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

3. हमने पिकाबा मोबाइल परियोजना को कैसे लागू किया

2012 के अंत तक हमने प्रौद्योगिकी स्टैक पर निर्णय लिया, हमने न्यूनतम कार्यक्षमता के साथ एक क्रॉस-प्लेटफ़ॉर्म हाइब्रिड मोबाइल एप्लिकेशन विकसित करना शुरू कर दिया, जो इसके लिए अनुमति देगा:

• लॉग इन करें और खाते बनाएँ;
• एप्लिकेशन बनाएं, संपादित करें और सहेजें;
• एप्लिकेशन, उत्पाद और सेवाएं देखें और उनके लिए खोजें;
• प्रोफाइल, ग्रिड द्वारा ब्राउज़ करें।

इस प्रकार, प्राथमिक कार्य ग्राहकों के लिए सभी आवश्यक कार्यक्षमता बनाना था। विक्रेताओं के लिए कार्यक्षमता बाद में लागू की जानी थी।

डेवलपर्स को Google क्लोजर के साथ बातचीत के लिए अपने MVC फ्रेमवर्क को विकसित करने का भी काम था। बेशक, कोई भी इस तरह के फ्रेमवर्क के अस्तित्व के बारे में नहीं भूल गया जैसे कि AngularJS , EmberJS , KnockoutJS , जिसमें MVC मॉडल को शुरू में लागू किया गया था और UI के साथ बातचीत सरल और कम से कम होगी। लेकिन एक सर्वव्यापी संकलनकर्ता के रूप में Google क्लोजर टूल्स से "बन्स", यूनिट परीक्षण लिखने के लिए समर्थन और उपकरण इन छोटी असुविधाओं के लिए एक योग्य शुल्क बन गए हैं।

नतीजतन, उपरोक्त कार्यक्षमता को पिछले समाधान की तुलना में बहुत तेजी से लिखा और परीक्षण किया गया था , क्योंकि टीडीडी का उपयोग किया गया था ।

4. मार्केटिंग बोनस

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

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

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

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



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

PSS हम कुछ महीनों में प्राप्त अनुभव और पहले से ही समाप्त बंडल को लागू करने में कामयाब रहे, जब विकास के लिए एक छोटा सामाजिक वाणिज्य परियोजना दिखाई दी। हमने पिबाबा मोबाइल से एमवीसी फ्रेमवर्क का उपयोग करके विकास को गति दी।