💅🏼 👃🏾 💪🏿 नया आवेदन "जेलिफ़िश"। क्यों फड़फड़ाना? 📐 ㊙️ 😔

तकनीकी निदेशक बोरिस गोर्याचेव इस बारे में बात करते हैं कि मेडुसा ने एक साल तक इस पर कैसे काम किया और इसे फ़्लटर में क्यों लिखा गया

12 मई को, नए मेडुसा मोबाइल एप्लिकेशन ( आईओएस , एंड्रॉइड ) की रिहाई हुई - लगभग दो साल बाद जब हमने उन्हें फिर से लिखने का फैसला किया। इतना लंबा क्यों? देशी ऐप्स क्यों नहीं? स्पंदन क्यों? यह सब मेडुसा बोरिस गोर्याचेव के तकनीकी निदेशक द्वारा बताया गया है।

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

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

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

साइट पर काम के समानांतर में, हम एक नए एप्लिकेशन के बारे में सोच रहे थे - हम इसके नेविगेशन, अर्थ, स्क्रीन, फीचर्स और इतने पर आए।

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

क्यों यह अभी भी स्पंदन है। और डार्ट के बारे में थोड़ा

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

डार्ट एक प्रोग्रामिंग भाषा है जिसे Google द्वारा विकसित किया गया था। यह 2011 में घोषित किया गया था, अर्थात यह अभी भी एक युवा भाषा है। यह एक प्रमुख प्रोग्रामिंग भाषा नहीं बन गई है (कम से कम अभी के लिए), लेकिन साथ ही साथ यह कंपनी में ही बहुत सक्रिय रूप से उपयोग की जाती है। Google के अलावा, अन्य बड़ी कंपनियां हैं, उदाहरण के लिए, Wrike, जो डार्ट का उपयोग करते हैं और उस पर पूर्ण स्टैक लिखते हैं।

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

मैं यह समझाने की कोशिश नहीं करूंगा कि फ़्लटर में क्या शामिल हैं - विकिपीडिया इस कार्य को बेहतर तरीके से सामना करेगा, लेकिन मैं केवल यह कहूंगा कि लेखकों में ऐसे लोग हैं जो क्रोमियम में प्रस्तुत किए गए हैं।

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

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

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

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

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

पारिस्थितिकी तंत्र

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

इसके अलावा, Google स्वयं फ़्लटर का अच्छी तरह से समर्थन करता है। हम पुशबेट, एनालिटिक्स, प्रोफाइल और स्टोरिंग यूजर डेटा (रीडिंग हिस्ट्री, एपिसोड पोज़िशन्स, बुकमार्क) और सब कुछ "बस काम करता है" के लिए फायरबेस का उपयोग करते हैं। बेशक, एक ऐसे व्यक्ति के रूप में, जिसने पहले कभी भी देशी एप्लिकेशन नहीं लिखे हैं, कभी-कभी यह वर्गीकृत फ़ाइलों में चढ़ने या info.plist में संपत्ति डालने के लिए जंगली है। लेकिन आमतौर पर सब कुछ गुगली हो जाता है, और अविश्वसनीय रूप से जटिल कुछ भी नहीं है।

मंच का अंतर

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

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

सबसे सरल और सबसे ज्वलंत उदाहरण iOS में वापस स्वाइप करना है। स्क्रीन का क्षेत्र जो स्वाइप स्वीकार करता है, डिफ़ॉल्ट रूप से लगभग 20 पिक्सेल का होता है। यह है कि मेल एप्लिकेशन iPhones पर कैसे काम करता है, और यह बहुत असुविधाजनक है। ट्विटर पर, यह क्षेत्र थोड़ा विस्तारित है, जबकि टेलीग्राम पर, यह बहुत बड़ा है! एंड्रॉइड पर टेलीग्राम में चैट सूची से चैट करने के लिए अपना विशेष प्रकार का नेविगेशन है, यह आईओएस और एंड्रॉइड के बीच एक क्रॉस है। हां, दिशानिर्देश शांत हैं, लेकिन iPhone XR पर, डिवाइस के ऊपरी बाएं किनारे पर अपनी उंगली तक पहुंचना बहुत असुविधाजनक है। इसलिए हमने फैसला किया (निश्चित रूप से, डेटा पर भरोसा करते हुए) कि "मेडुसा" एप्लिकेशन में, iOS पर "बैक" बटन नीचे होगा। लेकिन एंड्रॉइड पर यह बिल्कुल नहीं होगा। ऐसा करने के लिए, svaypas (हमारे अपने और नए एंड्रॉइड svaypas दोनों) और एक सिस्टम बटन "बैक" हैं।

