Electron: دعم المحمول

أعتقد أن atom-shell كان مصممًا بشكل أساسي لمحرر نصوص atom ، لذلك لا أتوقع أنه يدعم منصات الأجهزة المحمولة. هناك Phonegap و Cordova لتطبيقات الجوال HTML5.

نعم ، ولكن الأمر يتعلق بمشاركة التعليمات البرمجية من وحدات node.js والوصول إلى الموارد منخفضة المستوى

بالنسبة لمنصة الأجهزة المحمولة ، لا تنطبق جميع واجهات برمجة التطبيقات الخاصة بـ atom-shell تقريبًا ، لذلك لا أعتقد أننا سندعم الأنظمة الأساسية للجوّال على الإطلاق.

ربما يمكنكم على الأقل اللعب بشكل جيد مع كوردوفا ، وما إلى ذلك ، عن طريق (بطريقة ما) اكتشاف البيئة (في وقت التشغيل ، أو تحديدها أثناء البناء) بحيث تقوم واجهات برمجة تطبيقات Electron ببساطة باستدعاء وحدات كوردوفا (أو الكود الأصلي) دون علمنا. سيكون ذلك رائعا بجنون.

+1 trusktr

trusktr يبدو وكأنه وحدة رائعة تابعة لجهة خارجية من شأنها أن توفر حشوات توافق لـ Cordova

وأنا آمل حقا يحدث هذا. أعتقد أن مستقبل منصة الويب يجب أن يتحرك في هذا الاتجاه ، حتى نتمكن من كتابة تطبيقات عبر الأنظمة الأساسية حقًا. آمل حقًا ألا يتم استبعاد هذا.

لا أصدق أنه 2016 بالفعل ولا يوجد شيء من هذا القبيل حتى الآن.

@ emin93 هذا ليس بنّاءً ، كما سبق أن أوضحهzcbenz ، سيكون من المستحيل تقريبًا نقل واجهات برمجة التطبيقات الإلكترونية إلى الهاتف المحمول.
لا يمكنك طلب ميزات بدون على الأقل نوع من الاقتراحات حول كيفية تحقيق ذلك.

YuriSolovyov أنا لا أشير إلى إلكترون مباشرة. لا توجد بدائل في الواقع وهذا ما يجعلني أشعر بالإحباط. لكن نعم ، أنت على حق ، هذا في الواقع ليس المكان المناسب لمناقشة ذلك.

سيكون الإلكترون للجوال رائعًا جدًا. لدي عدد قليل من تطبيقات Electron التي تم تطويرها وأحب إطار العمل ولكن كل يوم أتمنى أن نراه يعمل على الهاتف المحمول أيضًا.

إطار العمل الوحيد عبر النظام الأساسي الذي يُظهر دعمًا شاملاً للمنصات (IOS ، Android ، Windows ، OSX ، Linux) هو Xamarin ولكنه يتطلب رمزًا في C #. لن أتفاجأ إذا سمح Xamarin برمز JS قريبًا لأن Microsoft تمتلك الآن Xamarin وخطت أيضًا خطوات كبيرة في نقل العقدة إلى محرك JS الخاص بها.

آمل حقًا أن يتمكن بعض الرعاة من الشركات من الانضمام إلى هذا المنفذ لتمويل مثل هذا المنفذ / مفترق الإلكترون للجوال والذي سيتم أخيرًا في نفس الإطار حتى نتمكن من الحصول على إطار عمل تطوير تطبيق عبر النظام الأساسي بالكامل يعتمد على JS.

شكرا لفريق Electron لعملك الرائع!

مرددًا السؤال الأصلي من cjfromthesea ، هل يمكن لشخص ما أن يشرح المشاكل الموجودة مع واجهات برمجة تطبيقات Electron على الهاتف المحمول (ربماzcbenz)؟ مع بعض التوجيهات العامة ، يمكن أن أبدأ أنا والآخرين في التفكير في طرق للتغلب على المشاكل عن طريق القرصنة والعبث. لقد تعاملت مع jxcore-cordova قليلاً ، لكن بعض الإرشادات ستكون لطيفة. ما هي الحواجز؟

lastmjs من العوائق الضخمة أن Electron تستخدم V8 وهو غير مدعوم على iOS. هذا يعني أن Chromium و Node.js لن يعملوا أيضًا على نظام التشغيل iOS وهذه المكونات الثلاثة هي المكونات الرئيسية للإلكترون.

تم إصدار إصدار جديد من الكروم لـ IOS في كانون الثاني (يناير) ، ويمكن لتطبيق node.app أن يفي بالغرض مع node.js. ولا ينبغي أن يكون Android مشكلة نظرًا لأن V8 مدعوم.
في غضون ذلك ، يمكننا كتابة وثائق حول كيفية استخدام كوردوفا مع الإلكترون لـ IOS (لأنني أحتاجها حقًا ، وسأكون سعيدًا بالمساعدة).

noelmace Chrome لنظام التشغيل iOS لا يستخدم محرك Chromium لأن Apple لا تسمح بذلك. إنه مجرد WKWebView مثل Safari يستخدمه ، ولكن مع واجهة مستخدم مختلفة.

@ emin93 هل تطبيق يسمح باستخدام أي مترجم مخصص مثل node.app؟

كان لدي بعض الأسئلة التي أحب التفكير فيها من أولئك الموجودين في هذا الموضوع -

• هل تتطلع إلى إنشاء تطبيق واحد يعمل في كل مكان؟
  
  
  
  • سؤال المتابعة ، هل هناك أمثلة لتطبيقات سطح المكتب (ليست تطبيقات ويب) وهي أيضًا تطبيقات جوال؟
  
  
• أم أنك تبحث عن تجربة إنشاء تطبيق Electron ولكن على الهاتف المحمول؟
  
  
  
  • سؤال المتابعة ، كيف سيختلف ذلك عن Cordova / PhoneGap (أو غيرهما)؟
  
  

أنا بالتأكيد أبحث عن تطبيق واحد يمكن تشغيله في كل مكان. قاعدة بيانات واحدة ، منصة ويب واحدة ، أي بيئة.

أمثلة على تطبيقات الجوال / سطح المكتب / الويب الجيدة ، حيث لا يهم حجم الشاشة والجهاز حقًا ، ولكنك قد ترغب في نفس الوظيفة:

• كروم
• ثعلب النار
• تثاقل
• بريد جوجل
• صور جوجل
• خرائط جوجل

لا تحتوي جميع التطبيقات المذكورة أعلاه بالضرورة على إصدار سطح مكتب يعمل مع ملف تنفيذي أصلي ، ولكن لديهم إصدار سطح مكتب في المتصفح. بالنسبة لي ، يعتمد الأمر بالطبع على كل حالة على حدة ، ولكن بشكل عام أريد أن يكون تطبيقي هو تطبيقي بغض النظر عن الجهاز الذي يعمل عليه. أسعى للحصول على نفس الميزات عبر جميع الأجهزة قدر الإمكان. لما لا؟ أريد أن يعمل Chrome بنفس الطريقة على سطح المكتب كما هو الحال على جهاز Android أو iPhone أو الجهاز اللوحي ، كما هو الحال مع Firefox و Slack وخرائط Google. أجد أنه من المحزن أن تكون ميزات خرائط Google في بعض الأحيان خاصة بالنظام الأساسي. بالعودة إلى Chrome ، أريد أن أكون قادرًا على عرض المصدر وحتى استخدام مصحح الأخطاء ، حتى على هاتفي. أعتقد أحيانًا أننا لا نملك البصيرة للحد من وظائف تطبيقاتنا بشكل مناسب. ماذا لو أراد شخص ما ميزة تعمل على إصدار سطح المكتب من التطبيق على هاتفه؟ يجب أن تكون التطبيقات سريعة الاستجابة بالطبع ، ولكن يجب أن تظل الوظائف الأساسية كما هي قدر الإمكان في رأيي.

lastmjs شكرا. لقد قمت للتو بتحرير سؤالي لأن ما كنت أفكر فيه ، ولكن لم أحدده ، كان تطبيقات سطح المكتب التي هي أيضًا تطبيقات للهاتف المحمول ولكنها ليست تطبيقات ويب. أعتقد أن هذا تمييز مهم.

ولكن يجب أن تظل الوظائف الأساسية كما هي قدر الإمكان في رأيي

التفكير بصوت عالٍ هنا: تنشئ Electron واجهة برمجة تطبيقات لسلوكيات تطبيقات سطح المكتب الأصلية الشائعة - يبدو أنه إذا أضفت أيضًا في الهاتف المحمول ، فإن الأرضية المشتركة بين كل هذه الأمور ستتقلص. قد يعمل التطبيق المستند إلى الأرضية المشتركة بين سطح المكتب والجوّال في نهاية المطاف في كل مكان ، ولكنه يكون تجربة هاتف محمول دون المستوى وتجربة سطح مكتب دون المستوى؟

هل سلوكيات تطبيقات سطح المكتب المحلية الشائعة التي تتحدث عنها تعتمد في الغالب على واجهة المستخدم؟ أستطيع أن أرى كيف قد لا تُترجم القوائم الأصلية والسلوكيات الأخرى بشكل جيد. أكبر فائدة بالنسبة لي هي الحصول على وقت تشغيل واحد موحد ، حيث يمكنني الوصول إلى Node.js و Chromium API's ، وقول إن وقت التشغيل قابل للنشر على جميع الأنظمة الأساسية الرئيسية. تقوم Electron و Cordova بطريقة ما بفعل الشيء نفسه لمنصات مختلفة ، باستثناء وظائف واجهة المستخدم التي ربما كنت تتحدث عنها. مع كوردوفا ، لديك قاعدة بيانات واحدة يمكن نشرها على عدد قليل من أنظمة تشغيل الهواتف المحمولة الرئيسية ، كما ذكرنا أن أنظمة تشغيل الأجهزة المحمولة لا تختلف كثيرًا في الوظائف عن أنظمة تشغيل سطح المكتب الرئيسية. يدير نظام التشغيل العمليات ومواردها ، ويمنح الوصول إلى الأجهزة التي قد تحتاجها العمليات. لا يوجد فرق جوهري كبير بين أنظمة تشغيل الأجهزة المحمولة وسطح المكتب. ومع بداية امتلاك المتصفحات لواجهات برمجة التطبيقات للأجهزة ، أصبحت منصة الويب أكثر عالمية في قدرتها على النشر في جميع البيئات الرئيسية. لذا كما أراها ، فإن كوردوفا وإلكترون ينجزان إلى حد كبير نفس المهام ولكن على أنظمة تشغيل مختلفة ، وقال إن أنظمة التشغيل لا تختلف اختلافًا جوهريًا ، فلماذا لا يتم الجمع بينهما؟ 😃

تضمين التغريدة

أُنشئ للجوال وسطح المكتب وأود أن أضيف إلى التعليقات من lastmrs و noelmace

ها هي أفكاري حول كيف يمكن أن تعمل مع الجميع.

يجب أن تختلف واجهة برمجة التطبيقات التي يعرضها الإلكترون بناءً على ما إذا كانت محمولة أو سطح مكتب. لذلك ، تقع على عاتق المطور مسؤولية اكتشاف بيئة وقت التشغيل (التي توفرها طبقة الإلكترون) لاستدعاء واجهة برمجة تطبيقات مختلفة وفقًا لسياق البيئة.
مرة أخرى للتوضيح ، الأمر متروك للمطور لفعل الشيء الصحيح

فيما يتعلق بجوانب واجهة المستخدم ، يعود الأمر مرة أخرى إلى المطور للقيام بالشيء الصحيح. أنا أستخدم البوليمر لجميع مشاريعي المكتبية والمحمولة ، والأمر متروك لي للقيام بذلك بشكل صحيح.
أستخدم أيضًا golang لكتابة أي أشياء مجمعة أحتاجها على سطح المكتب والجوال للوصول إلى أي جهاز.

في وقت الإنشاء ، أقوم بحزمه لسطح المكتب (amd 64 ، إلخ ، إلخ) والجوّال (android أو iOS) حيث أقوم بإنشاء حزمة منفصلة لكل نظام تشغيل وبنية شريحة. أفعل نفس الشيء مع الإلكترون. هذا يسمح لي بتجميع فروق التوقيت كما أحتاجها لأن بعض الأكواد تعتمد على الأجهزة.
لا يزال بإمكاني تضمين نفس الكود في جميع الإنشاءات والقيام باستنشاق وقت التشغيل ، وهذا هو المكان الذي سيوفر لي الإلكترون سياق البيئة.

إن الشيء العظيم الذي يوفره هذا هو الأدوات الشائعة في وقت التصميم ووقت الترجمة. يعد هذا تحسينًا كبيرًا للإنتاجية للمطورين لأنه يمكنك تثبيت الإلكترون وتشغيل برنامج نصي bootstrap bash لتثبيت بتات iOS و android وكتابة عالم الترحيب والتعبئة والنشر على سطح المكتب والجوال.

لم أكن أعلم أن فريق Google قد قام بتحديث Chrome لنظام iOS ليكون متعدد العمليات. أنا متحمس للغاية لرؤية هذا.

إذا كان بإمكاني المساعدة في أي من هذا ، فسأقوم بكل سرور بالمساعدة.

سيكون هذا تحسينًا كبيرًا للعديد من مشاريعي أيضًا. سيتعين على المرء بالفعل إجراء تغييرات على واجهة المستخدم بناءً على ما إذا كان محمولًا أم لا ، وقد يقوم أيضًا بأي اكتشاف / تغييرات أخرى أيضًا.

لا أعتقد أن وجود واجهتي API منفصلتين فكرة جيدة (@ joeblew99). بالنسبة للمستخدم النهائي ، أعتقد أنه سيكون من الأفضل أن تجعل Electron واجهات برمجة التطبيقات الخاصة بها تعمل أعلى كوردوفا أو Node ، بحيث يحتاج المستخدم النهائي فقط إلى معرفة API واحد (Electron API). ثم إذا لم يتم تغطية شيء ما بواسطة API ، فيمكن للمستخدمين النهائيين الغوص في Node أو Cordova حسب الحاجة.

أيضًا ، أعتقد أنه سيكون من المهم للإلكترون تحديد كيفية استخدام سير عمل NPM الذي يعمل في كلتا الحالتين (كوردوفا أو مباشرة على العقدة). أي ، سيتعين على Electron تحديد نظام البناء الخاص به ليكون متوافقًا مع كليهما ، باستخدام NPM (وستفيد وحدات ES6 أيضًا) حتى لا يضطر المستخدمون النهائيون إلى القلق بشأن كيفية البناء لكل منهما. من الواضح أنه تم التعامل مع حالة Node بالفعل ، ولكن قد تكون هناك حاجة إلى مزيد من العمل حتى يعمل NPM بشكل جيد في Cordova.

لاحظ أنه في Cordova Node.js APIs غير متوفرة ، لذلك سيحتاج Electron إلى ملء بعض وحدات Node.js الأصلية ببدائل تعمل في كوردوفا ، على غرار ما يفعله Browserify للمتصفح. سيساعد هذا في إنشاء واجهة برمجة تطبيقات موحدة ، لأنه إذا كان هناك شيء لا تغطيه Electron API ، فعندئذٍ على الأقل تعني libs متعددة التعبئة أنه يمكن للمستخدم الرجوع إلى واجهات برمجة التطبيقات المستندة إلى Node والتي تستدعي وراء الكواليس واجهات برمجة تطبيقات كوردوفا.

إن الحاجة إلى polyfill هي بالضبط ما أعتقد أنه من الأفضل البدء بمسار API. ليس من الضروري أن تكون واجهة برمجة تطبيقات منفصلة ، فقط بعض الميزات غير متوفرة على الفور. إذا قمت بإجراء ذلك وجعلته متوافقًا بنسبة 100٪ ، فسيكون التعامل معه أكبر بكثير عند إضافة ميزات جديدة في المستقبل.

أود أيضًا أن أشير إلى أن Android و IOS لم يعدا مجرد أجهزة محمولة بعد الآن. سيبدو المشروع الذي أعمل عليه رائعًا على جهاز Android TV ، بالإضافة إلى أنني لا أفهم سبب عدم رغبة Github في تشغيل Atom على أجهزة التلفزيون أو الأجهزة اللوحية.

نقطة مهمة ، لم يعد الأمر يتعلق بحجم الشاشة ، لقد بدأنا في التعامل مع أنظمة تشغيل للأغراض العامة.

أنا في حيرة من أمري فيما يتعلق بحالة Electron على Android؟

هل هو شيء يتم التفكير فيه بنشاط أم مجرد شيء يتم الحديث عنه؟

جعل تطبيقات Electron هدفًا صالحًا لتطبيقات PhoneGap أو Cordova أسهل بنحو 1000 مرة!
بمعنى آخر. cordova platform add electron-osx electron-win electron-linux

purplecabbage بالتأكيد ولكنك ستفقد بعد ذلك جميع الفوائد الإضافية للتحكم في حزمة المتصفح بالكامل.

RE: Node.js Polyfills.

يجب أن نبدأ قائمة من polyfills _ الأصلية المطلوبة لكي يعمل هذا. يحتوي Browserify بالفعل على إصدارات ويب خالصة من _lot_ من Node.js Core. الأشخاص الوحيدون الذين يمكنني التفكير في أننا سنحتاجهم هم:

• dns
• net
• fs

هل من شيء آخر؟

كائنات عالمية:

• __dirname
• __اسم الملف
• معالجة

purplecabbage يبدو أن هؤلاء الثلاثة لديهم تطبيقات browserify. https://github.com/substack/browserify-handbook#__dirname. هل يجب أن نعطيهم قيمًا مختلفة بناءً على الأجهزة؟

نعم ، __dirname و __filename ليسا من الأشياء الكبيرة.
العملية مجردة في المتصفح ، ألا نريد دعم الأحداث؟
https://github.com/defunctzombie/node-process/blob/master/browser.js

بالنسبة إلى كود مشاركة تطبيقات Native Mobile مع electron.js ، أعتقد أن الأفضل هو استكشاف المسار من خلال الجمع بين Electron.js و NativeScript - http://github.com/NativeScript/NativeScript.

نحن (فريق NativeScript) نخطط لإنشاء نموذج تطبيق تجريبي ، إذا كنت مهتمًا ، فيرجى التعليق على هذه المشكلة - https://github.com/NativeScript/NativeScript/issues/2695

في الواقع ، هناك بالفعل البذور المتقدمة Angular 2 المتاحة والتي تتيح ذلك - https://github.com/NathanWalker/angular2-seed-advanced. لكن الزاوية 2 ليست بأي حال من الأحوال مطلبًا لتنفيذ مثل هذا النوع من الحلول.

هل هذا شيء منطقي؟

أعتقد أن الشيء الرئيسي هو أن فريقك قد أنجز العمل الأساسي لإضافة واجهات برمجة التطبيقات الأصلية. أنا جميعًا مع فكرتك.

valentinstoychev هذه فكرة مثيرة للاهتمام حقًا على الرغم من أنها تعني أساسًا أن أي تطبيقات إلكترونية ستضطر إلى إعادة واجهة المستخدم بالكامل ، أليس كذلك؟ سيكون من المثير للاهتمام حقًا أن تقوم بطريقة ما بتضمين libchromiumcontent لإنشاء webview مشابه لـ electron . بعد ذلك سيكون من الأسهل استخدام كليهما في تطبيق واحد.

ماذا عن عنصر واجهة مستخدم Android WebView وما يعادله على iOS؟ في الواقع ، Android one هو بالفعل chromium. :)

hadees نعم ، الفكرة هي تنفيذ واجهة مستخدم الهاتف المحمول مرة واحدة لنظامي التشغيل iOS و Android باستخدام NativeScript ومرة ​​واحدة لسطح المكتب باستخدام الإلكترون. كل شيء آخر - يجب أن تكون البيانات والنماذج ومنطق الأعمال والخدمات والوصول إلى البيانات هي نفسها.

هناك شيئان يجب ملاحظتهما هنا.

أولاً ، ستستخدم مجموعة المهارات نفسها تقريبًا (مما يعني أن فريقًا واحدًا يمكنه صنعها لسطح المكتب والويب والجوال) عند الإنشاء باستخدام electron.js و NativeScript - إنها كلها JavaScript / TypeScript / CSS. يمكنك استخدام Angular 2 إذا أردت. بالنسبة إلى التصميم ، ستستخدم CSS لكل من NativeScript والإلكترون. _بشكل عام ، الشيء الوحيد الذي سيكون مختلفًا هو ترميز واجهة المستخدم_. حتى التصميم يجب أن يكون مألوفًا لأننا نطلق تخطيط FlexBox الشهر المقبل. كل شيء آخر هو رمز قابل لإعادة الاستخدام والأهم من ذلك مجموعة مهارات قابلة لإعادة الاستخدام. يجب أن يكون جزء الأدوات مألوفًا أيضًا كما هو الحال في NativeScript حيث نستخدم Chrome Devtools ...

الشيء الثاني الذي يجب ملاحظته هنا هو أنك تريد بالفعل أن يكون لديك واجهة مستخدم مختلفة للجوال وسطح المكتب ، صحيح. لذلك ، في كثير من الحالات ، لن يتم إعادة استخدام جزء واجهة المستخدم على أي حال ويجب أن يكون مختلفًا.

أعتقد أن هذه قصة مقنعة للغاية وسوف نستكشفها ونعرض مثالًا من الحياة الواقعية قريبًا جدًا. آمل أن تساعد رؤية الكود الفعلي والتطبيق الفعلي في توضيح بعض الشيء إذا كان الأمر يستحق الاستكشاف أم لا.

على أي حال ، سيكون التطبيق النهائي (أو التطبيقات) مع واجهة مستخدم أصلية في كل مكان. وأعتقد أن هذا ما يجعل هذا الحل فريدًا ويستحق الاستكشاف. كما أنه من السهل اختراقها لأنه لا توجد تغييرات يلزم إجراؤها على كل من electron.js و NativeScript. بدءًا من هذا الحل الأول ، قد نجد مناطق يمكن أن يوجد فيها تعاون أكثر إحكامًا.

لقد استخدمت البوليمر لسطح المكتب والجهاز المحمول واجهة المستخدم الرسومية ، مع كوردوفا. كوردوفا
يدعم سطح المكتب والجوال.

كان المفتاح بالنسبة لي هو استخدام grpc كتقنية ملزمة. هذا جعلها كثيرا
أسهل لأن العملاء والخوادم يمكنهم التعامل مع بعضها البعض.

للجميع ، كنت فقط بحاجة إلى مكون إضافي وكيل grpc ليكون بمثابة وسيط

يوم السبت ، 10 سبتمبر 2016 ، الساعة 08:17 فالنتين ستويشيف ، [email protected]
كتب:

hadees https://github.com/hadees نعم ، الفكرة هي تنفيذ
واجهة مستخدم للجوال مرة واحدة لنظامي التشغيل iOS و Android باستخدام NativeScript ومرة ​​واحدة لسطح المكتب
باستخدام الإلكترون. كل شيء آخر - البيانات والنماذج ومنطق الأعمال والخدمات ،
يجب أن يكون الوصول إلى البيانات هو نفسه.

هناك شيئان يجب ملاحظتهما هنا.

أولاً ، ستستخدم نفس _المهارات_ تقريبًا (يعني أن فريقًا واحدًا يمكنه ذلك
اجعلها لأجهزة سطح المكتب والويب والجوال) عند الإنشاء باستخدام electron.js و
NativeScript - كل شيء هو JavaScript / TypeScript / CSS. يمكنك استخدام Angular 2
إذا تحب. بالنسبة إلى التصميم ، ستستخدم CSS لكل من NativeScript و
إلكترون. _ لذلك بشكل عام الشيء الوحيد الذي سيكون مختلفًا هو واجهة المستخدم
وضع علامة على_. حتى التصميم يجب أن يكون مألوفًا لأننا نطلق FlexBox
التخطيط الشهر المقبل. كل شيء آخر هو رمز قابل لإعادة الاستخدام والأهم من ذلك
مجموعة المهارات القابلة لإعادة الاستخدام.

الشيء الثاني الذي يجب ملاحظته هنا هو أنك تريد حقًا أن يكون لديك اختلاف
واجهة المستخدم للجوال وسطح المكتب ، صحيح. لذلك ، في كثير من الحالات ، واجهة المستخدم
لن تتم إعادة استخدام الجزء على أي حال ويجب أن يكون مختلفًا.

أعتقد أن هذه قصة مقنعة للغاية وسوف نستكشفها و
اعرض مثالًا من الحياة الواقعية قريبًا جدًا. آمل أن أرى الكود الفعلي و
سيساعد التطبيق الفعلي في توضيح بعض الشيء إذا كان الأمر يستحق الاستكشاف أم لا.

على أي حال ، سيكون التطبيق النهائي (أو التطبيقات) مع واجهة مستخدم أصلية في كل مكان.
وأعتقد أن هذا ما يجعل هذا الحل فريدًا ويستحق الاستكشاف. هو - هي
تعتبر رخيصة أيضًا ليتم اختراقها نظرًا لعدم وجود تغييرات يلزم إجراؤها عليها
كل من electron.js و NativeScript. بدءًا من هذا الحل الأول ، نحن
قد تجد المجالات التي يمكن أن يوجد فيها تعاون وثيق.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/electron/electron/issues/562#issuecomment -246093147 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript ليس حقًا خيارًا لدعم الأجهزة المحمولة من Electron ، لأنه
إنه ينقل النموذج تمامًا بعيدًا عن تكنولوجيا الويب إلى JavaScript
الارتباطات للحاجيات الأصلية. في الجوهر ، ما كان لدينا لن يكون كذلك
"الإلكترون" ، لأن الإلكترون في جوهره عبارة عن مجموعة مستعرضات تكشف
Node.js _ داخل_ سياق المتصفح ، وهذا ما يجعل Electron
إلكترون.

يمكن اعتبار ارتباطات NativeScript + Node.js مختلفة تمامًا
المشروع.

أولاً ، ستستخدم مجموعة المهارات نفسها تقريبًا (مما يعني أن فريقًا واحدًا يمكنه صنعها لسطح المكتب والويب والجوال) عند الإنشاء باستخدام electron.js و NativeScript - إنها كلها JavaScript / TypeScript / CSS.

ليس بالضرورة صحيحًا ، لأنه مع NativeScript يجب أن يكون لديك بعض
فهم كيفية عمل عناصر واجهة المستخدم الأصلية ، بغض النظر عن حقيقة ذلك
أنت ترميز في JavaScript. هذا يعني أنه بدون علم
عناصر واجهة المستخدم ، وبدون معرفة كيفية تعديل ارتباطات عناصر واجهة المستخدم هذه مع
الكود الأصلي ، فإن القيام بشيء مخصص يصبح صعبًا للغاية ، وهو
ليس هذا هو الحال مع JS / HTML / CSS الخالص في مكدس الويب ، لأنه مع مكدس الويب
يعني تعديل العناصر الداخلية تعديل نفس النوع من التعليمات البرمجية في نفس البيئة التي تتواجد فيها بالفعل ، دون الحاجة إلى القلق بشأن لغة أجنبية.

الشيء الثاني الذي يجب ملاحظته هنا هو أنك تريد بالفعل أن يكون لديك واجهة مستخدم مختلفة للجوال وسطح المكتب ، صحيح. لذلك ، في كثير من الحالات ، لن يتم إعادة استخدام جزء واجهة المستخدم على أي حال ويجب أن يكون مختلفًا.

إحدى فوائد استخدام Electron (مع واجهته الأمامية المستندة إلى الويب) هي
أننا نكتب رمزًا واحدًا ، ويتصرف تقريبًا بنفس الطريقة
في كل مكان. لن يكون هذا هو الحال دائمًا مع NativeScript ، والذي
يحاول ربط مجموعات مختلفة تمامًا من التقنيات بلغة واحدة.

أنا شخصياً أحب فكرة استخدام واجهة مستخدم ويب في كل مكان ،
مقابل واجهات مستخدم أصلية مختلفة في كل مكان. يعتقد بعض الناس أن واجهات المستخدم الأصلية
أفضل بكثير من واجهات مستخدم الويب. هذا صحيح إلى حد ما ، وهذا هو الحال
مع المطورين الذين لا يعرفون الأساسيات الكاملة للويب. ولكن مع
الاستخدام السليم لواجهات برمجة تطبيقات الويب يمكننا في الواقع إنشاء واجهات مستخدم لطيفة. الويب يحقق أرباحًا ضخمة
تقدم. WebGL متعدد المنصات بشكل كبير ...

_ / #! / _ جوبي

يوم الجمعة ، 9 سبتمبر 2016 الساعة 11:17 مساءً ، Valentin Stoychev < [email protected]

كتب:

hadees https://github.com/hadees نعم ، الفكرة هي تنفيذ
واجهة مستخدم للجوال مرة واحدة لنظامي التشغيل iOS و Android باستخدام NativeScript ومرة ​​واحدة لسطح المكتب
باستخدام الإلكترون. كل شيء آخر - البيانات والنماذج ومنطق الأعمال والخدمات ،
يجب أن يكون الوصول إلى البيانات هو نفسه.

هناك شيئان يجب ملاحظتهما هنا.

أولاً ، ستستخدم نفس _المهارات_ تقريبًا (يعني أن فريقًا واحدًا يمكنه ذلك
اجعلها لأجهزة سطح المكتب والويب والجوال) عند الإنشاء باستخدام electron.js و
NativeScript - كل شيء هو JavaScript / TypeScript / CSS. يمكنك استخدام Angular 2
إذا تحب. بالنسبة إلى التصميم ، ستستخدم CSS لكل من NativeScript و
إلكترون. _ لذلك بشكل عام الشيء الوحيد الذي سيكون مختلفًا هو واجهة المستخدم
وضع علامة على_. حتى التصميم يجب أن يكون مألوفًا لأننا نطلق FlexBox
التخطيط الشهر المقبل. كل شيء آخر هو رمز قابل لإعادة الاستخدام والأهم من ذلك
مجموعة المهارات القابلة لإعادة الاستخدام.

الشيء الثاني الذي يجب ملاحظته هنا هو أنك تريد حقًا أن يكون لديك اختلاف
واجهة المستخدم للجوال وسطح المكتب ، صحيح. لذلك ، في كثير من الحالات ، واجهة المستخدم
لن تتم إعادة استخدام الجزء على أي حال ويجب أن يكون مختلفًا.

أعتقد أن هذه قصة مقنعة للغاية وسوف نستكشفها و
اعرض مثالًا من الحياة الواقعية قريبًا جدًا. آمل أن أرى الكود الفعلي و
سيساعد التطبيق الفعلي في توضيح بعض الشيء إذا كان الأمر يستحق الاستكشاف أم لا.

على أي حال ، سيكون التطبيق النهائي (أو التطبيقات) مع واجهة مستخدم أصلية في كل مكان.
وأعتقد أن هذا ما يجعل هذا الحل فريدًا ويستحق الاستكشاف. هو - هي
تعتبر رخيصة أيضًا ليتم اختراقها نظرًا لعدم وجود تغييرات يلزم إجراؤها عليها
كل من electron.js و NativeScript. بدءًا من هذا الحل الأول ، نحن
قد تجد المجالات التي يمكن أن يوجد فيها تعاون وثيق.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/electron/electron/issues/562#issuecomment -246093147 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

trusktr أنا أتفق بصدق. أعتقد أن المطورين يضعون الكثير من المخزون في البحث عن المحتوى الأصلي. Native ليس حتى مثاليًا ثابتًا. في العقد الماضي ، تغيرت واجهات الهاتف المحمول عشرات المرات ، ولم تعد متسقة حتى من هاتف android إلى آخر.

إن جعل تطبيقك يبدو متسقًا عبر جميع الأنظمة الأساسية التي يمكن للمستخدم الوصول إليها من خلالها يعد معيارًا أفضل بكثير ليحتفظ به. إن جعلهم يتعلمون مجموعتين من رموز وإشارات واجهة المستخدم لمجرد تشغيل تطبيق على كل من أجهزة iPhone و Windows الخاصة بهم أمر فظيع.

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

تاريخيًا ، تم الاحتفاظ برمز Chrome لنظام iOS منفصلاً عن باقي مشروع Chromium نظرًا للتعقيد الإضافي المطلوب للنظام الأساسي. بعد سنوات من إعادة البناء بعناية ، فإن كل هذه التعليمات البرمجية تنضم مجددًا إلى Chromium ويتم نقلها إلى مستودع مفتوح المصدر.

نظرًا لقيود نظام iOS الأساسي ، يجب إنشاء جميع المتصفحات أعلى محرك عرض WebKit. بالنسبة إلى Chromium ، يعني هذا دعم كل من WebKit وكذلك Blink ، محرك عرض Chrome للأنظمة الأساسية الأخرى. أدى ذلك إلى بعض التعقيدات الإضافية التي أردنا تجنب وضعها في قاعدة رمز Chromium.

نظرًا لالتزام Chrome بالشفرة مفتوحة المصدر ، فقد أمضينا الكثير من الوقت على مدار السنوات العديدة الماضية في إجراء التغييرات المطلوبة لنشر شفرة Chrome لنظام iOS في Chromium. اليوم ، اكتمل هذا التحميل ، ويمكن للمطورين تجميع إصدار iOS من Chromium كما يفعلون للإصدارات الأخرى من Chromium. أصبحت سرعة التطوير أيضًا أسرع الآن حيث أن جميع اختبارات Chrome لنظام التشغيل iOS متاحة لمجتمع Chromium بأكمله ويتم تشغيلها تلقائيًا في أي وقت يتم فيه تسجيل الوصول.

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

أول خطوة كبيرة؟ :]

لكن هذا لا يعني شيئًا لأن الكروم غير مسموح بوضعه في متجر آبل.

ولكن في Android ، هناك حاجة ماسة إليه الآن.

التطوير باستخدام كوردوفا وعرض الويب الافتراضي هو الجحيم ، وقد ألغت شركة إنتل Crosswalk ، وهو منفذ Intel لعرض ويب الكروم كعرض ويب افتراضي لنظام Android.
https://crosswalk-project.org/blog/crosswalk-final-release.html

مشاكل:

• يعد عرض الويب الافتراضي غير موثوق به بفضل البائعين المختلفين الذين يقومون بأشياء مختلفة. فهو غير مستقر حتى الإصدار 6.0 من نظام Android ، والذي يستخدم 20٪ فقط من الهواتف.
• لا يقوم كل شخص بتحديث البرامج الثابتة أو الحزمة لنظام Android ، خاصة في المناطق المقيدة لعرض النطاق الترددي مع شبكة 3G باهظة الثمن.

ماذا نستطيع فعله:

• من المستحيل نقل واجهات برمجة التطبيقات الإلكترونية إلى الكروم (كما قالzcbenz في عام 2014)
• chromuim for android and chromium webview لنظام android مفتوح بالكامل الآن: https://www.chromium.org/developers/how-tos/android-build-instructions
• يمكننا مفترق الطرق و cotinue الحفاظ على العبور (وهو في الأساس منفذ الكروم إلى أندرويد مع قيود أقل) https://github.com/crosswalk-project ، إنه مستقر بالفعل.
• تُظهر تجربتنا أن ممر المشاة وكوردوفا مع إطار عمل JS جيد يعطي أداء شبه أصلي (Emberjs / React / Angular / Vue).
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

نحن بحاجة إلى مساهمين ومشرفين في معبر المشاة ، قد يكون هذا الشخص الذي تبحث عنه.

أخبار جيدة

الأخبار ذات الصلة ، منفذ جديد من Node.js إلى iOS بواسطة orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/

لذا فإن الجهد الوحيد الذي يجب القيام به هو التأكد من أن متصفحات الهاتف المحمول تدعم الإلكترون إذا تمت محاكاته عبر الرابط الذي نشره mikeal ؟

هل من القانوني شحن JS VMs الأخرى على iOS في الوقت الحاضر؟ أو هل ما زالت Apple تطلب منك استخدام ما لديهم؟

trusktr shipping VMs التي لا تنشئ رمزًا قابلاً للتنفيذ لا تنتهك إرشادات متجر التطبيقات. لقد حصلنا على مثل هذا التطبيق المعتمد في متجر التطبيقات من قبل (على الرغم من استخدام SpiderMonkey وليس ChakraCore).

هل يمكننا إعادة فتح هذه المشكلة لمواصلة النقاش حول ما إذا كان الإلكترون سيكون له إطار عمل متنقل مدعوم في المستقبل؟

أنا أؤيد هذا. ما الذي يجب القيام به؟ يسعدني أن أبدأ في اختبار هذا أو اختراقه بقليل من التوجيه.

OtterCode هل من المنطقي إنشاء ريبو يسمى المحمول الإلكتروني والبدء في القرصنة هناك؟ يمكنني أن أرى خطوة ضرورية للتخطيط والحصول على أمثلة للتطبيقات جاهزة للبدء في معرفة ما يجب القيام به. هل توجد مكتبة API ذات مستوى أعلى للإلكترون يمكننا محاكاتها للبدء؟ (مستندات Api ، إنشاء أهداف ، إلخ)

OtterCode وأي شخص مهتم قمت بإنشائه ، https://github.com/gabrielcsapo/electron-mobile ، إذا كان أي شخص مهتمًا يمكنني إضافتك كمالك ويمكننا البدء في العمل على مسار للأمام لنظام iOS و Android build أهداف للإلكترون.

منتجات مثل Samsung Dex ، http://www.samsung.com/global/galaxy/apps/samsung-dex/
اجعل هذا طلب IMO قابلاً للتطبيق (على الأقل لنظام Android).

هذا بالتأكيد ممكن جدا. على سبيل المثال ، يمنحنا تطبيق "Termux" من Google Play محطة قائمة على دبيان بالكامل في التطبيق. يمكننا apt-get install أي شيء نحتاجه (Node ، Vim ، Git ، إلخ ، طالما أن الشيء الذي نقوم بتثبيته يدعم بنية وحدة المعالجة المركزية للجهاز). من الممكن تمامًا تشغيل Electron في بيئة آلية التطبيق الخاصة بها المشابهة لـ Termux.

يعمل Termux بدون تجذير هواتفنا ، ويقوم بتثبيت كل شيء داخل صندوق حماية التطبيق ، ويمكننا حتى ربط وحدة التخزين الخارجية الخاصة بنا في "المجلد الرئيسي" داخل Termux والعمل في وحدة التخزين الخارجية الخاصة بنا باستخدام جميع أدوات سطر الأوامر التي يوفرها لنا Termux.

يمكننا فتح تطبيقات Node.js في متصفحنا ، على المضيف المحلي ، والتي يتم تقديمها مباشرة من خلال Termux.

من الممكن بالتأكيد القيام بشيء كهذا باستخدام Electron.

آمل حقًا أن يحدث هذا ، لقد استخدمت ElectronJS في مشروعي السابق الذي كان نظامًا محوسبًا قائمًا على سطح المكتب قائم بذاته. كان Electron رائعًا للغاية ، والآن تريد إحدى الشركات توظيفي ويريدون إنشاء تطبيقات للهاتف المحمول ، فهم يفكرون في استخدام PhoneGap من أجله لأنهم لا يريدون تحمل مشكلة وجود فرق متعددة لمنصات مختلفة (iOS / Android) ، إن وجود حل يناسب الجميع أمر رائع للغاية ، وآمل أن يكون لدى ElectronJS إصدار يدعم الهاتف المحمول حتى لا أضطر إلى التبديل بين الأنظمة الأساسية واللغات المختلفة ، فهذا أمر مرهق في بعض الأحيان.

رد الفعل الأصلي ليس حلاً دائمًا لهذه المشكلة

aprilmintacpineda هل بحثت بالفعل في تطبيقات الويب التقدمية؟ https://developers.google.com/web/progressive-web-apps/

@ Serkan-devel نعم لدي ، لم أكن على علم بتطبيقات الويب التقدمية عندما رأيت هذه المشكلة هنا. قررت استخدام رد الفعل الأصلي بدلاً من ذلك.

aprilmintacpineda ، لا يزال بإمكانك تجربة PWAs أيضًا ، https://youtube.com/watch؟v=vhg01Ml-8pI . كما أنه يساعد على سطح المكتب

كيف يمكن للمرء أن يدمج nodejs-mobile مع Chromium ؟ يبدو أن هذا هو الحل الأقرب لجلب Node إلى الهاتف المحمول في بيئة المتصفح ، على غرار ما فعلته Electron لسطح المكتب.

(أنا على دراية بما يمكن أن تفعله PWAs اليوم ، وهناك أطر عمل مثل Cordova لتغليف تطبيقات الويب في تطبيقات الهاتف المحمول ، لكن PWAs لا يمكنها الوصول إلى أنظمة الملفات على مستوى نظام التشغيل أو تضمين خوادم HTTP ، وكوردوفا مجرد مبالغة لمشروعي الحالي ، ناهيك عن عمليات الإعداد والبناء لكل من Android و iOS.)

حزمة قابلة للتوزيع من متصفح Node-Integrated للجوال من شأنه أن يجعل التطوير سهلاً مثل تطوير تطبيقات سطح المكتب باستخدام Electron ، وهو ما أعتقد أنه جعل Electron مشهورًا للغاية. يمكن أيضًا إعادة استخدام الكثير من التعليمات البرمجية بدلاً من كتابة رمز مختلف تمامًا للجوال.

أنا مطور ويب وليس لدي الخبرة في إنشاء تطبيقات النظام / الأصلية ، ناهيك عن دمج متصفح معقد مع Node ، لذا فإن أي مؤشرات ستكون موضع تقدير كبير. إذا كانت لديك الخبرة وتريد المساعدة في إنشاء مثل هذا المشروع ، فنحن نرحب بك للمساهمة.

في حين أنه من الممكن تحقيق ذلك ، أعتقد أنه يجب علينا التفكير مرتين إذا كان ينبغي لنا فعل ذلك حقًا. في تطبيق سطح المكتب حيث استخدمت الإلكترون ، واجهت تأخيرات ، خاصة مع الرسوم المتحركة css. إذا كان هناك خيار أصلي ، فأنا أفضل اختيار المواطن الأصلي ، لديه الكثير ليقدمه. أو ربما جرب PWA. إنه رائع ، لكنه ليس بديلاً بعد للتطبيقات ، لكنني أعتقد أنه يتمتع بمستقبل رائع.

علامة

https://github.com/dna2github/dna2oslab

nodejs التي يمكن أن تعمل بشكل جيد على android

إنها ليست تمامًا مثل Electron ، ولكن بالنسبة لأي شخص يريد إنشاء تطبيقات Android باستخدام Node.js ، يبدو أن هذه المكتبة تعمل بشكل جيد في الاختبار الخاص بي.