Electron: मोबाइल समर्थन

मुझे लगता है कि परमाणु-खोल मुख्य रूप से परमाणु पाठ संपादक के लिए बनाया गया था, इसलिए मुझे उम्मीद नहीं थी कि यह मोबाइल प्लेटफॉर्म का समर्थन करेगा। HTML5 मोबाइल ऐप्स के लिए Phonegap और Cordova हैं।

हाँ, लेकिन यह नोड.जेएस मॉड्यूल से कोड साझा करने और निम्न स्तर के संसाधनों तक पहुँचने के बारे में है

मोबाइल प्लेटफॉर्म के लिए, लगभग सभी एटम-शेल के एपीआई लागू नहीं होते हैं, इसलिए मुझे नहीं लगता कि हम कभी भी मोबाइल प्लेटफॉर्म का समर्थन करेंगे।

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

+1 @trusktr

@trusktr एक महान तृतीय-पक्ष मॉड्यूल की तरह लगता है जो कॉर्डोवा के लिए संगतता शिम प्रदान करेगा

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

मुझे विश्वास नहीं हो रहा है कि यह पहले से ही 2016 है और अभी भी ऐसी कोई बात नहीं है।

@ emin93 यह रचनात्मक नहीं है, जैसा कि पहले ही @zcbenz द्वारा बताया गया है, इलेक्ट्रॉन एपीआई को मोबाइल पर पोर्ट करना लगभग असंभव होगा।
आप कम से कम किसी प्रकार के सुझावों के बिना सुविधाओं की मांग नहीं कर सकते कि इसे कैसे किया जाए।

@YuriSolovyov मैं सीधे इलेक्ट्रॉन की बात नहीं कर रहा हूँ। वास्तव में कोई विकल्प नहीं है और यही मुझे निराश करता है। लेकिन हाँ, आप सही कह रहे हैं, यह वास्तव में उस पर चर्चा करने के लिए सही जगह नहीं है।

मोबाइल के लिए इलेक्ट्रॉन इतना बढ़िया होगा। मेरे पास कुछ इलेक्ट्रॉन ऐप्स विकसित हुए हैं और ढांचे से प्यार करते हैं लेकिन हर दिन मैं चाहता हूं कि हम इसे मोबाइल पर भी काम करते देखें।

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

मुझे वास्तव में उम्मीद है कि कुछ कॉर्पोरेट प्रायोजक मोबाइल के लिए इलेक्ट्रॉन के ऐसे पोर्ट/फोर्क को निधि देने के लिए बोर्ड पर आ सकते हैं जिसे अंततः उसी ढांचे में बेक किया जाएगा ताकि हमारे पास एक पूर्ण जेएस आधारित क्रॉस प्लेटफॉर्म एप्लिकेशन डेवलपमेंट फ्रेमवर्क हो सके।

आपके महान कार्य के लिए धन्यवाद इलेक्ट्रॉन टीम!

@cjfromthesea से मूल प्रश्न को प्रतिध्वनित करते हुए, क्या कोई मोबाइल पर इलेक्ट्रॉन के एपीआई (शायद @zcbenz) के साथ होने वाली समस्याओं की व्याख्या कर सकता है? कुछ सामान्य मार्गदर्शन के साथ, मैं और अन्य लोग संभावित रूप से हैकिंग और छेड़छाड़ करके समस्याओं के समाधान के बारे में सोचना शुरू कर सकते हैं। मैंने jxcore-cordova के साथ थोड़ा सा व्यवहार किया है, लेकिन कुछ मार्गदर्शन अच्छा होगा। बाधाएं क्या हैं?

@lastmjs एक बड़ी बाधा यह है कि इलेक्ट्रॉन V8 का उपयोग करता है जो iOS पर समर्थित नहीं है। इसका मतलब है कि क्रोमियम और Node.js भी iOS पर काम नहीं करेंगे और ये तीनों इलेक्ट्रॉन के मुख्य घटक हैं।

