Electron: Assistance mobile

Je pense qu'atom-shell a été principalement conçu pour l'éditeur de texte atom, donc je ne m'attendrais pas à ce qu'il prenne en charge les plates-formes mobiles. Il existe Phonegap et Cordova pour les applications mobiles HTML5.

Oui, mais il s'agit de partager le code des modules node.js et d'accéder aux ressources de bas niveau

Pour la plate-forme mobile, presque toutes les API d'atom-shell ne s'appliquent pas, donc je ne pense pas que nous prendrons jamais en charge les plates-formes mobiles.

Peut-être que vous pouvez au moins bien jouer avec Cordova, etc., en détectant (d'une manière ou d'une autre) l'environnement (au moment de l'exécution ou spécifié lors de la construction) afin que les API Electron appellent simplement les modules Cordova (ou le code natif) sans que nous le sachions. Ce serait incroyablement génial.

+1 @trusktr

@trusktr Cela ressemble à un excellent module tiers qui fournirait des cales de compatibilité pour Cordova

J'espère vraiment que ça arrive. Je pense que l'avenir de la plate-forme Web doit évoluer dans cette direction, afin que nous puissions écrire VRAIMENT des applications multiplateformes. J'espère vraiment que ce n'est pas exclu.

Je ne peux pas croire que nous sommes déjà en 2016 et qu'il n'y a toujours rien de tel.

@emin93 ce n'est pas constructif, comme l'a déjà souligné @zcbenz , il serait presque impossible de porter les API Electron sur mobile.
Vous ne pouvez pas simplement exiger des fonctionnalités sans au moins quelques suggestions sur la façon de les réaliser.

@YuriSolovyov Je ne parle pas directement d'Electron. Il n'y a en fait aucune alternative et c'est ce qui me frustre. Mais oui, vous avez raison, ce n'est en fait pas le bon endroit pour en parler.

Electron pour mobile serait tellement génial. J'ai développé quelques applications Electron et j'adore le cadre, mais chaque jour, je souhaite que nous le voyions également fonctionner sur mobile.

Le seul framework multiplateforme qui montre un support multiplateforme de bout en bout (IOS, Android, Windows, OSX, Linux) est Xamarin mais qui nécessite de coder en C#. Je ne serais pas surpris si Xamarin autorise le code JS dès que Microsoft possède désormais Xamarin et a également fait de grands progrès dans le portage du nœud vers son propre moteur JS.

J'espère vraiment que certaines entreprises sponsors pourront s'impliquer pour financer un tel port / fork d'électron pour mobile qui serait éventuellement intégré dans le même cadre afin que nous puissions avoir un cadre de développement d'applications multiplateforme basé sur JS.

Merci à l'équipe Electron pour votre excellent travail !

Faisant écho à la question initiale de @cjfromthesea , quelqu'un peut-il expliquer les problèmes rencontrés avec les API d'Electron sur mobile (peut-être @zcbenz) ? Avec quelques conseils généraux, moi-même et d'autres pouvons potentiellement commencer à réfléchir à des moyens de contourner les problèmes en piratant et en bricolant. J'ai un peu traité avec jxcore-cordova, mais quelques conseils seraient bien. Quels sont les barrages routiers ?

@lastmjs un énorme barrage routier est qu'Electron utilise V8 qui n'est pas pris en charge sur iOS. Cela signifie que Chromium et Node.js ne fonctionneront pas non plus sur iOS et ces trois éléments sont les principaux composants d'Electron.

Une nouvelle version chromium pour IOS est sortie en janvier, et node.app pourrait peut-être faire l'affaire pour node.js. Et Android ne devrait pas être un problème étant donné que V8 est pris en charge.
En attendant, nous pourrions écrire une documentation sur la façon d'utiliser Cordova avec electron pour IOS (comme j'en ai vraiment besoin, je serais heureux de vous aider).

@noelmace Chrome pour iOS n'utilise pas le moteur Chromium car Apple ne le permet pas. C'est juste le WKWebView comme Safari l'utilise, mais avec une interface utilisateur différente.

@ emin93 Apply permet-il d'utiliser n'importe quel interpréteur personnalisé comme node.app ?

J'avais quelques questions sur lesquelles j'aimerais avoir des réflexions de la part de ceux de ce fil—

