मोबाइल डेवलपर के दृष्टिकोण से प्रतिक्रिया मूलक

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

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

इनकार

मोबाइल एप्लिकेशन में जावास्क्रिप्ट? IOS पर JavaScriptCore के उपयोग के साथ केवल कुछ पुस्तकालयों की जानकारी मेरे दिमाग में आई (इन पुस्तकालयों में उन अनुप्रयोगों के क्रैश का 90% हिस्सा था, जिनमें उनका उपयोग किया गया था) और "पुराने मॉडल" के हाइब्रिड अनुप्रयोग (ठीक है, जो कि आम तौर पर असस हैं)।

हाइब्रिड अनुप्रयोगों ने उम्मीद जताई कि जब तक आप उन्हें आज़माएंगे, उसके बाद आप उनसे दूर तक और जहाँ तक संभव हो भागना शुरू करें।

3 साल पहले ज़ामरीन को सीखने के असफल प्रयासों को याद करते हुए, मैंने तुरंत रिएक्ट नेटिव का उपयोग करने का विचार त्याग दिया।

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

कोप

जब मैं पहले से ही जानता हूं कि यह "वास्तविक" कैसे करना है तो मुझे एक सरलीकृत संस्करण क्यों सिखाना चाहिए!
मुझे अभी भी इस सवाल का जवाब ढूंढना था जब कंपनी ने किसी एक एप्लिकेशन को पूरी तरह से रीडिज़ाइन करने का काम निर्धारित किया था (उस समय केवल आईओएस पर उपलब्ध) और इसे एंड्रॉइड पर जारी करना।

एक साथ दो काम कैसे करें और कम कोड लिखें? जैसे सुझाव: एक पतली ग्राहक, स्विफ्ट / कोटलिन कोड, रिएक्ट नेटिव से एक कॉल के साथ सी लाइब्रेरी?

लाइब्रेरी बनाने की क्षमता के कारण रिएक्ट नेटिव काफी आशाजनक लग रहा था और फिर उन्हें तुरंत तीन प्लेटफार्मों (आईओएस / एंड्रॉइड / वेब) पर उपयोग करना था।

नीलाम

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

मंदी

संदेह वाजिब था। मुख्य समस्याएं हैं:

• प्रतिक्रियाशील मूल के मूल में बूंदों की एक सभ्य मात्रा;
• विधियाँ जो केवल एक ही प्लेटफ़ॉर्म पर काम करती हैं (डॉक इंगित करती हैं कि वे हर जगह काम करती हैं);
• अधूरा विवरण। बस रिएक्ट नेटिव कलेक्टर के गोदी को देखें ।

मुख्य छिपी हुई समस्या: मेरे सिर में आंतरिक ब्लॉक, जिसने मुझे मीनारों के एक समूह के पीछे प्लसस को देखने से रोका।

स्वीकार

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

यदि हम स्पष्ट समस्याओं को छोड़ देते हैं, जैसे कि क्रैश और मेज़र डॉक, तो यहाँ उदाहरण हैं कि मुझे क्या सामना करना पड़ा:

जावास्क्रिप्ट

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

यदि आप रिएक्ट नेटिव पर एप्लिकेशन लिखने का निर्णय लेते हैं, तो मैं नवीनतम जेएस पाठ्यक्रमों में से एक लेने की सलाह देता हूं। उन्हें प्रतिक्रिया या प्रतिक्रिया मूलक होने की आवश्यकता नहीं है।

पिछले कुछ वर्षों में, ES6, ES7, और ES8 मानकों के रिलीज के साथ, आपके द्वारा कोड लिखने का तरीका बहुत बदल गया है।

और वह बहुत व्यक्तिगत हो गया।

स्थैतिक जाँच

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

विभिन्न उपयोगिताओं हैं जो इसकी अनुपस्थिति को सुचारू करती हैं, कार्यों का हिस्सा प्रदर्शन करती हैं

लेआउट तत्व

यहां सबसे बड़ी चुनौती शुरुआती आईओएस डेवलपर्स के लिए होगी।

यह चुनौती एक विज़ुअल इंटरफेस एडिटर की कमी है।

सब कुछ JSX मार्कअप का उपयोग करके कोड में किया जाता है। तकनीकी रूप से, यह मार्कअप वैकल्पिक है, यह घटकों के पदानुक्रम को देखने में मदद करता है। Android डेवलपर्स XML के साथ समानता को देखते हुए, कम से कम होंगे।

उसी समय विचारों का एक स्पष्ट दृष्टिकोण और पुन: उपयोग की संभावना है।

आईओएस में, या तो एक या दूसरा है, जो कि किस पद्धति पर चयन करना है (कोड में लेआउट या इंटरफ़ेस बिल्डर में)। हां, इन दोनों समस्याओं को हल किया जा सकता है, लेकिन आपको एक सभ्य कोड लिखना होगा।