IOS के लिए एक नया क्रोमियम संस्करण जनवरी में जारी किया गया था, और node.app शायद node.js के लिए चाल चल सकता है। और Android को कोई समस्या नहीं होनी चाहिए क्योंकि V8 समर्थित है।
इस बीच, हम आईओएस के लिए इलेक्ट्रॉन के साथ कॉर्डोवा का उपयोग करने के तरीके पर एक दस्तावेज लिख सकते हैं (जैसा कि मुझे वास्तव में उनकी आवश्यकता है, मुझे मदद करने में खुशी होगी)।

IOS के लिए @noelmace Chrome क्रोमियम इंजन का उपयोग नहीं करता है क्योंकि Apple इसकी अनुमति नहीं देता है। यह सिर्फ WKWebView है जैसे सफारी इसका उपयोग करता है, लेकिन एक अलग यूआई के साथ।

@ emin93 क्या नोड.एप जैसे किसी भी कस्टम दुभाषिया का उपयोग करने की अनुमति देता है?

मेरे कुछ प्रश्न थे जिन पर मुझे इस सूत्र में विचार करना अच्छा लगेगा-

• क्या आप _one ऐप बनाना चाहते हैं जो हर जगह चलता हो_?
  
  
  
  • अनुवर्ती प्रश्न, क्या डेस्कटॉप ऐप्स के उदाहरण हैं (जो वेब ऐप्स नहीं हैं) जो मोबाइल ऐप्स भी हैं?
  
  
• या आप इलेक्ट्रॉन ऐप बिल्डिंग _experience_ की तलाश कर रहे हैं लेकिन मोबाइल पर?
  
  
  
  • अनुवर्ती प्रश्न, यह कॉर्डोवा/फोनगैप (या अन्य) से कैसे भिन्न होगा?
  
  

मैं निश्चित रूप से एक ऐसे ऐप की तलाश में हूं जो हर जगह चल सके। एक कोडबेस, एक वेब प्लेटफॉर्म, कोई भी वातावरण।

अच्छे मोबाइल/डेस्कटॉप/वेब ऐप्स के उदाहरण, जहां स्क्रीन का आकार और डिवाइस वास्तव में मायने नहीं रखता है, लेकिन आप समान कार्यक्षमता चाहते हैं:

• क्रोम
• फ़ायर्फ़ॉक्स
• ढीला
• जीमेल लगीं
• गूगल फोटो
• गूगल मानचित्र

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

धन्यवाद @lastmjs। मैंने अभी अपना प्रश्न संपादित किया क्योंकि मैं जो सोच रहा था, लेकिन निर्दिष्ट नहीं किया था, वह डेस्कटॉप ऐप्स था जो मोबाइल ऐप्स भी हैं लेकिन वेब ऐप्स नहीं हैं। मुझे लगता है कि यह एक महत्वपूर्ण अंतर है।

लेकिन मेरी राय में जहां तक ​​संभव हो कोर कार्यक्षमता वही रहनी चाहिए

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

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

@jlord

मैं मोबाइल और डेस्कटॉप के लिए निर्माण करता हूं और @lastmrs और @noelmace . की टिप्पणियों में जोड़ना चाहूंगा

यहां मेरे विचार हैं कि यह सभी के लिए कैसे काम कर सकता है।

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

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

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

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

मुझे नहीं पता था कि Google टीम ने iOS के लिए क्रोम को मल्टी-प्रोसेस होने के लिए अपडेट किया था। मैं इसे देखने के लिए सुपर एक्साइटेड हूं।

अगर मैं इसमें से किसी की मदद कर सकता हूं तो मुझे खुशी से मदद मिलेगी।

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

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

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

ध्यान दें कि कॉर्डोवा में Node.js API उपलब्ध नहीं हैं, इसलिए इलेक्ट्रॉन को कुछ देशी Node.js मॉड्यूल को उन विकल्पों के साथ पॉलीफ़िल करने की आवश्यकता होगी जो कॉर्डोवा में काम करते हैं, जैसा कि ब्राउज़र के लिए Browserify करता है। यह एक एकीकृत एपीआई बनाने में मदद करेगा, क्योंकि अगर ऐसा कुछ है जो इलेक्ट्रॉन एपीआई कवर नहीं करता है, तो कम से कम पॉलीफिल्ड libs का मतलब है कि उपयोगकर्ता नोड-आधारित एपीआई पर वापस आ सकता है जो दृश्यों के पीछे कॉर्डोवा एपीआई कहते हैं।

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

मैं यह भी बताना चाहूंगा कि Android और IOS अब केवल मोबाइल नहीं रह गए हैं। जिस प्रोजेक्ट पर मैं काम कर रहा हूं वह एंड्रॉइड टीवी पर बहुत अच्छा लगेगा, साथ ही मुझे नहीं पता कि जीथब टीवी या टैबलेट पर एटम को क्यों नहीं चलाना चाहता।

बढ़िया बिंदु, यह अब स्क्रीन आकार के बारे में नहीं है, हम सामान्य प्रयोजन ऑपरेटिंग सिस्टम से निपटना शुरू कर रहे हैं।

मैं एंड्रॉइड पर इलेक्ट्रॉन के संबंध में स्थिति के बारे में उलझन में हूं?

क्या यह कुछ ऐसा है जिस पर सक्रियता से विचार किया जा रहा है या केवल कुछ के बारे में बात की जा रही है?

फोनगैप या कॉर्डोवा ऐप्स के लिए इलेक्ट्रॉन ऐप्स को एक वैध लक्ष्य बनाना लगभग 1000X आसान है!
अर्थात। cordova platform add electron-osx electron-win electron-linux

@purplecabbage यकीन है लेकिन फिर आप पूरे ब्राउज़रस्टैक को नियंत्रित करने के सभी अतिरिक्त लाभ खो देते हैं।

आरई: Node.js पॉलीफिल।

हमें इसके काम करने के लिए आवश्यक _native_ पॉलीफ़िल्स की एक सूची शुरू करनी चाहिए। Browserify में पहले से ही Node.js Core के _lot_ के शुद्ध वेब संस्करण हैं। केवल वही जो मैं सोच सकता हूं कि हमें इसकी आवश्यकता होगी:

• dns
• net
• fs

और कुछ?

वैश्विक वस्तुएं:

• __दिरनाम
• __फ़ाइल का नाम
• प्रक्रिया

@purplecabbage ऐसा लगता है कि उन 3 में ब्राउज़र कार्यान्वयन है। https://github.com/substack/browserify-handbook#__dirname। क्या हमें उन्हें उपकरणों के आधार पर अलग-अलग मूल्य देना चाहिए?

हाँ, __dirname और __filename बड़े नहीं हैं।
ब्राउज़र में प्रक्रिया बेयरबोन है, क्या हम घटनाओं का समर्थन नहीं करना चाहेंगे?
https://github.com/defunctzonbie/node-process/blob/master/browser.js

इलेक्ट्रॉनिक.जेएस के साथ कोड साझा करने वाले नेटिव मोबाइल ऐप्स के लिए, मुझे लगता है कि इलेक्ट्रॉन.जेएस को नेटिवस्क्रिप्ट - http://github.com/NativeScript/NativeScript के साथ जोड़कर मार्ग का पता लगाना सबसे अच्छा होगा।

हम (नेटिवस्क्रिप्ट टीम) एक नमूना डेमो ऐप बनाने की योजना बना रहे हैं, यदि आप रुचि रखते हैं, तो कृपया इस मुद्दे पर टिप्पणी करें - https://github.com/NativeScript/NativeScript/issues/2695

दरअसल, पहले से ही उपलब्ध एंगुलर 2 उन्नत बीज है जो इसे सक्षम करता है - https://github.com/NathanWalker/angular2-seed-advanced। लेकिन इस तरह के समाधान को लागू करने के लिए कोणीय 2 की आवश्यकता नहीं है।

क्या यह कुछ समझ में आता है?

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

@valentintoychev यह वास्तव में एक दिलचस्प विचार है, हालांकि इसका मूल रूप से मतलब है कि किसी भी इलेक्ट्रॉन ऐप को इसे फिर से करना होगा, यह संपूर्ण यूआई सही है? यह वास्तव में दिलचस्प होगा यदि आप किसी तरह libchromiumcontent को $#$ electron webview बनाने के लिए शामिल कर सकते हैं। तब दोनों को एक ऐप में इस्तेमाल करना आसान हो जाएगा।