• Souhaitez-vous créer _une application qui s'exécute partout_ ?
  
  
  
  • Question complémentaire : existe-t-il des exemples d'applications de bureau (qui ne sont pas des applications Web) qui sont également des applications mobiles ?
  
  
• Ou recherchez-vous l'_expérience_ de création d'applications Electron mais sur mobile ?
  
  
  
  • Question de suivi, en quoi cela serait-il différent de Cordova/PhoneGap (ou d'autres) ?
  
  

Je suis définitivement à la recherche d'une application qui peut fonctionner partout. Une base de code, une plateforme Web, n'importe quel environnement.

Exemples de bonnes applications mobiles/de bureau/web, où la taille de l'écran et l'appareil n'ont pas vraiment d'importance, mais vous pourriez vouloir la même fonctionnalité :

• Chrome
• Firefox
• Mou
• Gmail
• Google Photos
• Google Maps

Toutes les applications ci-dessus n'ont pas nécessairement une version de bureau exécutée avec un exécutable natif, mais elles ont une version de bureau dans le navigateur. Pour moi, bien sûr, cela dépend de chaque cas, mais en général, je veux que mon application soit mon application, quel que soit l'appareil sur lequel elle se trouve. Je m'efforce autant que possible d'avoir les mêmes fonctionnalités sur tous les appareils. Pourquoi pas? Je veux que Chrome fonctionne de la même manière sur mon bureau que sur mon Android, mon iPhone ou ma tablette, de même pour Firefox, Slack, Google Maps. Je trouve triste que les fonctionnalités de Google Maps soient parfois spécifiques à une plate-forme. De retour à Chrome, je veux pouvoir afficher la source et même utiliser le débogueur, même sur mon téléphone. Je pense parfois que nous n'avons pas la prévoyance de limiter la fonctionnalité de nos applications de manière appropriée. Que se passe-t-il si quelqu'un veut une fonctionnalité qui fonctionne sur la version de bureau de l'application sur son téléphone ? Les applications doivent bien sûr être réactives, mais les fonctionnalités de base doivent rester les mêmes autant que possible à mon avis.

Merci @lastmjs. Je viens de modifier ma question parce que ce que je pensais, mais que je n'avais pas précisé, c'était des applications de bureau qui sont également des applications mobiles mais qui ne sont pas des applications Web. Je pense que c'est une distinction importante.

mais la fonctionnalité de base devrait rester la même autant que possible à mon avis

Penser à voix haute ici : Electron crée une API pour les comportements courants des applications de bureau natives. Il semble que si vous ajoutez également le mobile, le terrain d'entente entre tous ces éléments diminuerait. Une application basée sur le terrain d'entente entre ordinateur de bureau et mobile pourrait en fin de compte fonctionner partout, mais être une expérience mobile et une expérience de bureau inférieures à la normale ?

Les comportements courants des applications de bureau natives dont vous parlez sont-ils principalement basés sur l'interface utilisateur ? Je peux voir comment les menus natifs et d'autres comportements peuvent ne pas bien se traduire. Le plus grand avantage pour moi serait d'avoir un environnement d'exécution consolidé, où j'ai accès aux API Node.js et Chromium, et ledit environnement d'exécution pouvant être déployé sur toutes les principales plates-formes. Electron et Cordova font en quelque sorte la même chose pour différentes plates-formes, moins la fonctionnalité d'interface utilisateur dont vous avez peut-être parlé. Avec Cordova, vous disposez d'une base de code qui peut être déployée sur quelques principaux systèmes d'exploitation mobiles, lesdits systèmes d'exploitation mobiles n'étant pas trop différents en termes de fonctionnalités des principaux systèmes d'exploitation de bureau. Un système d'exploitation gère les processus et leurs ressources, et accorde l'accès au matériel dont les processus pourraient avoir besoin. Il n'y a pas beaucoup de différence fondamentale entre les systèmes d'exploitation mobiles et de bureau. Et avec les navigateurs qui commencent à avoir des API matérielles, la plate-forme Web devient de plus en plus universelle dans sa capacité à se déployer dans tous les principaux environnements. Donc, selon moi, Cordova et Electron accomplissent en grande partie les mêmes tâches mais sur des systèmes d'exploitation différents, lesdits systèmes d'exploitation n'étant pas fondamentalement différents, et alors pourquoi ne pas les combiner ? 😃

@jlord

Je construis pour mobile et ordinateur de bureau et j'aimerais ajouter aux commentaires de @lastmrs et @noelmace

Voici mes réflexions sur la façon dont cela pourrait fonctionner pour tout le monde.

L'API que l'électron expose doit varier selon qu'il s'agit d'un mobile ou d'un ordinateur de bureau. Il est donc alors de la responsabilité du développeur de faire la détection de l'environnement d'exécution (ce que la couche électronique fournit) pour appeler une API différente en fonction du contexte de l'environnement.
Encore une fois pour être clair, c'est au développeur de faire ce qu'il faut

En ce qui concerne les aspects de l'interface utilisateur, encore une fois, c'est au développeur de faire ce qu'il faut. J'utilise du polymère pour tous mes projets de bureau et mobiles, et c'est à moi de le faire correctement.
J'utilise également golang pour écrire tout ce dont j'ai besoin sur ordinateur et sur mobile pour accéder à n'importe quel matériel.

Au moment de la construction, j'emballe pour les ordinateurs de bureau ( amd 64, etc. ) et mobiles ( android ou iOS) où je crée un package séparé pour chaque architecture de système d'exploitation et de puce. Je fais la même chose avec l'électron. Cela me permet de compiler les différences de temps selon mes besoins, car certains codes dépendent du matériel.
Je peux toujours inclure le même code dans toutes les versions et faire du reniflage d'exécution, et c'est là qu'électron me fournirait le contexte de l'environnement.

La grande chose que cela fournit est un outil commun au moment de la conception et au moment de la compilation. Il s'agit d'une énorme amélioration de la productivité pour les développeurs, car vous pouvez installer electron et exécuter un script bootstrap bash pour installer les bits iOS et Android et votre écriture hello world et empaqueter et déployer sur ordinateur de bureau et mobile.

Je ne savais pas que l'équipe Google avait mis à jour chrome pour iOS afin qu'il soit multi-processus. Je suis super excité de voir ça.

Si je peux aider avec tout cela, je serais heureux de vous aider.

Ce serait aussi une amélioration massive pour beaucoup de mes projets. Il faudrait déjà apporter des modifications à l'interface utilisateur selon qu'elle est mobile ou non, autant faire d'autres détections/modifications également.

Je ne pense pas qu'avoir deux API distinctes soit une bonne idée (@joeblew99). Pour l'utilisateur final, je pense qu'il serait préférable qu'Electron fasse fonctionner ses API au-dessus de Cordova ou de Node, de sorte que l'utilisateur final n'ait besoin de connaître qu'une seule API (API Electron). Ensuite, si quelque chose n'est pas couvert par l'API, les utilisateurs finaux peuvent plonger dans Node ou Cordova selon leurs besoins.

De plus, je pense qu'il serait important pour Electron de définir comment utiliser un flux de travail NPM qui fonctionne dans les deux cas (Cordova ou directement sur Node). C'est-à-dire qu'Electron devrait définir son système de construction pour qu'il soit compatible avec les deux, en utilisant NPM (et les modules ES6 seraient également utiles) afin que les utilisateurs finaux n'aient pas à se soucier de la façon de construire pour chacun. Le cas de Node est déjà traité, évidemment, mais il faudra peut-être travailler davantage pour que NPM fonctionne correctement à Cordova.

Notez que dans Cordova, les API Node.js ne sont pas disponibles, donc Electron aurait besoin de remplir certains des modules Node.js natifs avec des alternatives qui fonctionnent dans Cordova, similaire à ce que fait Browserify pour le navigateur. Cela aiderait à créer une API unifiée, car s'il y a quelque chose que l'API Electron ne couvre pas, alors au moins les bibliothèques polyfilles signifient que l'utilisateur peut se rabattre sur les API basées sur Node qui appellent en coulisse les API Cordova.

Le besoin de polyfill est exactement ce que je pense qu'il est plus intelligent de commencer avec la route API. Il n'est pas nécessaire que ce soit une API distincte, seules certaines fonctionnalités ne sont pas disponibles immédiatement. Si vous le rendez 100% compatible, alors c'est une bête beaucoup plus grosse à gérer lorsque de nouvelles fonctionnalités sont ajoutées sur la route.

Je voudrais également souligner qu'Android et IOS ne sont plus seulement mobiles. Le projet sur lequel je travaille aurait l'air génial sur un téléviseur Android, et je ne vois pas pourquoi Github ne voudrait pas faire fonctionner Atom sur des téléviseurs ou des tablettes.

Bon point, il ne s'agit plus de taille d'écran, nous commençons à traiter des systèmes d'exploitation à usage général.

Je suis confus quant au statut d'Electron sur Android ?

Est-ce quelque chose qui est activement envisagé ou simplement quelque chose dont on parle ?

Faire des applications Electron une cible valide pour les applications PhoneGap ou Cordova est environ 1000 fois plus facile !
c'est à dire. cordova platform add electron-osx electron-win electron-linux

@purplecabbage bien sûr, mais vous perdez alors tous les avantages supplémentaires du contrôle de l'ensemble de la pile du navigateur.

RE : Node.js Polyfills.

Nous devrions commencer une liste des polyfills _native_ requis pour que cela fonctionne. Browserify a déjà des versions Web pures d'un _lot_ de Node.js Core. Les seuls dont nous aurions besoin à mon avis sont :

• dns
• net
• fs

Rien d'autre?

Objets globaux :

• __dirname
• __nom de fichier
• traiter

@purplecabbage ressemble à ces 3 implémentations de navigateur. https://github.com/substack/browserify-handbook#__dirname. Doit-on leur donner des valeurs différentes selon les appareils ?

oui, __dirname et __filename ne sont pas des biggies.
le processus est rudimentaire dans browserify, ne voudrions-nous pas prendre en charge les événements ?
https://github.com/defunctzombie/node-process/blob/master/browser.js

Pour les applications mobiles natives partageant du code avec electron.js, je pense que le mieux sera d'explorer la voie en combinant Electron.js avec NativeScript - http://github.com/NativeScript/NativeScript.

Nous (l'équipe NativeScript) prévoyons de créer un exemple d'application de démonstration, si vous êtes intéressé, veuillez commenter ce problème - https://github.com/NativeScript/NativeScript/issues/2695

En fait, il existe déjà une graine avancée Angular 2 qui permet cela - https://github.com/NathanWalker/angular2-seed-advanced. Mais angular 2 n'est en aucun cas une exigence pour mettre en œuvre ce type de solution.

Est-ce quelque chose qui a du sens ?

Je pense que l'essentiel est que votre équipe ait fait le travail nécessaire pour ajouter les API natives. Je suis tout à fait d'accord avec ton idée.

@valentinstoychev c'est une idée vraiment intéressante même si cela signifie essentiellement que toutes les applications électroniques vont devoir refaire toute l'interface utilisateur, n'est-ce pas ? Ce serait vraiment intéressant si vous pouviez tous inclure libchromiumcontent pour créer un webview similaire à electron . Ensuite, il serait plus facile d'utiliser les deux dans une seule application.

Qu'en est-il du widget Android WebView et de son équivalent sur iOS ? En fait celui d'Android est déjà chromé. :)

@hadees oui, l'idée est d'implémenter l'interface utilisateur mobile une fois pour iOS et Android en utilisant NativeScript et une fois pour le bureau en utilisant electron. Tout le reste - données, modèles, logique métier, services, accès aux données doit être le même.

Il y a deux choses à noter ici.

Tout d'abord, vous utiliserez presque le même ensemble de compétences (ce qui signifie qu'une équipe peut le faire pour le bureau, le Web et le mobile) lors de la construction avec electron.js et NativeScript - tout est JavaScript/TypeScript/CSS. Vous pouvez utiliser Angular 2 si vous le souhaitez. Pour le style, vous utiliserez CSS pour NativeScript et electron. _Donc, généralement, la seule chose qui sera différente est le balisage de l'interface utilisateur_. Même la mise en page devrait être familière car nous publierons la mise en page FlexBox le mois prochain. Tout le reste est un code réutilisable et, surtout, un ensemble de compétences réutilisables. La partie outillage doit également être familière car dans NativeScript nous utilisons Chrome Devtools...

La deuxième chose à noter ici est que vous voulez en fait avoir une interface utilisateur différente pour le mobile et le bureau, n'est-ce pas. Ainsi, dans la plupart des cas, la partie UI ne sera de toute façon pas réutilisée et devrait être différente.

Je pense que c'est une histoire assez convaincante et nous allons l'explorer et montrer un exemple concret très bientôt. J'espère que voir le code réel et l'application réelle aidera à clarifier un peu si cela vaut la peine d'être exploré ou non.

Dans tous les cas, l'application finale (ou les applications) sera avec une interface utilisateur native partout. Et je pense que c'est ce qui rend cette solution unique et mérite d'être explorée. Il est également peu coûteux d'être piraté car il n'y a aucune modification à apporter à la fois à electron.js et à NativeScript. A partir de cette première solution, on peut trouver des domaines où une collaboration plus étroite peut exister.

J'ai utilisé du polymère pour l'interface graphique de bureau et mobile, avec Cordova. Cordoue
prend en charge le bureau et le mobile.

La clé pour moi était d'utiliser grpc comme technologie de liaison. Cela a fait beaucoup
plus facile car les clients et les serveurs peuvent interagir.

Pour tous, j'avais juste besoin d'un plugin proxy grpc pour agir en tant qu'intermédiaire

Le sam. 10 sept. 2016, 08:17 Valentin Stoychev, [email protected]
a écrit:

@hadees https://github.com/hadees oui, l'idée est d'implémenter le
interface utilisateur mobile une fois pour iOS et Android en utilisant NativeScript et une fois pour le bureau
utilisant l'électron. Tout le reste - données, modèles, logique métier, services,
l'accès aux données doit être le même.

Il y a deux choses à noter ici.

Tout d'abord, vous utiliserez presque le même _skillset_ (ce qui signifie qu'une équipe peut
faites-le pour le bureau, le Web et le mobile) lors de la construction avec electron.js et
NativeScript - tout est JavaScript/TypeScript/CSS. Vous pouvez utiliser Angular 2
si tu veux. Pour le style, vous utiliserez CSS pour NativeScript et
électron. _Donc, généralement, la seule chose qui sera différente est l'interface utilisateur
balisage_. Même la mise en page devrait être familière car nous publions FlexBox
mise en page le mois prochain. Tout le reste est du code réutilisable et surtout
compétences réutilisables.

La deuxième chose à noter ici est que vous voulez réellement avoir différents
Interface utilisateur pour mobile et ordinateur de bureau, à droite. Ainsi, dans de nombreux/la plupart des cas, l'interface utilisateur
partie ne sera pas réutilisée de toute façon et devrait être différente.

Je crois que c'est une histoire assez convaincante et nous allons l'explorer et
montrer un exemple concret très bientôt. J'espère voir le code réel et
l'application réelle aidera à clarifier un peu si cela vaut la peine d'être exploré ou non.

Dans tous les cas, l'application finale (ou les applications) sera avec une interface utilisateur native partout.
Et je pense que c'est ce qui rend cette solution unique et mérite d'être explorée. Ce
est également bon marché pour être piraté car il n'y a aucun changement à faire sur
à la fois electron.js et NativeScript. Partant de cette première solution, nous
peut trouver des domaines où une collaboration plus étroite peut exister.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/electron/electron/issues/562#issuecomment -246093147,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript n'est pas vraiment une option pour le support mobile d'Electron, car
il déplace complètement le paradigme de la technologie Web vers JavaScript
liaisons pour les widgets natifs. En substance, ce que nous aurons ne serait plus
"Electron", car Electron est à la base une pile de navigateur qui expose
Node.js _inside_ d'un contexte de navigateur, et c'est ce qui rend Electron
Électron.

Les liaisons NativeScript + Node.js peuvent être considérées comme complètement différentes
projet.

Tout d'abord, vous utiliserez presque le même ensemble de compétences (ce qui signifie qu'une équipe peut le faire pour le bureau, le Web et le mobile) lors de la construction avec electron.js et NativeScript - tout est JavaScript/TypeScript/CSS.

Pas nécessairement vrai, car avec NativeScript vous devez avoir quelques
compréhension du comportement des widgets natifs, indépendamment du fait que
vous codez en JavaScript. Cela signifie qu'à l'insu des
widgets, et sans savoir comment modifier ces liaisons de widget avec
code natif, alors faire quelque chose de personnalisé devient très difficile, ce qui est
pas le cas avec JS/HTML/CSS pur dans une pile Web, car avec une pile Web
modifier les composants internes signifie modifier le même type de code dans le même environnement que celui dans lequel vous vous trouvez déjà, sans avoir à vous soucier d'une langue étrangère.

La deuxième chose à noter ici est que vous voulez en fait avoir une interface utilisateur différente pour le mobile et le bureau, n'est-ce pas. Ainsi, dans la plupart des cas, la partie UI ne sera de toute façon pas réutilisée et devrait être différente.

L'un des avantages de l'utilisation d'Electron (avec son interface Web), est
que nous écrivons un code, et il se comporte presque _exactement de la même manière_
partout. Ce ne serait pas toujours le cas avec NativeScript, qui
essaie de relier des ensembles de technologies complètement différents avec une seule langue.

Personnellement, j'aime beaucoup plus l'idée d'utiliser une interface utilisateur Web partout,
par rapport à différentes interfaces utilisateur natives partout. Certaines personnes pensent que les interfaces utilisateur natives
sont bien meilleurs que les interfaces utilisateur Web. C'est vrai dans une certaine mesure, et c'est le cas
avec des développeurs qui ne connaissent pas tous les sous-jacents du Web. Mais avec
en utilisant correctement les API Web, nous pouvons en fait créer de belles interfaces utilisateur. Le web devient énorme
le progrès. WebGL est extrêmement multiplateforme...

_/#!/_JoePea

Le ven. 9 septembre 2016 à 23h17, Valentin Stoychev < [email protected]

a écrit:

@hadees https://github.com/hadees oui, l'idée est d'implémenter le
interface utilisateur mobile une fois pour iOS et Android en utilisant NativeScript et une fois pour le bureau
utilisant l'électron. Tout le reste - données, modèles, logique métier, services,
l'accès aux données doit être le même.

Il y a deux choses à noter ici.

Tout d'abord, vous utiliserez presque le même _skillset_ (ce qui signifie qu'une équipe peut
faites-le pour le bureau, le Web et le mobile) lors de la construction avec electron.js et
NativeScript - tout est JavaScript/TypeScript/CSS. Vous pouvez utiliser Angular 2
si tu veux. Pour le style, vous utiliserez CSS pour NativeScript et
électron. _Donc, généralement, la seule chose qui sera différente est l'interface utilisateur
balisage_. Même la mise en page devrait être familière car nous publions FlexBox
mise en page le mois prochain. Tout le reste est du code réutilisable et surtout
compétences réutilisables.

La deuxième chose à noter ici est que vous voulez réellement avoir différents
Interface utilisateur pour mobile et ordinateur de bureau, à droite. Ainsi, dans de nombreux/la plupart des cas, l'interface utilisateur
partie ne sera pas réutilisée de toute façon et devrait être différente.

Je crois que c'est une histoire assez convaincante et nous allons l'explorer et
montrer un exemple concret très bientôt. J'espère voir le code réel et
l'application réelle aidera à clarifier un peu si cela vaut la peine d'être exploré ou non.

Dans tous les cas, l'application finale (ou les applications) sera avec une interface utilisateur native partout.
Et je pense que c'est ce qui rend cette solution unique et mérite d'être explorée. Ce
est également bon marché pour être piraté car il n'y a aucun changement à faire sur
à la fois electron.js et NativeScript. Partant de cette première solution, nous
peut trouver des domaines où une collaboration plus étroite peut exister.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/electron/electron/issues/562#issuecomment -246093147,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr Je suis entièrement d'accord. Je pense que les développeurs accordent trop d'importance à l'aspect natif. Native n'est même pas un idéal cohérent. Au cours de la dernière décennie, les interfaces mobiles ont changé des dizaines de fois et ne sont même pas cohérentes d'un téléphone Android à l'autre.

Faire en sorte que votre application ait l'air cohérente sur toutes les plateformes à partir desquelles un utilisateur peut y accéder est une bien meilleure norme à respecter. Leur faire apprendre deux ensembles de symboles et de signaux d'interface utilisateur juste pour faire fonctionner une application à la fois sur leur iPhone et sur leur machine de travail Windows est terrible.

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

Historiquement, le code de Chrome pour iOS était séparé du reste du projet Chromium en raison de la complexité supplémentaire requise pour la plate-forme. Après des années de refactorisation minutieuse, tout ce code rejoint Chromium et est déplacé dans le référentiel open source.

En raison des contraintes de la plate-forme iOS, tous les navigateurs doivent être construits sur le moteur de rendu WebKit. Pour Chromium, cela signifie prendre en charge à la fois WebKit et Blink, le moteur de rendu de Chrome pour d'autres plates-formes. Cela a créé des complexités supplémentaires que nous voulions éviter de placer dans la base de code Chromium.

Compte tenu de l'engagement de Chrome envers le code open source, nous avons passé beaucoup de temps au cours des dernières années à apporter les modifications nécessaires pour mettre en amont le code de Chrome pour iOS dans Chromium. Aujourd'hui, cette mise en amont est terminée et les développeurs peuvent compiler la version iOS de Chromium comme ils le peuvent pour les autres versions de Chromium. La vitesse de développement est également plus rapide maintenant que tous les tests pour Chrome pour iOS sont disponibles pour l'ensemble de la communauté Chromium et s'exécutent automatiquement chaque fois que le code est enregistré.

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

Premier grand pas ? :]

Mais cela ne veut rien dire puisque le chrome n'est pas autorisé à mettre sur Apple Store.

Mais dans Android, c'est vraiment nécessaire maintenant.

Développer avec cordova et la vue Web par défaut est un enfer, et Intel avait abandonné Crosswalk, qui est le port d'Intel de la vue Web chromée comme vue Web par défaut pour Android.
https://crosswalk-project.org/blog/crosswalk-final-release.html

Problèmes:

• La vue Web par défaut n'est pas fiable grâce à différents fournisseurs qui font des choses différentes. Elle n'est pas stable jusqu'à la version 6.0 d'Android, qui n'est utilisée que par 20 % des téléphones.
• tout le monde ne fait pas de mises à jour de firmware ou de packages Android, en particulier dans les zones à bande passante restreinte avec la 3G coûteuse.

Ce que nous pouvons faire:

• Les API Electron sont impossibles à porter sur chrome (comme @zcbenz l'a dit en 2014)
• chromuim pour Android et chromium webview pour Android sont maintenant entièrement open source : https://www.chromium.org/developers/how-tos/android-build-instructions
• Nous pouvons bifurquer et continuer à maintenir le passage pour piétons (qui est essentiellement un port de chrome vers Android avec moins de restrictions) https://github.com/crosswalk-project , il est déjà assez stable.
• Notre expérience montre que crosswalk et cordova avec un bon framework JS donnent des performances quasi-natives (Emberjs / React / Angular /Vue).
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

nous avons besoin de contributeurs et de mainteneurs dans crosswalk , c'est peut-être celui que vous recherchez.

Bonnes nouvelles

Actualité pertinente, nouveau portage de Node.js vers iOS par @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/

donc le seul effort qui devrait être fait est de s'assurer que les navigateurs mobiles prennent en charge l'électron s'il est émulé via le lien que @mikeal a posté ?

Est-il légal d'expédier d'autres VM JS sur iOS de nos jours ? Ou Apple exige-t-il toujours que vous utilisiez le leur ?

@trusktr expédiant des machines virtuelles qui ne génèrent pas de code exécutable n'enfreint pas les directives de l'App Store. Nous avons déjà fait approuver une telle application dans l'App Store (bien qu'en utilisant SpiderMonkey et non ChakraCore).

Pouvons-nous rouvrir ce problème pour poursuivre la discussion sur la question de savoir si Electron aura un cadre mobile pris en charge à l'avenir ?

Je seconde ceci. Que faut-il faire ? Je suis heureux de commencer à tester ou à pirater cela avec un peu de direction.

@OtterCode serait-il judicieux de créer un référentiel appelé electron-mobile et de commencer à le pirater ? Je pouvais voir une étape nécessaire de planification et de préparation d'exemples d'applications pour commencer à comprendre ce qui doit être fait. Existe-t-il une bibliothèque API de niveau supérieur pour les électrons que nous pourrions émuler pour commencer ? (Documents API, cibles de construction, etc.)

@OtterCode et toute personne intéressée que j'ai créée, https://github.com/gabrielcsapo/electron-mobile , si quelqu'un est intéressé, je peux vous ajouter en tant que propriétaire et nous pouvons commencer à travailler sur une voie à suivre pour la construction iOS et Android cibles pour l'électron.

Produits tels que Samsung Dex, http://www.samsung.com/global/galaxy/apps/samsung-dex/
Faites-en une demande viable IMO (au moins pour Android).

C'est certainement très faisable. L'application "Termux" de Google Play, par exemple, nous donne un terminal complet basé sur Debian directement dans l'application. Nous pouvons apt-get install tout ce dont nous avons besoin (Node, Vim, Git, etc., tant que la chose que nous installons prend en charge l'architecture CPU de l'appareil). Il est tout à fait possible de faire fonctionner Electron dans son propre environnement d'application en bac à sable similaire à Termux.

Termux fonctionne sans rooter nos téléphones, il installe tout dans le bac à sable de l'application, et nous pouvons même créer un lien symbolique entre notre stockage externe et notre "dossier personnel" dans Termux et travailler dans notre stockage externe en utilisant tous les outils de ligne de commande que Termux nous donne.

Nous pouvons ouvrir les applications Node.js dans notre navigateur, sur localhost, servi directement depuis Termux.

Il est tout à fait possible de faire quelque chose comme ça avec Electron.

J'espère vraiment que cela se produira, j'ai utilisé ElectronJS pour mon projet précédent qui était un système informatisé autonome basé sur un ordinateur de bureau. Electron était extrêmement génial, maintenant une entreprise veut m'embaucher et ils veulent créer des applications mobiles, ils envisagent d'utiliser PhoneGap pour cela car ils ne veulent pas supporter la peine d'avoir plusieurs équipes pour différentes plates-formes (iOS/Android) , avoir une solution unique est extrêmement génial, et j'espère qu'ElectronJS pourra avoir une version qui prend en charge le mobile afin que je n'aie pas à basculer entre différentes plates-formes et langues, c'est vraiment fatiguant parfois.

react-native n'est pas une solution permanente à ce problème

@aprilmintacpineda avez-vous déjà étudié les Progressive Web Apps ? https://developers.google.com/web/progressive-web-apps/

@Serkan-devel oui, je n'étais pas au courant des applications Web progressives lorsque j'ai vu ce problème ici. J'ai décidé d'utiliser React-native à la place.

@aprilmintacpineda , vous pouvez toujours essayer les PWA, https://youtube.com/watch?v=vhg01Ml-8pI . Cela aide également sur le bureau

Comment intégrer nodejs-mobile avec Chromium ? Cela semble être la solution la plus proche pour amener Node sur mobile dans un environnement de navigateur, similaire à ce qu'Electron a fait pour le bureau.

(Je suis conscient de ce que les PWA peuvent faire aujourd'hui , et il existe des frameworks tels que Cordova pour intégrer des applications Web dans des applications mobiles, mais les PWA ne peuvent pas accéder aux systèmes de fichiers au niveau du système d'exploitation ou intégrer des serveurs HTTP, et Cordova n'est qu'une exagération pour mon projet actuel, sans parler des processus de configuration et de construction pour Android et iOS.)

Un ensemble distribuable de navigateur intégré à Node pour mobile aurait rendu le développement aussi simple que le développement d'applications de bureau avec Electron, ce qui, je crois, a rendu Electron si populaire. Une grande partie du code serait également réutilisable au lieu d'écrire un code complètement différent pour le mobile.

Je suis un développeur Web et je n'ai pas l'expertise nécessaire pour créer des applications système/natives, et encore moins intégrer un navigateur complexe avec Node, donc tout pointeur serait grandement apprécié. Si vous avez l'expertise et que vous voulez aider à créer un tel projet, vous êtes plus que bienvenu pour y contribuer.

Bien qu'il soit possible d'y parvenir, je pense que nous devrions réfléchir à deux fois si nous devons vraiment le faire. Sur l'application de bureau où j'utilisais Electron, j'ai connu des décalages, en particulier avec les animations CSS. S'il y a une option native, je préfère opter pour le natif, le natif a beaucoup à offrir. Ou essayez peut-être PWA. C'est génial, mais pas ENCORE un remplacement pour les applications, mais je pense qu'il a un grand avenir.

marque

https://github.com/dna2github/dna2oslab

le nodejs qui peut bien fonctionner sur android

Ce n'est pas exactement comme Electron, mais pour quiconque souhaite créer des applications Android avec Node.js, cette bibliothèque semble bien fonctionner lors de mes tests.