React Native में यह समस्या नहीं है।
एंड्रॉइड में, वैसे, यह वहां भी नहीं है।
लेकिन एंड्रॉइड विशेषज्ञ मार्कअप में सीधे बाहरी घटकों से आंतरिक में स्थानांतरित होने के तरीके की सराहना करेंगे।

यहां मूल दृश्य एक ही समय में स्थिरांक के एक मिश्रण के साथ रैखिकअरआउट (Android) और UIStackView (iOS) का एक एनालॉग है। पोजिशनिंग तत्वों की तुलना में काफी सरल तरीका (कॉन्ट्रास्ट की तुलना में)।

UIViewController और गतिविधि

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

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

• यूआई तत्व इनपुट मापदंडों को बदलते समय स्वयं स्थिति / उपस्थिति बदलते हैं;
• Android पर onSaveInstantState को टकराने की कोई आवश्यकता नहीं है। प्रतिक्रिया मूल निवासी यह सब हमारे लिए करता है;
• iOS पर ऐसी कोई विधियाँ नहीं हैं जो एप्लिकेशन स्क्रीन के प्रकट / छिपने के क्षण को स्पष्ट रूप से रिपोर्ट करती हैं।

बिल्ड टाइम / लाइव रीलोड / हॉट रीलोड

वृद्धिशील असेंबली के कारण महान गति प्राप्त की जाती है - केवल संशोधित मॉड्यूल का पुनर्निर्माण किया जाता है, न कि पूरे बंडल को।

जेएस कोड में सभी परिवर्तन सिम्युलेटर में तुरंत दिखाई देते हैं। विकास को तेजी से बढ़ाता है!

जेएस में देशी कार्यक्षमता का अभाव

रिएक्ट नेटिव के जेएस भाग में, आपकी जरूरत की हर चीज बॉक्स से बाहर नहीं है।

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

तीसरे पक्ष के डेवलपर्स द्वारा तैयार किए गए बड़ी संख्या में तैयार मॉड्यूल हैं।

सभी मॉड्यूल npm (iOS और Android के लिए ग्रेडल के लिए कोकोआपॉड का एनालॉग) के माध्यम से जुड़े हुए हैं, जिनके पास आवश्यक कार्यक्षमता के साथ मूल कोड है।

यूनिवर्सल और गहरे लिंक

कार्यक्षमता फेसबुक द्वारा कार्यान्वित की जाती है।
यह अच्छी तरह से और लगातार काम करता है।

प्रसंस्करण तीसरे पक्ष के इरादे

पिछले पैराग्राफ के एक विशेष मामले के रूप में।

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

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

उत्पादकता

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

और आप जेस्चर और उनके संघटन का सामान्य नियंत्रण बॉक्स से बाहर नहीं निकाल सकते।

अस्थिरता

अक्सर एक परियोजना बस निर्माण बंद कर देती है, उदाहरण के लिए:

• प्रतिक्रियाशील कर्नेल अपडेट (लघु संस्करण को अपडेट करते समय सहित);
• एनपीएम मॉड्यूल अपडेट;
• Xcode अपडेट;
• कोकोआपोड्स अपडेट (इसके साथ स्थायी समस्याएं);
• बस ऐसे ही। हां, ऐसा भी होता है।

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

3 पक्ष निर्भरता अस्थिरता

IOS पर सबसे बड़ी समस्या थी और विधि swizzling का उपयोग करने के लिए npm मॉड्यूल की व्यापक इच्छा है।

कई मूल मॉड्यूल बायनेरिज़ द्वारा जुड़े हुए हैं। यह समझना कि कई स्वतंत्र मॉड्यूल svizlyat एक ही विधि इतनी सरल नहीं है।

विधानसभा कई चरणों में होती है और उनमें से प्रत्येक में कुछ गलत हो सकता है।

तृतीय-पक्ष निर्भरता को अद्यतन करते समय अस्थिरता

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

एक समान समस्या अगर npm मॉड्यूल विभिन्न संस्करणों के साथ देशी एंड्रॉइड मॉड्यूल पर भरोसा करते हैं।

कैश की सफाई के बाद, नए संस्करण चुपचाप लोड हो सकते हैं। ऐसा लगता है कि उन्होंने कुछ नहीं किया, लेकिन काम करना बंद कर दिया।

यूनिट और यूआई परीक्षण

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

यूआई परीक्षण के लिए पुस्तकालय हैं। अब तक, वास्तव में, मुझे इसका उपयोग करने की आवश्यकता नहीं थी।

निष्कर्ष

रिएक्ट नेटिव के साथ काम करने के 13 महीने बाद, मैं आत्मविश्वास से कह सकता हूं:

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

किसी ऐसे व्यक्ति के लिए अंतिम शब्द जिसने तुरंत प्रतिक्रिया मूल पर लिखना शुरू कर दिया और किसी कारण से इस लेख को पढ़ने का फैसला किया, यहां तक ​​कि बहुत अंत तक।

यदि आपको लगता है कि आप विषय को समझते हैं और आप अच्छा कर रहे हैं, तो कृपया, अपने आप को मूल डेवलपर के रूप में आज़माएं।