मेरे सहयोगी, मेडुसा नास्त्य यारवया के कला निर्देशक कहते हैं:

मेरे पास छोटे हाथ और एक बड़ा फोन है। यह हास्यास्पद लगता है, लेकिन इसने विकास प्रक्रिया में दो महत्वपूर्ण निर्णयों को प्रभावित किया। सबसे पहले, मैंने स्वाइप ज़ोन को वापस बढ़ाने (50% तक बढ़ाने) का प्रस्ताव दिया - दिशानिर्देशों से पहला विचलन। फिर, जब हमने सामग्री के अंदर नेविगेशन और फ़ंक्शन बटन पर काम किया, तो मैंने नीचे दिए गए बटन को सामान्य मेनू में डालने का सुझाव दिया - यह इंटरफ़ेस में सामान्य पैटर्न से एक और विचलन है। अब आप इसे अपने अंगूठे के साथ पहुंचा सकते हैं, क्योंकि वे मुख्य रूप से इसके द्वारा स्क्रॉल किए जाते हैं।

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

थोड़ा अभ्यास: यह स्पंदन में कैसे काम करता है

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

मोटे तौर पर, दो प्रकार के विजेट हैं जो एक डेवलपर के साथ बातचीत करता है: स्टेटलेस और स्टेटफुल।

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

स्टेटफुल विजेट्स में एक सेटस्टैट फंक्शन (हैलो, रिएक्ट!) होता है। आप स्थिति बदलते हैं, और विजेट फिर से तैयार किया जाता है।

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

स्पंदन के लिए कई समाधान हैं। उदाहरण के लिए, एक BloC पैटर्न है जिसमें डेटा स्रोतों से स्ट्रीम और इवेंट का उपयोग किया जाता है, उनमें व्यावसायिक तर्क होते हैं जो नई घटनाओं के जन्म को उत्तेजित करते हैं। इन घटनाओं को विगेट्स द्वारा सुना जाता है, और विगेट्स परिवर्तनों का जवाब देते हैं।

जो लोग रिएक्ट के बाद आते हैं वे Redux को आजमाना चाहते हैं। सिद्धांत रूप में, इस दृष्टिकोण का उपयोग करके रिएक्ट में लिखे जाने पर कोई समस्या नहीं होनी चाहिए।

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

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

आमतौर पर, प्रदाताओं को एप्लिकेशन के बहुत "शीर्ष" पर विज्ञापित किया जाता है, और आप एक ही बार में कई प्रदाताओं का उपयोग कर सकते हैं - प्रत्येक अपने स्वयं के व्यवसाय तर्क के लिए जिम्मेदार है।

अब हम आठ प्रदाताओं का उपयोग करते हैं जो आवेदन के विभिन्न स्थानों में "सुन" रहे हैं। उदाहरण के लिए, यहां बुकमार्क प्रदाता कैसे काम करता है, इसके लिए पाठक अपनी पसंदीदा सामग्री को सहेज सकते हैं, इसे ऑफ़लाइन पढ़ सकते हैं और एक ही स्थान से विभिन्न उपकरणों के लिए।

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

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

परिणामस्वरूप, सही रंग इस तरह विजेट पर आता है:

TextSpan(
	text: block['data']['first'],
	style: TextStyle(
		color: Provider.of<ThemeProvider>(context)
        .current
        .bodyFontColor,                            
  fontFamily: 'Proxima Nova',
));

प्रदाता कोड, यदि सरलीकृत किया जाता है:

class ThemeProvider extends ChangeNotifier {
  CustomThemeData current;
  
  CustomThemeData blackTheme = CustomThemeData(
    name: 'black',
    bodyFontColor: Color.fromRGBO(184, 184, 184, 1),
    ...
  );
  
  CustomThemeData lightTheme = CustomThemeData(
    name: 'black',
    bodyFontColor: Color.fromRGBO(184, 184, 184, 1),
    ...
  );
  
  ThemeProvider(withTheme, withFontMultiplier, withAutoTheme) {
    theme = withTheme;
    autoTheme = withAutoTheme;
    current = withTheme == 'light' ? lightTheme : blackTheme;
  }
}

तदनुसार, जब आप वर्तमान चर को बदलते हैं, तो थीम से रंग लेने वाले सभी विजेट बिना किसी अपवाद के सही ढंग से प्रदर्शित होंगे।

आगे क्या होगा

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

नया आवेदन "जेलिफ़िश"। क्यों फड़फड़ाना?

क्यों यह अभी भी स्पंदन है। और डार्ट के बारे में थोड़ा

पारिस्थितिकी तंत्र

मंच का अंतर

थोड़ा अभ्यास: यह स्पंदन में कैसे काम करता है

आगे क्या होगा

More articles: