Electron: Mobile Unterstützung

Ich denke, Atom-Shell wurde hauptsächlich für den Atom-Texteditor entwickelt, daher würde ich nicht erwarten, dass es mobile Plattformen unterstützt. Es gibt Phonegap und Cordova für mobile HTML5-Apps.

Ja, aber es geht darum, Code von node.js-Modulen zu teilen und auf Low-Level-Ressourcen zuzugreifen

Für mobile Plattformen gelten fast alle APIs von Atom-Shell nicht, daher glaube ich nicht, dass wir mobile Plattformen jemals unterstützen werden.

Vielleicht könnt ihr zumindest gut mit Cordova usw. spielen, indem ihr (irgendwie) die Umgebung erkennt (zur Laufzeit oder während des Builds angegeben), sodass die Electron-APIs einfach Cordova-Module (oder nativen Code) aufrufen, ohne dass wir es wissen. Das wäre wahnsinnig toll.

+1 @trusktr

@trusktr Klingt nach einem großartigen Modul eines Drittanbieters, das Kompatibilitäts-Shims für Cordova bereitstellen würde

Ich hoffe wirklich, dass dies geschieht. Ich denke, die Zukunft der Webplattform muss sich in diese Richtung bewegen, damit wir WIRKLICH plattformübergreifende Apps schreiben können. Ich hoffe sehr, dass das nicht ausgeschlossen ist.

Ich kann nicht glauben, dass es schon 2016 ist und es so etwas noch nicht gibt.

@emin93 dies ist nicht konstruktiv, wie bereits von @zcbenz betont , es wäre nahezu unmöglich, Electron-APIs auf Mobilgeräte zu portieren.
Sie können nicht einfach Funktionen fordern, ohne zumindest Vorschläge zu machen, wie dies geschehen kann.

@YuriSolovyov Ich beziehe mich nicht direkt auf Electron. Es gibt eigentlich keine Alternativen und das frustriert mich. Aber ja, du hast recht, das ist eigentlich nicht der richtige Ort, um darüber zu diskutieren.

Electron für Handys wäre so genial. Ich habe ein paar Electron-Apps entwickelt und liebe das Framework, aber ich wünsche mir jeden Tag, dass es auch auf Mobilgeräten funktioniert.

Das einzige plattformübergreifende Framework, das plattformübergreifende End-to-End-Unterstützung (IOS, Android, Windows, OSX, Linux) zeigt, ist Xamarin , aber dafür muss in C# codiert werden. Ich wäre nicht überrascht, wenn Xamarin bald JS-Code zulässt, da Microsoft jetzt Xamarin besitzt und auch große Fortschritte bei der Portierung von Knoten auf ihre eigene JS-Engine gemacht hat.

Ich hoffe wirklich, dass einige Unternehmenssponsoren an Bord kommen können, um einen solchen Port / Fork von Electron für Mobilgeräte zu finanzieren, der schließlich in dasselbe Framework eingebrannt wird, damit wir ein vollständiges JS-basiertes plattformübergreifendes Anwendungsentwicklungs-Framework haben können.

Vielen Dank an das Electron-Team für Ihre großartige Arbeit!

Kann jemand in Anlehnung an die ursprüngliche Frage von @cjfromthesea die Probleme mit den APIs von Electron auf Mobilgeräten erklären (vielleicht @zcbenz)? Mit einigen allgemeinen Anleitungen können ich und andere möglicherweise anfangen, über Wege nachzudenken, wie die Probleme durch Hacken und Basteln umgangen werden können. Ich habe mich ein wenig mit jxcore-cordova beschäftigt, aber eine Anleitung wäre schön. Was sind die Straßensperren?

@lastmjs Ein großes Hindernis ist, dass Electron V8 verwendet, das von iOS nicht unterstützt wird. Das bedeutet, dass Chromium und Node.js auch nicht auf iOS funktionieren und diese drei die Hauptkomponenten von Electron sind.

Eine neue Chromium-Version für IOS wurde im Januar veröffentlicht, und node.app könnte vielleicht den Trick für node.js machen. Und Android sollte kein Problem sein, da V8 unterstützt wird.
In der Zwischenzeit könnten wir eine Dokumentation darüber schreiben, wie man Cordova mit Elektron für IOS verwendet (da ich die wirklich brauche, würde ich gerne helfen).

@noelmace Chrome für iOS verwendet die Chromium-Engine nicht, da Apple dies nicht zulässt. Es ist nur das WKWebView, wie Safari es verwendet, aber mit einer anderen Benutzeroberfläche.

@emin93 Erlaubt Apply die Verwendung eines benutzerdefinierten Interpreters wie node.app?

Ich hätte ein paar Fragen, zu denen ich gerne Gedanken von denen in diesem Thread hätte—

• Möchten Sie _eine App entwickeln, die überall läuft_?
  
  
  
  • Folgefrage: Gibt es Beispiele für Desktop-Apps (die keine Web-Apps sind), die auch mobile Apps sind?
  
  
• Oder suchen Sie nach dem Electron-App-Building _experience_, aber auf dem Handy?
  
  
  
  • Folgefrage, wie würde sich das von Cordova/PhoneGap (oder anderen) unterscheiden?
  
  

Ich suche definitiv nach einer App, die überall laufen kann. Eine Codebasis, eine Webplattform, jede Umgebung.

Beispiele für gute Mobil-/Desktop-/Web-Apps, bei denen die Bildschirmgröße und das Gerät keine Rolle spielen, Sie aber möglicherweise die gleiche Funktionalität wünschen:

• Chrom
• Feuerfuchs
• Locker
• Gmail
• Google Fotos
• Google Maps

Nicht alle der oben genannten Apps haben unbedingt eine Desktop-Version, die mit einer nativen ausführbaren Datei ausgeführt wird, aber sie haben eine Desktop-Version im Browser. Für mich hängt das natürlich von Fall zu Fall ab, aber generell möchte ich, dass meine App meine App bleibt, egal auf welchem ​​Gerät sie läuft. Ich strebe so weit wie möglich die gleichen Funktionen auf allen Geräten an. Warum nicht? Ich möchte, dass Chrome auf meinem Desktop genauso funktioniert wie auf meinem Android, meinem iPhone oder meinem Tablet, das gleiche für Firefox, Slack, Google Maps. Ich finde es traurig, wenn Google Maps-Funktionen manchmal plattformspezifisch sind. Zurück zu Chrome, ich möchte in der Lage sein, die Quelle anzuzeigen und sogar den Debugger zu verwenden, sogar auf meinem Telefon. Ich denke manchmal, wir haben nicht die Weitsicht, die Funktionalität unserer Anwendungen angemessen einzuschränken. Was ist, wenn jemand eine Funktion haben möchte, die auf der Desktop-Version der App auf seinem Telefon funktioniert? Die Apps sollten natürlich responsiv sein, aber die Kernfunktionalität sollte meiner Meinung nach so weit wie möglich gleich bleiben.

Danke @lastmjs. Ich habe gerade meine Frage bearbeitet, weil ich dachte, aber nicht angegeben hatte, dass es sich um Desktop-Apps handelt, die auch mobile Apps, aber keine Web-Apps sind. Ich denke, das ist eine wichtige Unterscheidung.

aber die Kernfunktionalität sollte meiner Meinung nach so weit wie möglich gleich bleiben

Hier laut gedacht: Electron erstellt eine API für gemeinsames natives Desktop-Anwendungsverhalten – es scheint, dass die Gemeinsamkeiten zwischen all diesen schrumpfen würden, wenn Sie auch Mobilgeräte hinzufügen. Eine App, die auf den Gemeinsamkeiten zwischen Desktop und Mobilgerät basiert, könnte am Ende überall funktionieren, aber ein unterdurchschnittliches mobiles Erlebnis und ein unterdurchschnittliches Desktop-Erlebnis sein?

Sind die üblichen nativen Desktop-Anwendungsverhalten, von denen Sie sprechen, hauptsächlich UI-basiert? Ich kann sehen, wie native Menüs und andere Verhaltensweisen möglicherweise nicht gut übersetzt werden. Der größte Vorteil für mich wäre, eine konsolidierte Laufzeit zu haben, in der ich Zugriff auf Node.js- und Chromium-APIs habe und die Laufzeit auf allen wichtigen Plattformen bereitgestellt werden kann. Electron und Cordova machen in gewisser Weise dasselbe für verschiedene Plattformen, abzüglich der UI-Funktionalität, über die Sie vielleicht gesprochen haben. Mit Cordova haben Sie eine Codebasis, die auf einigen wenigen großen mobilen Betriebssystemen bereitgestellt werden kann, wobei sich die mobilen Betriebssysteme in ihrer Funktionalität nicht allzu sehr von den großen Desktop-Betriebssystemen unterscheiden. Ein Betriebssystem verwaltet Prozesse und ihre Ressourcen und gewährt Zugriff auf Hardware, die die Prozesse möglicherweise benötigen. Es gibt keinen großen grundlegenden Unterschied zwischen mobilen und Desktop-Betriebssystemen. Und da Browser beginnen, Hardware-APIs zu haben, wird die Webplattform immer universeller in ihrer Fähigkeit, sich in allen wichtigen Umgebungen einzusetzen. So wie ich es sehe, erfüllen Cordova und Electron weitgehend die gleichen Aufgaben, aber auf unterschiedlichen Betriebssystemen, wobei sich die Betriebssysteme nicht grundlegend unterscheiden, und warum also nicht sie kombinieren? 😃

@jlord

Ich baue für Mobilgeräte und Desktops und möchte die Kommentare von @lastmrs und @noelmace ergänzen

Hier sind meine Gedanken, wie es für alle funktionieren könnte.

Die API, die Elektron verfügbar macht, muss je nachdem, ob sie mobil oder Desktop ist, variieren. Es liegt dann in der Verantwortung des Entwicklers, die Laufzeitumgebungserkennung (die die Elektronenschicht bereitstellt) durchzuführen, um je nach Umgebungskontext eine andere API aufzurufen.
Um es noch einmal klarzustellen, es liegt an der Entwicklung, das Richtige zu tun

Was die UI-Aspekte betrifft, liegt es wiederum am Entwickler, das Richtige zu tun. Ich verwende Polymer für alle meine Desktop- und mobilen Projekte, und es liegt an mir, es richtig zu machen.
Ich verwende golang auch, um alle kompilierten Dinge zu schreiben, die ich auf dem Desktop und auf Mobilgeräten benötige, um auf beliebige Hardware zuzugreifen.

Zur Erstellungszeit paketiere ich für Desktop (Amd 64 usw. usw.) und Mobilgeräte (Android oder iOS), wobei ich für jedes Betriebssystem und jede Chiparchitektur ein separates Paket erstelle. Ich mache das gleiche mit Elektron. Dadurch kann ich bei Bedarf Kompilierzeitunterschiede vornehmen, da ein Teil des Codes hardwareabhängig ist.
Ich kann immer noch denselben Code in alle Builds einbauen und Laufzeit-Sniffing durchführen, und hier würde Electron mir den Umgebungskontext liefern.

Das Tolle, was dies bietet, sind gemeinsame Werkzeuge zur Entwurfszeit und zur Kompilierzeit. Dies ist eine enorme Produktivitätssteigerung für Entwickler, da Sie Elektron installieren und ein Bootstrap-Bash-Skript ausführen können, um die iOS- und Android-Bits zu installieren und Hallo Welt zu schreiben, zu verpacken und auf Desktop und Mobilgeräten bereitzustellen.

Ich wusste nicht, dass das Google-Team Chrome für iOS so aktualisiert hat, dass es Multi-Prozess ist. Ich bin sehr aufgeregt, das zu sehen.

Wenn ich dabei helfen kann, helfe ich gerne.

Dies wäre auch für viele meiner Projekte eine so massive Verbesserung. Man müsste bereits Änderungen an der Benutzeroberfläche vornehmen, je nachdem, ob sie mobil ist oder nicht, und könnte auch andere Erkennungen/Änderungen vornehmen.

Ich denke nicht, dass es eine gute Idee ist, zwei separate APIs zu haben (@joeblew99). Für den Endbenutzer wäre es meiner Meinung nach besser, wenn Electron seine APIs auf Cordova oder Node aufbauen würde, sodass der Endbenutzer nur eine API (Electron API) kennen muss. Wenn etwas nicht von der API abgedeckt wird, können Endbenutzer nach Bedarf in Node oder Cordova eintauchen.

Ich denke auch, dass es für Electron wichtig wäre, zu definieren, wie ein NPM-Workflow verwendet wird, der in beiden Fällen funktioniert (Cordova oder direkt auf Node). Das heißt, Electron müsste sein Build-System so definieren, dass es mit beiden kompatibel ist, indem es NPM verwendet (und ES6-Module wären auch gut), so dass sich Endbenutzer keine Gedanken darüber machen müssten, wie sie für beide bauen sollen. Der Node-Fall ist offensichtlich bereits behandelt, aber es muss möglicherweise zusätzliche Arbeit geleistet werden, damit NPM in Cordova einwandfrei funktioniert.

Beachten Sie, dass in Cordova Node.js-APIs nicht verfügbar sind, sodass Electron einige der nativen Node.js-Module mit Alternativen füllen müsste, die in Cordova funktionieren, ähnlich wie Browserify für den Browser. Dies würde bei der Erstellung einer einheitlichen API helfen, denn wenn es etwas gibt, das die Electron-API nicht abdeckt, dann bedeuten die mehrfach gefüllten Bibliotheken zumindest, dass der Benutzer auf Node-basierte APIs zurückgreifen kann, die hinter den Kulissen Cordova-APIs aufrufen.

Die Notwendigkeit des Polyfill ist genau das, was ich für klüger halte, um mit der API-Route zu beginnen. Es muss keine separate API sein, nur einige Funktionen sind nicht sofort verfügbar. Wenn Sie es durchgehen und es zu 100% kompatibel machen, dann ist es ein viel größeres Tier, mit dem Sie fertig werden müssen, wenn später neue Funktionen hinzugefügt werden.

Ich möchte auch nur darauf hinweisen, dass Android und IOS nicht mehr nur mobil sind. Das Projekt, an dem ich arbeite, würde auf einem Android-Fernseher fantastisch aussehen, und ich verstehe nicht, warum Github Atom nicht auf Fernsehern oder Tablets ausführen möchte.

Toller Punkt, es geht nicht mehr um die Bildschirmgröße, wir fangen an, uns mit Allzweck-Betriebssystemen zu befassen.

Ich bin verwirrt über den Status bezüglich Electron auf Android?

Wird darüber aktiv nachgedacht oder nur darüber gesprochen?

Es ist etwa 1000-mal einfacher, Electron-Apps zu einem gültigen Ziel für PhoneGap- oder Cordova-Apps zu machen!
dh. cordova platform add electron-osx electron-win electron-linux

@purplecabbage sicher, aber dann verlieren Sie alle zusätzlichen Vorteile der Kontrolle des gesamten Browserstacks.

RE: Node.js-Polyfills.

Wir sollten eine Liste der erforderlichen _nativen_ Polyfills erstellen, damit dies funktioniert. Browserify hat bereits reine Webversionen von _lot_ von Node.js Core. Die einzigen, die mir einfallen, die wir brauchen würden, sind:

• dns
• net
• fs

Noch etwas?

Globale Objekte:

• __dirname
• __Dateiname
• Prozess

@purplecabbage sieht so aus, als hätten diese 3 browserify-Implementierungen. https://github.com/substack/browserify-handbook#__dirname. Sollten wir ihnen je nach Gerät unterschiedliche Werte geben?

Ja, __dirname und __filename sind keine großen Dinge.
Prozess ist Barebones in Browserify, würden wir nicht Events unterstützen wollen?
https://github.com/defunctzombie/node-process/blob/master/browser.js

Für native mobile Apps, die Code mit electron.js teilen, ist es meiner Meinung nach am besten, die Route durch die Kombination von Electron.js mit NativeScript zu erkunden - http://github.com/NativeScript/NativeScript.

Wir (das NativeScript-Team) planen, eine Beispiel-Demo-App zu erstellen. Wenn Sie interessiert sind, kommentieren Sie dieses Problem bitte - https://github.com/NativeScript/NativeScript/issues/2695

Tatsächlich gibt es bereits Angular 2 Advanced Seed, das dies ermöglicht – https://github.com/NathanWalker/angular2-seed-advanced. Angle 2 ist aber keinesfalls Voraussetzung für die Umsetzung einer solchen Lösung.

Ist das etwas Sinnvolles?

Ich denke, das Wichtigste ist, dass Ihr Team die Beinarbeit geleistet hat, um die nativen APIs hinzuzufügen. Ich bin für deine Idee.

@valentinstoychev das ist eine wirklich interessante Idee, obwohl es im Grunde bedeutet, dass alle Elektron-Apps ihre gesamte Benutzeroberfläche neu erstellen müssen, oder? Es wäre wirklich interessant, wenn Sie irgendwie libchromiumcontent einfügen könnten, um ein webview ähnlich wie electron $ zu erstellen. Dann wäre es einfacher, beides in einer App zu nutzen.

Was ist mit dem Android WebView-Widget und dem Äquivalent auf iOS? Tatsächlich ist das Android-Gerät bereits Chromium. :)

@hadees ja, die Idee ist, die mobile UI einmal für iOS und Android mit NativeScript und einmal für den Desktop mit Elektron zu implementieren. Alles andere – Daten, Modelle, Geschäftslogik, Dienste, Datenzugriff – sollte gleich sein.

Hier sind zwei Dinge zu beachten.

Erstens werden Sie beim Erstellen mit electron.js und NativeScript fast die gleichen Fähigkeiten verwenden (d. h. ein Team kann es für Desktop, Web und Mobilgeräte erstellen) – es ist alles JavaScript/TypeScript/CSS. Sie können Angular 2 verwenden, wenn Sie möchten. Für das Styling verwenden Sie CSS sowohl für NativeScript als auch für Elektron. _Also im Allgemeinen ist das einzige, was anders sein wird, das UI-Markup_. Sogar das Layout sollte vertraut sein, da wir nächsten Monat das FlexBox-Layout veröffentlichen. Alles andere ist wiederverwendbarer Code und vor allem wiederverwendbares Skillset. Der Werkzeugteil sollte auch vertraut sein, da wir in NativeScript Chrome Devtools verwenden ...

Die zweite Sache, die Sie hier beachten sollten, ist, dass Sie tatsächlich unterschiedliche Benutzeroberflächen für Mobilgeräte und Desktops haben möchten, richtig. In vielen/den meisten Fällen wird der UI-Teil also sowieso nicht wiederverwendet und sollte anders sein.

Ich glaube, dass dies eine ziemlich überzeugende Geschichte ist, und wir werden sie untersuchen und sehr bald ein Beispiel aus dem wirklichen Leben zeigen. Ich hoffe, den tatsächlichen Code und die tatsächliche App zu sehen, hilft ein wenig zu klären, ob es sich lohnt, sie zu erkunden oder nicht.

In jedem Fall wird die endgültige App (oder Apps) überall mit nativer Benutzeroberfläche sein. Und ich denke, das macht diese Lösung einzigartig und es wert, erkundet zu werden. Es ist auch billig, gehackt zu werden, da weder an electron.js noch an NativeScript Änderungen vorgenommen werden müssen. Ausgehend von dieser ersten Lösung finden wir möglicherweise Bereiche, in denen eine engere Zusammenarbeit bestehen kann.

Ich habe Polymer für die Desktop- und mobile GUI mit Cordova verwendet. Cordova
unterstützt Desktop und Handy.

Der Schlüssel für mich war, grpc als Bindungstechnologie zu verwenden. Das machte es viel
einfacher, da Clients und Server zusammenarbeiten können.

Für alles brauchte ich nur ein Grpc-Proxy-Plugin, um als Mittelsmann zu fungieren

Am Samstag, 10. September 2016, 08:17 Uhr Valentin Stoychev, [email protected]
schrieb:

@hadees https://github.com/hadees ja, die Idee ist, das umzusetzen
mobile UI einmal für iOS und Android mit NativeScript und einmal für Desktop
unter Verwendung von Elektron. Alles andere - Daten, Modelle, Geschäftslogik, Services,
Datenzugriff sollte gleich sein.

Hier sind zwei Dinge zu beachten.

Erstens werden Sie fast das gleiche _Skillset_ verwenden (das heißt, ein Team kann
make it for desktop, web and mobile) beim Bauen mit electron.js und
NativeScript - es ist alles JavaScript/TypeScript/CSS. Sie können Angular 2 verwenden
wenn du möchtest. Für das Styling verwenden Sie CSS sowohl für NativeScript als auch für
Elektron. _Im Allgemeinen wird also nur die Benutzeroberfläche anders sein
Markup_. Sogar das Layout sollte vertraut sein, da wir FlexBox veröffentlichen
Anordnung nächsten Monat. Alles andere ist wiederverwendbarer Code und vor allem
wiederverwendbares Skillset.

Die zweite Sache, die hier zu beachten ist, ist, dass Sie eigentlich etwas anderes haben wollen
Benutzeroberfläche für Mobilgeräte und Desktops, rechts. Also, in vielen/den meisten Fällen, die UI
Teil wird sowieso nicht wiederverwendet und sollte anders sein.

Ich glaube, das ist eine ziemlich fesselnde Geschichte und wir werden sie erforschen und
bald ein Beispiel aus der Praxis zeigen. Ich hoffe, den tatsächlichen Code zu sehen und
Die tatsächliche App hilft dabei, ein wenig zu klären, ob es sich lohnt, sie zu erkunden oder nicht.

In jedem Fall wird die endgültige App (oder Apps) überall mit nativer Benutzeroberfläche sein.
Und ich denke, das macht diese Lösung einzigartig und es wert, erkundet zu werden. Es
ist auch billig zu hacken, da keine Änderungen vorgenommen werden müssen
sowohl electron.js als auch NativeScript. Ausgehend von dieser ersten Lösung haben wir
möglicherweise Bereiche finden, in denen eine engere Zusammenarbeit bestehen kann.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/electron/electron/issues/562#issuecomment -246093147,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript ist nicht wirklich eine Option für den mobilen Support von Electron, weil
es verschiebt das Paradigma vollständig weg von der Webtechnologie hin zu JavaScript
Bindungen für native Widgets. Im Wesentlichen wäre das, was wir haben werden, nicht mehr
"Electron", weil Electron im Kern ein Browser-Stack ist, der exponiert
Node.js _innerhalb_ eines Browserkontexts, und das macht Electron
Elektron.

NativeScript + Node.js-Bindungen können als völlig anders angesehen werden
Projekt.

Erstens werden Sie beim Erstellen mit electron.js und NativeScript fast die gleichen Fähigkeiten verwenden (d. h. ein Team kann es für Desktop, Web und Mobilgeräte erstellen) – es ist alles JavaScript/TypeScript/CSS.

Stimmt nicht unbedingt, denn bei NativeScript muss man welche haben
Verständnis dafür, wie sich die nativen Widgets verhalten, unabhängig davon, dass
Sie codieren in JavaScript. Das bedeutet, dass ohne Kenntnis des
Widgets und ohne Wissen darüber, wie diese Widget-Bindungen geändert werden können
nativen Code, dann wird es sehr schwierig, etwas Benutzerdefiniertes zu tun, was ist
nicht der Fall bei reinem JS/HTML/CSS in einem Webstack, weil bei einem Webstack
Das Ändern der Interna bedeutet, dass Sie denselben Codetyp in derselben Umgebung ändern, in der Sie sich bereits befinden, und sich nicht um eine Fremdsprache kümmern müssen.

Die zweite Sache, die Sie hier beachten sollten, ist, dass Sie tatsächlich unterschiedliche Benutzeroberflächen für Mobilgeräte und Desktops haben möchten, richtig. In vielen/den meisten Fällen wird der UI-Teil also sowieso nicht wiederverwendet und sollte anders sein.

Einer der Vorteile der Verwendung von Electron (mit seinem webbasierten Front-End) ist
dass wir einen Code schreiben, und er verhält sich fast _genau gleich_
überall, überallhin, allerorts. Dies wäre bei NativeScript nicht immer der Fall, was
versucht, mit einer Sprache völlig unterschiedliche Technologien zu überbrücken.

Ich persönlich mag viel mehr die Idee, überall ein Web-UI zu verwenden,
im Vergleich zu verschiedenen nativen UIs überall. Einige Leute glauben, dass native UIs
sind viel besser als Web-UIs. Es stimmt bis zu einem gewissen Grad, und es ist der Fall
mit Entwicklern, die die vollständigen Grundlagen des Webs nicht kennen. Aber mit
Mit der richtigen Verwendung von Web-APIs können wir tatsächlich nette UIs erstellen. Das Web wird riesig
Progress. WebGL ist enorm plattformübergreifend ...

_/#!/_JoePea

Am Freitag, 9. September 2016 um 23:17 Uhr, Valentin Stoychev < [email protected]

schrieb:

@hadees https://github.com/hadees ja, die Idee ist, das umzusetzen
mobile UI einmal für iOS und Android mit NativeScript und einmal für Desktop
unter Verwendung von Elektron. Alles andere - Daten, Modelle, Geschäftslogik, Services,
Datenzugriff sollte gleich sein.

Hier sind zwei Dinge zu beachten.

Erstens werden Sie fast das gleiche _Skillset_ verwenden (das heißt, ein Team kann
make it for desktop, web and mobile) beim Bauen mit electron.js und
NativeScript - es ist alles JavaScript/TypeScript/CSS. Sie können Angular 2 verwenden
wenn du möchtest. Für das Styling verwenden Sie CSS sowohl für NativeScript als auch für
Elektron. _Im Allgemeinen wird also nur die Benutzeroberfläche anders sein
Markup_. Sogar das Layout sollte vertraut sein, da wir FlexBox veröffentlichen
Anordnung nächsten Monat. Alles andere ist wiederverwendbarer Code und vor allem
wiederverwendbares Skillset.

Die zweite Sache, die hier zu beachten ist, ist, dass Sie eigentlich etwas anderes haben wollen
Benutzeroberfläche für Mobilgeräte und Desktops, rechts. Also, in vielen/den meisten Fällen, die UI
Teil wird sowieso nicht wiederverwendet und sollte anders sein.

Ich glaube, das ist eine ziemlich fesselnde Geschichte und wir werden sie erforschen und
bald ein Beispiel aus der Praxis zeigen. Ich hoffe, den tatsächlichen Code zu sehen und
Die tatsächliche App hilft dabei, ein wenig zu klären, ob es sich lohnt, sie zu erkunden oder nicht.

In jedem Fall wird die endgültige App (oder Apps) überall mit nativer Benutzeroberfläche sein.
Und ich denke, das macht diese Lösung einzigartig und es wert, erkundet zu werden. Es
ist auch billig zu hacken, da keine Änderungen vorgenommen werden müssen
sowohl electron.js als auch NativeScript. Ausgehend von dieser ersten Lösung haben wir
möglicherweise Bereiche finden, in denen eine engere Zusammenarbeit bestehen kann.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/electron/electron/issues/562#issuecomment -246093147,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr Dem stimme ich voll und ganz zu. Ich denke, Entwickler legen zu viel Wert darauf, nativ auszusehen. Native ist nicht einmal ein konsistentes Ideal. In den letzten zehn Jahren haben sich mobile Schnittstellen dutzende Male geändert und sind nicht einmal von einem Android-Telefon zum nächsten konsistent.

Es ist ein viel besserer Standard, wenn Ihre App auf allen Plattformen, von denen ein Benutzer möglicherweise darauf zugreift, konsistent aussieht. Es ist schrecklich, sie dazu zu bringen, zwei Sätze von UI-Symbolen und Signalen zu lernen, nur um eine App sowohl auf ihrem iPhone als auch auf ihrer Windows-Arbeitsmaschine zu bedienen.

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

In der Vergangenheit wurde der Code für Chrome für iOS aufgrund der für die Plattform erforderlichen zusätzlichen Komplexität vom Rest des Chromium-Projekts getrennt gehalten. Nach Jahren sorgfältiger Umgestaltung wird dieser gesamte Code wieder in Chromium aufgenommen und in das Open-Source-Repository verschoben.

Aufgrund von Einschränkungen der iOS-Plattform müssen alle Browser auf der WebKit-Rendering-Engine aufbauen. Für Chromium bedeutet dies, dass sowohl WebKit als auch Blink, die Rendering-Engine von Chrome für andere Plattformen, unterstützt werden. Das führte zu einigen zusätzlichen Komplexitäten, die wir vermeiden wollten, in die Chromium-Codebasis zu integrieren.

Angesichts des Engagements von Chrome für Open-Source-Code haben wir in den letzten Jahren viel Zeit darauf verwendet, die Änderungen vorzunehmen, die erforderlich sind, um den Code für Chrome für iOS in Chromium hochzuladen. Heute ist das Upstreaming abgeschlossen und Entwickler können die iOS-Version von Chromium so kompilieren, wie sie es für andere Versionen von Chromium können. Die Entwicklungsgeschwindigkeit ist jetzt auch schneller, da alle Tests für Chrome für iOS der gesamten Chromium-Community zur Verfügung stehen und jedes Mal automatisch ausgeführt werden, wenn dieser Code eingecheckt wird.

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

Der erste große Schritt? :]

Aber das bedeutet nichts, da Chrom nicht auf den Apple Store gelegt werden darf.

Aber in Android wird es jetzt dringend benötigt.

Die Entwicklung mit Cordova und Standard-Webview ist die Hölle, und Intel hatte Crosswalk, das Intels Port von Chromium Webview als Standard-Webview für Android ist, verschrottet.
https://crosswalk-project.org/blog/crosswalk-final-release.html

Probleme:

• Die Standard-Webansicht ist unzuverlässig, da verschiedene Anbieter unterschiedliche Dinge tun. Sie ist bis Android 6.0 nicht stabil, was nur 20% der Telefone verwenden.
• Nicht jeder führt Android-Firmware- oder -Paketaktualisierungen durch, insbesondere in Bereichen mit eingeschränkter Bandbreite und teurem 3G.

Was wir tun können:

• Elektronen-APIs können nicht auf Chrom portiert werden (wie @zcbenz 2014 sagte)
• Chromuim für Android und Chromium WebView für Android sind jetzt vollständig Opensource: https://www.chromium.org/developers/how-tos/android-build-instructions
• Wir können Crosswalk forken und weiter pflegen (was im Grunde eine Portierung von Chrom auf Android mit weniger Einschränkungen ist) https://github.com/crosswalk-project , es ist bereits ziemlich stabil.
• Unsere Erfahrung zeigt, dass Crosswalk und Cordova mit einem guten JS-Framework nahezu native Leistung erbringen (Emberjs/React/Angular/Vue).
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

Wir brauchen Mitwirkende und Betreuer in Crosswalk , das könnte jemand sein, den Sie suchen.

Gute Nachrichten

Relevante Neuigkeiten, neue Portierung von Node.js auf iOS von @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/

Die einzige Anstrengung, die unternommen werden müsste, besteht also darin, sicherzustellen, dass die mobilen Browser Elektron unterstützen, wenn sie über den von @mikeal geposteten Link emuliert werden?

Ist es heutzutage legal, andere JS-VMs auf iOS zu versenden? Oder verlangt Apple immer noch, dass Sie ihre verwenden?

Das Versenden von VMs durch @trusktr , die keinen ausführbaren Code generieren, verstößt nicht gegen die App Store-Richtlinien. Wir haben zuvor eine solche App im App Store genehmigt bekommen (allerdings mit SpiderMonkey und nicht mit ChakraCore).

Können wir dieses Thema erneut öffnen, um die Diskussion darüber fortzusetzen, ob Elektron in Zukunft ein unterstütztes mobiles Framework haben wird?

Ich unterstütze das. Was muss getan werden? Ich freue mich, mit dem Testen oder Hacken mit einer kleinen Anleitung zu beginnen.

@OtterCode wäre es sinnvoll, ein Repo namens Electron-Mobile zu erstellen und dort mit dem Hacken zu beginnen? Ich konnte einen notwendigen Schritt der Planung und Vorbereitung von Beispielanwendungen sehen, um herauszufinden, was getan werden muss. Gibt es eine API-Bibliothek auf höherer Ebene für Elektron, die wir emulieren könnten, um loszulegen? (API-Dokumente, Build-Ziele usw.)

@OtterCode und alle Interessierten habe ich erstellt, https://github.com/gabrielcsapo/electron-mobile , wenn jemand interessiert ist, kann ich Sie als Besitzer hinzufügen und wir können mit der Arbeit an einem Weg nach vorne für iOS- und Android-Builds beginnen Ziele für Elektron.

Produkte wie Samsung Dex, http://www.samsung.com/global/galaxy/apps/samsung-dex/
Machen Sie dies zu einer praktikablen Anfrage IMO (zumindest für Android).

Das ist auf jeden Fall sehr machbar. Die Anwendung „Termux“ von Google Play liefert uns zum Beispiel ein ganzes Debian-basiertes Terminal direkt in der App. Wir können apt-get install alles, was wir brauchen (Node, Vim, Git usw., solange das Ding, das wir installieren, die CPU-Architektur des Geräts unterstützt). Es ist durchaus möglich, Electron in einer eigenen App-Sandbox-Umgebung ähnlich wie Termux zum Laufen zu bringen.

Termux funktioniert, ohne unsere Telefone zu rooten, es installiert alles in der App-Sandbox, und wir können unseren externen Speicher sogar mit unserem „Home-Ordner“ innerhalb von Termux verknüpfen und mit allen Befehlszeilen-Tools, die Termux uns bietet, in unserem externen Speicher arbeiten.

Wir können Node.js-Apps in unserem Browser auf localhost öffnen, die direkt von Termux aus bereitgestellt werden.

Es ist definitiv möglich, so etwas mit Electron zu machen.

Ich hoffe wirklich, dass dies passieren wird, ich habe ElectronJS für mein vorheriges Projekt verwendet, das ein eigenständiges computergestütztes Desktop-basiertes System war. Electron war extrem großartig, jetzt möchte mich ein Unternehmen einstellen und mobile Apps erstellen. Sie denken darüber nach, PhoneGap dafür zu verwenden, da sie sich nicht die Mühe machen wollen, mehrere Teams für verschiedene Plattformen (iOS/Android) zu haben. , eine One-Fits-All-Lösung zu haben, ist extrem großartig, und ich hoffe, ElectronJS kann eine Version haben, die Mobilgeräte unterstützt, sodass ich nicht zwischen verschiedenen Plattformen und Sprachen wechseln muss, was manchmal wirklich ermüdend ist.

React-Native ist keine dauerhafte Lösung für dieses Problem

@aprilmintacpineda hast du dich schon mit Progressive Web Apps beschäftigt? https://developers.google.com/web/progressive-web-apps/

@Serkan-devel Ja, das habe ich, ich war mir der progressiven Web-Apps nicht bewusst, als ich dieses Problem hier sah. Ich habe mich stattdessen für React-Native entschieden.

@aprilmintacpineda Sie können PWAs auch noch ausprobieren, https://youtube.com/watch?v=vhg01Ml-8pI . Es hilft auch auf dem Desktop

Wie integriert man nodejs-mobile mit Chromium ? Dies scheint die nächste Lösung zu sein, um Node in einer Browserumgebung auf Mobilgeräte zu bringen, ähnlich wie Electron es für den Desktop getan hat.

(Mir ist bewusst, was PWAs heute können , und es gibt Frameworks wie Cordova, um Web-Apps in mobile Apps einzubetten, aber PWAs können nicht auf Dateisysteme auf Betriebssystemebene zugreifen oder HTTP-Server einbetten, und Cordova ist einfach ein Overkill für mein aktuelles Projekt, ganz zu schweigen von den Setup- und Build-Prozessen für Android und iOS.)

Ein verteilbares Bündel von Node-integrierten Browsern für Mobilgeräte hätte die Entwicklung so einfach gemacht wie die Entwicklung von Desktop-Apps mit Electron, was meiner Meinung nach Electron so beliebt gemacht hat. Viel Code wäre auch wiederverwendbar, anstatt komplett anderen Code für Mobilgeräte zu schreiben.

Ich bin ein Webentwickler und habe nicht das Fachwissen zum Erstellen von System-/nativen Anwendungen, geschweige denn zum Integrieren eines komplexen Browsers in Node, daher wären alle Hinweise sehr willkommen. Wenn Sie über das Fachwissen verfügen und bei der Erstellung eines solchen Projekts helfen möchten, können Sie gerne einen Beitrag leisten.

Obwohl dies möglich ist, sollten wir es uns zweimal überlegen, ob wir dies wirklich tun sollten. In der Desktop-App, in der ich Elektron verwendet habe, habe ich Verzögerungen erlebt, insbesondere bei CSS-Animationen. Wenn es eine native Option gibt, würde ich mich eher für die native entscheiden, native hat viel zu bieten. Oder vielleicht probieren Sie PWA aus. Es ist großartig, aber NOCH kein Ersatz für Apps, aber ich denke, es hat eine große Zukunft.

Kennzeichen

https://github.com/dna2github/dna2oslab

die nodejs, die auf Android gut funktionieren können

Es ist nicht genau wie Electron, aber für jeden, der Android-Apps mit Node.js erstellen möchte, scheint diese Bibliothek in meinen Tests gut zu funktionieren.