Android WebView विजेट और iOS पर समकक्ष के बारे में क्या? वास्तव में एंड्रॉइड वन पहले से ही क्रोमियम है। :)

@ हदीस हां, आईओएस और एंड्रॉइड के लिए एक बार नेटिवस्क्रिप्ट का उपयोग करके और एक बार इलेक्ट्रॉन का उपयोग करके डेस्कटॉप के लिए मोबाइल यूआई को लागू करने का विचार है। बाकी सब कुछ - डेटा, मॉडल, व्यावसायिक तर्क, सेवाएं, डेटा एक्सेस समान होना चाहिए।

यहां दो बातें ध्यान देने योग्य हैं।

सबसे पहले, आप लगभग एक ही कौशल का उपयोग कर रहे होंगे (मतलब एक टीम इसे डेस्कटॉप, वेब और मोबाइल के लिए बना सकती है) इलेक्ट्रॉन.जेएस और नेटिवस्क्रिप्ट के साथ निर्माण करते समय - यह सभी जावास्क्रिप्ट/टाइपस्क्रिप्ट/सीएसएस है। आप चाहें तो एंगुलर 2 का इस्तेमाल कर सकते हैं। स्टाइलिंग के लिए, आप नेटिवस्क्रिप्ट और इलेक्ट्रॉन दोनों के लिए CSS का उपयोग करेंगे। _तो आम तौर पर केवल एक चीज जो अलग होगी वह है UI मार्कअप_। यहां तक ​​कि लेआउट से परिचित होना चाहिए क्योंकि हम अगले महीने फ्लेक्सबॉक्स लेआउट जारी कर रहे हैं। बाकी सब कुछ पुन: प्रयोज्य कोड है और सबसे महत्वपूर्ण पुन: प्रयोज्य कौशल है। टूलिंग भाग भी परिचित होना चाहिए क्योंकि नेटिवस्क्रिप्ट में हम क्रोम देवटूल का उपयोग कर रहे हैं ...

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

मेरा मानना ​​है कि यह एक बहुत ही सम्मोहक कहानी है और हम इसे बहुत जल्द तलाशेंगे और वास्तविक जीवन का उदाहरण दिखाएंगे। मुझे उम्मीद है कि वास्तविक कोड और वास्तविक ऐप को देखने से थोड़ा सा स्पष्ट करने में मदद मिलेगी कि यह खोज करने लायक है या नहीं।

किसी भी स्थिति में, अंतिम ऐप (या ऐप्स) हर जगह देशी UI के साथ होगा। और मुझे लगता है कि यही वह है जो इस समाधान को अद्वितीय और खोज के लायक बनाता है। हैक होना भी सस्ता है क्योंकि इलेक्ट्रॉन.जेएस और नेटिवस्क्रिप्ट दोनों पर कोई बदलाव करने की आवश्यकता नहीं है। इस पहले समाधान से शुरू होकर, हम ऐसे क्षेत्र खोज सकते हैं जहाँ अधिक सख्त सहयोग मौजूद हो सकता है।

मैंने कॉर्डोवा के साथ डेस्कटॉप और मोबाइल जीयूआई के लिए बहुलक का उपयोग किया है। कॉर्डोबा
डेस्कटॉप और मोबाइल का समर्थन करता है।

मेरे लिए कुंजी बाध्यकारी तकनीक के रूप में जीआरपीसी का उपयोग करना था। इसने इसे बहुत बनाया
आसान है क्योंकि क्लाइंट और सर्वर इंटरऑपरेट कर सकते हैं।

सभी के लिए मुझे बिचौलिए के रूप में कार्य करने के लिए बस एक जीआरपीसी प्रॉक्सी प्लगइन की आवश्यकता थी

शनिवार, 10 सितंबर 2016, 08:17 वैलेंटाइन स्टॉयचेव, नोटिफिकेशन @github.com . पर
लिखा था:

@hadees https://github.com/hadees हां, इसे लागू करने का विचार है
मोबाइल यूआई एक बार आईओएस और एंड्रॉइड के लिए नेटिवस्क्रिप्ट का उपयोग करके और एक बार डेस्कटॉप के लिए
इलेक्ट्रॉन का उपयोग करना। बाकी सब कुछ - डेटा, मॉडल, व्यावसायिक तर्क, सेवाएं,
डेटा एक्सेस समान होना चाहिए।

यहां दो बातें ध्यान देने योग्य हैं।

सबसे पहले, आप लगभग समान _skillset_ का उपयोग कर रहे होंगे (मतलब एक टीम कर सकती है
इलेक्ट्रॉनिक.जेएस और . के साथ निर्माण करते समय इसे डेस्कटॉप, वेब और मोबाइल के लिए बनाएं)
नेटिवस्क्रिप्ट - यह सभी जावास्क्रिप्ट/टाइपस्क्रिप्ट/सीएसएस है। आप कोणीय 2 . का उपयोग कर सकते हैं
यदि आप चाहते हैं। स्टाइल के लिए, आप नेटिवस्क्रिप्ट और . दोनों के लिए CSS का उपयोग करेंगे
इलेक्ट्रॉन। _तो आम तौर पर केवल एक चीज जो अलग होगी वह है UI
मार्कअप_. यहां तक ​​कि लेआउट से परिचित होना चाहिए क्योंकि हम फ्लेक्सबॉक्स जारी कर रहे हैं
अगले महीने लेआउट बाकी सब कुछ पुन: प्रयोज्य कोड है और सबसे महत्वपूर्ण बात
पुन: प्रयोज्य कौशल।

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

मेरा मानना ​​है कि यह एक बहुत ही सम्मोहक कहानी है और हम इसका पता लगाएंगे और
बहुत जल्द वास्तविक जीवन का उदाहरण दिखाएं। मुझे वास्तविक कोड देखने की उम्मीद है और
वास्तविक ऐप थोड़ा स्पष्ट करने में मदद करेगा कि यह खोज करने लायक है या नहीं।

किसी भी स्थिति में, अंतिम ऐप (या ऐप्स) हर जगह देशी UI के साथ होगा।
और मुझे लगता है कि यही वह है जो इस समाधान को अद्वितीय और खोज के लायक बनाता है। यह
हैक होना भी सस्ता है क्योंकि इसमें कोई बदलाव करने की आवश्यकता नहीं है
दोनों इलेक्ट्रॉन.जेएस और नेटिवस्क्रिप्ट। इस पहले समाधान से शुरू करते हुए, हम
ऐसे क्षेत्र मिल सकते हैं जहां अधिक सख्त सहयोग मौजूद हो सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/electron/electron/issues/562#issuecomment -246093147,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

नेटिवस्क्रिप्ट वास्तव में इलेक्ट्रॉन के मोबाइल समर्थन के लिए एक विकल्प नहीं है, क्योंकि
यह पूरी तरह से प्रतिमान को वेब तकनीक से दूर जावास्क्रिप्ट में बदल देता है
देशी विगेट्स के लिए बाइंडिंग। संक्षेप में, जो हमारे पास होगा वह अब नहीं होगा
"इलेक्ट्रॉन", क्योंकि इसके मूल में इलेक्ट्रॉन एक ब्राउज़र स्टैक है जो उजागर करता है
एक ब्राउज़र संदर्भ के Node.js _inside_, और यही इलेक्ट्रॉन बनाता है
इलेक्ट्रॉन।

नेटिवस्क्रिप्ट + नोड.जेएस बाइंडिंग को पूरी तरह से अलग समझा जा सकता है
परियोजना।

सबसे पहले, आप लगभग एक ही कौशल का उपयोग कर रहे होंगे (मतलब एक टीम इसे डेस्कटॉप, वेब और मोबाइल के लिए बना सकती है) इलेक्ट्रॉन.जेएस और नेटिवस्क्रिप्ट के साथ निर्माण करते समय - यह सभी जावास्क्रिप्ट/टाइपस्क्रिप्ट/सीएसएस है।

जरूरी नहीं कि सच हो, क्योंकि नेटिवस्क्रिप्ट के साथ आपके पास कुछ होना चाहिए
यह समझना कि देशी विजेट कैसे व्यवहार करते हैं, इस तथ्य की परवाह किए बिना कि
आप जावास्क्रिप्ट में कोडिंग कर रहे हैं। इसका मतलब है कि ज्ञान के बिना
विजेट, और उन विजेट बाइंडिंग को संशोधित करने के तरीके के ज्ञान के बिना
देशी कोड, फिर कुछ कस्टम करना बहुत मुश्किल हो जाता है, जो है
वेब स्टैक में शुद्ध JS/HTML/CSS के मामले में ऐसा नहीं है, क्योंकि वेब स्टैक के साथ
इंटर्नल को संशोधित करने का अर्थ है उसी प्रकार के कोड को उसी वातावरण में संशोधित करना जिसमें आप पहले से हैं, किसी विदेशी भाषा के बारे में चिंता करने की आवश्यकता नहीं है।

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

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

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

_/#!/_जोपिया

शुक्र, 9 सितंबर, 2016 को रात 11:17 बजे, वैलेंटाइन स्टोयचेव < नोटिफिकेशन @github.com

लिखा था:

@hadees https://github.com/hadees हां, इसे लागू करने का विचार है
मोबाइल यूआई एक बार आईओएस और एंड्रॉइड के लिए नेटिवस्क्रिप्ट का उपयोग करके और एक बार डेस्कटॉप के लिए
इलेक्ट्रॉन का उपयोग करना। बाकी सब कुछ - डेटा, मॉडल, व्यावसायिक तर्क, सेवाएं,
डेटा एक्सेस समान होना चाहिए।

यहां दो बातें ध्यान देने योग्य हैं।

सबसे पहले, आप लगभग समान _skillset_ का उपयोग कर रहे होंगे (मतलब एक टीम कर सकती है
इलेक्ट्रॉनिक.जेएस और . के साथ निर्माण करते समय इसे डेस्कटॉप, वेब और मोबाइल के लिए बनाएं)
नेटिवस्क्रिप्ट - यह सभी जावास्क्रिप्ट/टाइपस्क्रिप्ट/सीएसएस है। आप कोणीय 2 . का उपयोग कर सकते हैं
यदि आप चाहते हैं। स्टाइल के लिए, आप नेटिवस्क्रिप्ट और . दोनों के लिए CSS का उपयोग करेंगे
इलेक्ट्रॉन। _तो आम तौर पर केवल एक चीज जो अलग होगी वह है UI
मार्कअप_. यहां तक ​​कि लेआउट से परिचित होना चाहिए क्योंकि हम फ्लेक्सबॉक्स जारी कर रहे हैं
अगले महीने लेआउट बाकी सब कुछ पुन: प्रयोज्य कोड है और सबसे महत्वपूर्ण बात
पुन: प्रयोज्य कौशल।

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

मेरा मानना ​​है कि यह एक बहुत ही सम्मोहक कहानी है और हम इसका पता लगाएंगे और
बहुत जल्द वास्तविक जीवन का उदाहरण दिखाएं। मुझे वास्तविक कोड देखने की उम्मीद है और
वास्तविक ऐप थोड़ा स्पष्ट करने में मदद करेगा कि यह खोज करने लायक है या नहीं।

किसी भी स्थिति में, अंतिम ऐप (या ऐप्स) हर जगह देशी UI के साथ होगा।
और मुझे लगता है कि यही वह है जो इस समाधान को अद्वितीय और खोज के लायक बनाता है। यह
हैक होना भी सस्ता है क्योंकि इसमें कोई बदलाव करने की आवश्यकता नहीं है
दोनों इलेक्ट्रॉन.जेएस और नेटिवस्क्रिप्ट। इस पहले समाधान से शुरू करते हुए, हम
ऐसे क्षेत्र मिल सकते हैं जहां अधिक सख्त सहयोग मौजूद हो सकता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/electron/electron/issues/562#issuecomment -246093147,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

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

आपका ऐप उन सभी प्लेटफ़ॉर्म पर एक जैसा दिखता है, जहाँ से उपयोगकर्ता इसे एक्सेस कर सकता है, होल्ड करने के लिए एक बेहतर मानक है। उन्हें केवल अपने iPhone और Windows दोनों कार्य मशीन पर एक ऐप संचालित करने के लिए UI प्रतीकों और संकेतों के दो सेट सीखना भयानक है।

https://blog.chromium.org/2017/01/open-sourceing-chrome-on-ios.html

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

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

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

https://blog.chromium.org/2017/01/open-sourceing-chrome-on-ios.html

पहला बड़ा कदम? :]

लेकिन इसका कोई मतलब नहीं है क्योंकि क्रोमियम को सेब की दुकान पर रखने की अनुमति नहीं है।

लेकिन एंड्रॉइड में, अब इसकी बहुत जरूरत है।

कॉर्डोवा और डिफ़ॉल्ट वेबव्यू के साथ विकास करना नरक है, और इंटेल ने क्रॉसवॉक को खत्म कर दिया था, जो कि एंड्रॉइड के लिए डिफ़ॉल्ट वेबव्यू के रूप में क्रोमियम वेबव्यू का इंटेल पोर्ट है।
https://crosswalk-project.org/blog/crosswalk-final-release.html

समस्या:

• डिफ़ॉल्ट वेबव्यू अलग-अलग काम करने वाले विभिन्न विक्रेताओं के लिए अविश्वसनीय धन्यवाद है। यह एंड्रॉइड के 6.0 तक स्थिर नहीं है, जो कि केवल 20% फोन का उपयोग कर रहा है।
• हर कोई एंड्रॉइड फर्मवेयर या पैकेज अपडेट नहीं कर रहा है, खासकर बैंडविड्थ प्रतिबंधित क्षेत्रों में महंगे 3 जी के साथ।

हम क्या कर सकते हैं:

• इलेक्ट्रॉन एपीआई को क्रोम में पोर्ट करना असंभव है (जैसा कि @zcbenz ने 2014 में कहा था)
• एंड्रॉइड के लिए क्रोमियम और एंड्रॉइड के लिए क्रोमियम वेबव्यू अब पूरी तरह से खुला है: https://www.chromium.org/developers/how-tos/android-build-instructions
• हम क्रॉसवॉक को बनाए रखने के लिए कांटा और कोटिन्यू कर सकते हैं (जो मूल रूप से कम प्रतिबंधों के साथ एंड्रॉइड के लिए क्रोमियम का बंदरगाह है) https://github.com/crosswalk-project , यह पहले से ही काफी स्थिर है।
• हमारा अनुभव बताता है कि एक अच्छे जेएस फ्रेमवर्क के साथ क्रॉसवॉक और कॉर्डोवा नियर-नेटिव पेफॉर्मेंस (एम्बरज / रिएक्ट / एंगुलर / वीयू) देता है।
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

हमें क्रॉसवॉक में योगदानकर्ताओं और अनुरक्षकों की आवश्यकता है, जो वह हो सकता है जिसे आप ढूंढ रहे हैं।

अच्छी खबर

प्रासंगिक समाचार, @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/ द्वारा iOS के लिए Node.js का नया पोर्ट

इसलिए एकमात्र प्रयास जो करने की आवश्यकता होगी वह यह सुनिश्चित करने के लिए है कि मोबाइल ब्राउज़र इलेक्ट्रॉन का समर्थन करते हैं यदि @mikeal द्वारा पोस्ट किए गए लिंक के माध्यम से अनुकरण किया जाता है?

क्या आजकल अन्य JS VMs को iOS पर शिप करना कानूनी है? या क्या Apple को अभी भी आपको उनका उपयोग करने की आवश्यकता है?

@trusktr शिपिंग वीएम जो निष्पादन योग्य कोड उत्पन्न नहीं करते हैं, ऐप स्टोर दिशानिर्देशों का उल्लंघन नहीं करते हैं। हमने पहले भी ऐप स्टोर में इस तरह के ऐप को मंजूरी दे दी है (हालांकि स्पाइडरमॉन्की का उपयोग करते हुए और चक्रकोर का नहीं)।

क्या हम इस मुद्दे को फिर से खोल सकते हैं ताकि भविष्य में एक समर्थित मोबाइल फ्रेमवर्क पर चर्चा जारी रखी जा सके?

मैं इसे अपनी सहमति देता हूँ। क्या करने की जरूरत है? मुझे थोड़ी सी दिशा के साथ इस पर परीक्षण या हैकिंग शुरू करने में खुशी हो रही है।

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

@OtterCode और मेरी रुचि रखने वाले किसी भी व्यक्ति ने https://github.com/gabrielcsapo/electron-mobile बनाया है, अगर किसी को दिलचस्पी है तो मैं आपको एक मालिक के रूप में जोड़ सकता हूं और हम आईओएस और एंड्रॉइड बिल्ड के लिए आगे के रास्ते पर काम करना शुरू कर सकते हैं। इलेक्ट्रॉन के लिए लक्ष्य।

सैमसंग डेक्स जैसे उत्पाद, http://www.samsung.com/global/galaxy/apps/samsung-dex/
इसे एक व्यवहार्य अनुरोध IMO बनाएं (कम से कम Android के लिए)।

यह निश्चित रूप से बहुत करने योग्य है। उदाहरण के लिए, Google Play से एप्लिकेशन "टर्मक्स", हमें ऐप में एक संपूर्ण डेबियन-आधारित टर्मिनल देता है। हम apt-get install जो कुछ भी हमें चाहिए (नोड, विम, गिट, आदि, जब तक हम जो चीज स्थापित कर रहे हैं वह डिवाइस के सीपीयू आर्किटेक्चर का समर्थन करता है) कर सकते हैं। टर्मक्स के समान इलेक्ट्रॉन को अपने स्वयं के ऐप-सैंडबॉक्स वाले वातावरण में चलाना पूरी तरह से संभव है।

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

हम अपने ब्राउज़र में Node.js ऐप खोल सकते हैं, लोकलहोस्ट पर, टर्मक्स में से ही परोसे जाते हैं।

इलेक्ट्रॉन के साथ ऐसा कुछ करना निश्चित रूप से संभव है।

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

प्रतिक्रिया-मूल इस समस्या का स्थायी समाधान नहीं है

@aprilmintacpineda क्या आपने पहले से ही प्रगतिशील वेब ऐप्स पर ध्यान दिया है? https://developers.google.com/web/progressive-web-apps/

@ सेरकन-डेवेल हां मेरे पास है, जब मैंने इस मुद्दे को यहां देखा तो मुझे प्रगतिशील वेब ऐप्स के बारे में पता नहीं था। मैंने इसके बजाय प्रतिक्रिया-मूल का उपयोग करने का निर्णय लिया।

@aprilmintacpineda आप अभी भी PWA को आजमा सकते हैं, https://youtube.com/watch?v=vhg01Ml-8pI । यह डेस्कटॉप पर भी मदद करता है

क्रोमियम के साथ नोडज-मोबाइल को कोई कैसे एकीकृत करता है? यह एक ब्राउज़र वातावरण में Node को मोबाइल पर लाने के लिए निकटतम समाधान की तरह लगता है, जैसा कि इलेक्ट्रॉन ने डेस्कटॉप के लिए किया है।

(मुझे पता है कि पीडब्लूए आज क्या कर सकते हैं , और वेब ऐप्स को मोबाइल ऐप्स में लपेटने के लिए कॉर्डोवा जैसे ढांचे हैं, लेकिन पीडब्लूए ओएस-स्तरीय फाइल सिस्टम तक नहीं पहुंच सकते हैं या HTTP सर्वर एम्बेड नहीं कर सकते हैं, और कॉर्डोवा सिर्फ एक ओवरकिल है मेरे वर्तमान प्रोजेक्ट के लिए, एंड्रॉइड और आईओएस दोनों के लिए सेटअप और निर्माण प्रक्रियाओं का उल्लेख नहीं करना।)

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

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

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

निशान

https://github.com/dna2github/dna2oslab

नोडज जो एंड्रॉइड पर अच्छा काम कर सकते हैं

यह बिल्कुल इलेक्ट्रॉन की तरह नहीं है, लेकिन जो कोई भी Node.js के साथ एंड्रॉइड ऐप बनाना चाहता है, उसके लिए यह लाइब्रेरी मेरे परीक्षण में अच्छी तरह से काम करती है।