Electron: Soporte móvil

Creo que atom-shell se creó principalmente para el editor de texto atom, por lo que no esperaría que sea compatible con plataformas móviles. Hay Phonegap y Cordova para aplicaciones móviles HTML5.

Sí, pero se trata de compartir código de módulos node.js y acceder a recursos de bajo nivel

Para la plataforma móvil, casi todas las API de atom-shell no se aplican, por lo que no creo que alguna vez admitamos plataformas móviles.

Tal vez puedan al menos jugar bien con Cordova, etc., detectando (de alguna manera) el entorno (en tiempo de ejecución o especificado durante la compilación) para que las API de Electron simplemente llamen a los módulos de Cordova (o código nativo) sin que lo sepamos. Eso sería increíblemente increíble.

+1 @trusktr

@trusktr Suena como un excelente módulo de terceros que proporcionaría compatibilidad con Cordova

Realmente espero que esto pase. Creo que el futuro de la plataforma web debe moverse en esta dirección, para que podamos escribir VERDADERAMENTE aplicaciones multiplataforma. Realmente espero que esto no se descarte.

No puedo creer que ya sea 2016 y todavía no exista tal cosa.

@emin93 esto no es constructivo, como ya señaló @zcbenz , sería casi imposible portar las API de Electron a dispositivos móviles.
No puede simplemente exigir funciones sin al menos algún tipo de sugerencia sobre cómo hacer que suceda.

@YuriSolovyov No me refiero directamente a Electron. En realidad, no hay alternativas y eso es lo que me frustra. Pero sí, tienes razón, en realidad ese no es el lugar adecuado para discutir eso.

Electron para móviles sería genial. Tengo algunas aplicaciones Electron desarrolladas y me encanta el marco, pero todos los días deseo que lo veamos funcionar también en dispositivos móviles.

El único marco multiplataforma que muestra soporte multiplataforma de extremo a extremo (IOS, Android, Windows, OSX, Linux) es Xamarin , pero requiere codificar en C#. No me sorprendería si Xamarin permite el código JS pronto, ya que Microsoft ahora posee Xamarin y también ha hecho grandes avances con la migración del nodo a su propio motor JS.

Realmente espero que algunos patrocinadores corporativos puedan unirse para financiar un puerto / bifurcación de electrones para dispositivos móviles que eventualmente se integraría en el mismo marco para que podamos tener un marco completo de desarrollo de aplicaciones multiplataforma basado en JS.

¡Gracias al equipo de Electron por su gran trabajo!

Haciéndose eco de la pregunta original de @cjfromthesea , ¿alguien puede explicar los problemas que existen con las API de Electron en dispositivos móviles (quizás @zcbenz)? Con alguna orientación general, yo mismo y otros podemos potencialmente comenzar a pensar en formas de solucionar los problemas pirateando y modificando. He tratado un poco con jxcore-cordova, pero estaría bien alguna orientación. ¿Cuáles son los obstáculos?

@lastmjs un gran obstáculo es que Electron usa V8 que no es compatible con iOS. Esto significa que Chromium y Node.js tampoco funcionarán en iOS y estos tres son los componentes principales de Electron.

En enero se lanzó una nueva versión de Chrome para IOS, y node.app quizás podría hacer el truco para node.js. Y Android no debería ser un problema dado que V8 es compatible.
Mientras tanto, podríamos escribir una documentación sobre cómo usar Cordova con electron para iOS (ya que realmente los necesito, me encantaría ayudar).

@noelmace Chrome para iOS no usa el motor Chromium ya que Apple no lo permite. Es solo WKWebView como lo usa Safari, pero con una interfaz de usuario diferente.

@ emin93 ¿Aplicar permite usar cualquier intérprete personalizado como node.app?

Tenía algunas preguntas sobre las que me encantaría que las personas de este hilo respondieran:

• ¿Está buscando crear _una aplicación que se ejecute en todas partes_?
  
  
  
  • Pregunta de seguimiento, ¿hay ejemplos de aplicaciones de escritorio (que no son aplicaciones web) que también son aplicaciones móviles?
  
  
• ¿ O está buscando la experiencia de creación de aplicaciones de Electron pero en dispositivos móviles?
  
  
  
  • Pregunta de seguimiento, ¿en qué se diferenciaría de Cordova/PhoneGap (u otros)?
  
  

Definitivamente estoy buscando una aplicación que pueda ejecutarse en todas partes. Una base de código, una plataforma web, cualquier entorno.

Ejemplos de buenas aplicaciones móviles/de escritorio/web, donde el tamaño de la pantalla y el dispositivo realmente no importan, pero es posible que desee la misma funcionalidad:

• Cromo
• Firefox
• Flojo
• Gmail
• Fotos de Google
• mapas de Google

No todas las aplicaciones anteriores necesariamente tienen una versión de escritorio que se ejecuta con un ejecutable nativo, pero tienen una versión de escritorio en el navegador. Para mí, por supuesto, depende de cada caso, pero generalmente quiero que mi aplicación sea mi aplicación sin importar en qué dispositivo esté. Me esfuerzo por tener las mismas características en todos los dispositivos tanto como sea posible. ¿Por qué no? Quiero que Chrome funcione igual en mi escritorio que en mi Android, mi iPhone o mi tableta, lo mismo para Firefox, Slack, Google Maps. Me entristece que, a veces, las funciones de Google Maps sean específicas de la plataforma. Volviendo a Chrome, quiero poder ver la fuente e incluso usar el depurador, incluso en mi teléfono. A veces pienso que no tenemos la previsión de limitar adecuadamente la funcionalidad de nuestras aplicaciones. ¿Qué pasa si alguien quiere una función que funcione en la versión de escritorio de la aplicación en su teléfono? Por supuesto, las aplicaciones deben ser receptivas, pero en mi opinión, la funcionalidad principal debe permanecer igual en la medida de lo posible.

Gracias @lastmjs. Acabo de editar mi pregunta porque lo que estaba pensando, pero no había especificado, eran aplicaciones de escritorio que también son aplicaciones móviles pero no son aplicaciones web. Creo que esta es una distinción importante.

pero, en mi opinión, la funcionalidad principal debe seguir siendo la misma en la medida de lo posible.

Pensando en voz alta aquí: Electron crea una API para los comportamientos comunes de las aplicaciones de escritorio nativas; parece que si también agrega dispositivos móviles, el terreno común entre todos estos se reduciría. Una aplicación basada en el terreno común entre el escritorio y el dispositivo móvil podría al final funcionar en todas partes, pero ¿ser una experiencia móvil por debajo de la media y una experiencia de escritorio por debajo de la media?

¿Los comportamientos comunes de las aplicaciones de escritorio nativas de los que está hablando se basan principalmente en la interfaz de usuario? Puedo ver cómo los menús nativos y otros comportamientos pueden no traducirse bien. El mayor beneficio para mí sería tener un tiempo de ejecución consolidado, donde tengo acceso a las API de Node.js y Chromium, y dicho tiempo de ejecución se puede implementar en todas las plataformas principales. Electron y Cordova están haciendo lo mismo para diferentes plataformas, menos la funcionalidad de la interfaz de usuario de la que puede haber estado hablando. Con Cordova, tiene una base de código que se puede implementar en algunos de los principales sistemas operativos móviles, dichos sistemas operativos móviles no son muy diferentes en funcionalidad de los principales sistemas operativos de escritorio. Un sistema operativo administra los procesos y sus recursos, y otorga acceso al hardware que los procesos puedan necesitar. No hay mucha diferencia fundamental entre los sistemas operativos móviles y de escritorio. Y con los navegadores que comienzan a tener API de hardware, la plataforma web se está volviendo cada vez más universal en su capacidad de implementación en todos los entornos principales. Entonces, tal como lo veo, Cordova y Electron están realizando en gran medida las mismas tareas pero en diferentes sistemas operativos, dichos sistemas operativos no son fundamentalmente diferentes, entonces, ¿por qué no combinarlos? 😃

@jlord

Construyo para dispositivos móviles y de escritorio y me gustaría agregar a los comentarios de @lastmrs y @noelmace

Aquí están mis pensamientos sobre cómo podría funcionar para todos.

La API que expone electron tiene que variar en función de si es móvil o de escritorio. Entonces, es responsabilidad del desarrollador realizar la detección del entorno en tiempo de ejecución (que proporciona la capa de electrones) para llamar a una API diferente según el contexto del entorno.
Una vez más, para ser claros, depende del desarrollador hacer lo correcto.

En cuanto a los aspectos de la interfaz de usuario, nuevamente depende del desarrollador hacer lo correcto. Uso polímero para todos mis proyectos de escritorio y móviles, y depende de mí hacerlo correctamente.
También uso golang para escribir cualquier material compilado que necesito en el escritorio y en el móvil para acceder a cualquier hardware.

En el momento de la compilación, empaqueto para escritorio (amd 64, etc., etc.) y móvil (Android o iOS) donde hago un paquete separado para cada sistema operativo y arquitectura de chip. Hago lo mismo con el electrón. Esto me permite compilar diferencias de tiempo cuando lo necesito porque algunos códigos dependen del hardware.
Todavía puedo incluir el mismo código en todas las compilaciones y rastrear el tiempo de ejecución, y aquí es donde electron me proporcionaría el contexto del entorno.

Lo mejor que esto proporciona son herramientas comunes en tiempo de diseño y tiempo de compilación. Esta es una gran mejora de la productividad para los desarrolladores porque puede instalar electron y ejecutar un script bash de arranque para instalar los bits de iOS y Android y escribir hola mundo y empaquetar e implementar en computadoras de escritorio y dispositivos móviles.

No sabía que el equipo de Google había actualizado Chrome para que iOS fuera multiproceso. Estoy súper emocionada de ver esto.

Si puedo ayudar con algo de esto, con mucho gusto ayudaría.

Esto también sería una gran mejora para muchos de mis proyectos. Uno ya tendría que hacer cambios en la interfaz de usuario en función de si es móvil o no, también podría hacer cualquier otra detección/cambio.

No creo que tener dos API separadas sea una buena idea (@joeblew99). Para el usuario final, creo que sería mejor si Electron hiciera que sus API funcionen sobre Cordova o Node, de modo que el usuario final solo necesite conocer una API (API de Electron). Luego, si algo no está cubierto por la API, los usuarios finales pueden sumergirse en Node o Cordova según sea necesario.

Además, creo que sería importante que Electron defina cómo usar un flujo de trabajo de NPM que funcione en cualquier caso (Cordova o directamente en Node). Es decir, Electron tendría que definir su sistema de compilación para que sea compatible con ambos, usando NPM (y los módulos ES6 también serían útiles) para que los usuarios finales no tengan que preocuparse por cómo compilar para cada uno. El caso de Node ya está manejado, obviamente, pero es posible que deba haber trabajo adicional para que NPM funcione bien en Cordova.

Tenga en cuenta que en Cordova las API de Node.js no están disponibles, por lo que Electron necesitaría polillenar algunos de los módulos nativos de Node.js con alternativas que funcionen en Cordova, de forma similar a lo que hace Browserify para el navegador. Esto ayudaría a crear una API unificada, porque si hay algo que la API de Electron no cubre, al menos las bibliotecas polillenadas significan que el usuario puede recurrir a las API basadas en nodos que, en segundo plano, llaman a las API de Cordova.

La necesidad de polyfill es exactamente lo que creo que es más inteligente para comenzar con la ruta API. No tiene que ser una API separada, solo algunas funciones no están disponibles de inmediato. Si continúa y lo hace 100% compatible, entonces es una bestia mucho más grande con la que lidiar cuando se agregan nuevas funciones en el futuro.

También me gustaría señalar que Android e IOS ya no son solo dispositivos móviles. El proyecto en el que estoy trabajando se vería increíble en un Android TV, además no veo por qué Github no querría hacer que Atom se ejecutara en televisores o tabletas.

Gran punto, ya no se trata del tamaño de la pantalla, estamos empezando a tratar con sistemas operativos de propósito general.

¿Estoy confundido en cuanto al estado de Electron en Android?

¿Es algo que se está considerando activamente o simplemente algo de lo que se habla?

¡Hacer que las aplicaciones Electron sean un objetivo válido para las aplicaciones PhoneGap o Cordova es 1000 veces más fácil!
es decir. cordova platform add electron-osx electron-win electron-linux

@purplecabbage seguro, pero luego pierde todos los beneficios adicionales de controlar toda la pila del navegador.

RE: Node.js Polyfills.

Deberíamos comenzar una lista de los polyfills _nativos_ requeridos para que esto funcione. Browserify ya tiene versiones web puras de un montón de Node.js Core. Los únicos que se me ocurren que necesitaríamos son:

• dns
• net
• fs

¿Algo más?

Objetos globales:

• __dirname
• __nombre del archivo
• proceso

@purplecabbage parece que esos 3 tienen implementaciones browserify. https://github.com/substack/browserify-handbook#__dirname. ¿Deberíamos darles valores diferentes según los dispositivos?

sí, __dirname y __filename no son gran cosa.
El proceso es barebones en browserify, ¿no querríamos admitir eventos?
https://github.com/defunctzombie/node-process/blob/master/browser.js

Para aplicaciones móviles nativas que comparten código con electron.js, creo que lo mejor será explorar la ruta combinando Electron.js con NativeScript: http://github.com/NativeScript/NativeScript.

Nosotros (el equipo de NativeScript) planeamos crear una aplicación de demostración de muestra. Si está interesado, comente este problema: https://github.com/NativeScript/NativeScript/issues/2695

En realidad, ya está disponible la semilla avanzada Angular 2 que permite esto: https://github.com/NathanWalker/angular2-seed-advanced. Pero angular 2 no es de ninguna manera un requisito para implementar este tipo de solución.

¿Es esto algo que tiene sentido?

Creo que la clave es que su equipo ha hecho el trabajo preliminar para agregar las API nativas. Estoy a favor de tu idea.

@valentinstoychev , esa es una idea realmente interesante, aunque básicamente significa que cualquier aplicación de electrones tendrá que rehacer toda la interfaz de usuario, ¿verdad? Sería muy interesante si de alguna manera pudieran incluir libchromiumcontent para crear un webview similar a electron . Entonces sería más fácil usar ambos en una aplicación.

¿Qué pasa con el widget Android WebView y el equivalente en iOS? De hecho el de Android ya es cromo. :)

@hadees sí, la idea es implementar la interfaz de usuario móvil una vez para iOS y Android usando NativeScript y una vez para escritorio usando electron. Todo lo demás: datos, modelos, lógica comercial, servicios, acceso a datos debe ser el mismo.

Hay dos cosas a tener en cuenta aquí.

En primer lugar, usará casi el mismo conjunto de habilidades (lo que significa que un equipo puede hacerlo para escritorio, web y dispositivos móviles) cuando cree con electron.js y NativeScript: todo es JavaScript/TypeScript/CSS. Puedes usar Angular 2 si quieres. Para el estilo, utilizará CSS tanto para NativeScript como para electron. _Por lo general, lo único que será diferente es el marcado de la interfaz de usuario_. Incluso el diseño debería ser familiar ya que lanzaremos el diseño de FlexBox el próximo mes. Todo lo demás es código reutilizable y, lo que es más importante, un conjunto de habilidades reutilizable. La parte de las herramientas también debería ser familiar, ya que en NativeScript estamos usando Chrome Devtools...

La segunda cosa a tener en cuenta aquí es que en realidad desea tener una interfaz de usuario diferente para dispositivos móviles y de escritorio, ¿verdad? Por lo tanto, en muchos/la mayoría de los casos, la parte de la interfaz de usuario no se reutilizará de todos modos y debería ser diferente.

Creo que esta es una historia bastante convincente y la exploraremos y mostraremos un ejemplo de la vida real muy pronto. Espero que ver el código real y la aplicación real ayude a aclarar un poco si vale la pena explorarlo o no.

En cualquier caso, la aplicación (o aplicaciones) final tendrá una interfaz de usuario nativa en todas partes. Y creo que esto es lo que hace que esta solución sea única y que valga la pena explorarla. También es barato ser pirateado porque no es necesario realizar cambios tanto en electron.js como en NativeScript. A partir de esta primera solución, podemos encontrar áreas donde puede existir una colaboración más estrecha.

He usado polímero para la GUI de escritorio y móvil, con Cordova. Córdoba
es compatible con escritorio y móvil.

La clave para mí fue usar grpc como tecnología de enlace. Esto hizo mucho
más fácil porque los clientes y los servidores pueden interoperar.

Para todos, solo necesitaba un complemento de proxy grpc para actuar como intermediario

El sábado 10 de septiembre de 2016 a las 08:17 Valentin Stoychev, [email protected]
escribió:

@hadees https://github.com/hadees sí, la idea es implementar el
interfaz de usuario móvil una vez para iOS y Android usando NativeScript y una vez para escritorio
utilizando electrones. Todo lo demás: datos, modelos, lógica empresarial, servicios,
el acceso a los datos debe ser el mismo.

Hay dos cosas a tener en cuenta aquí.

Primero, usará casi el mismo _skillset_ (significa que un equipo puede
hacerlo para escritorio, web y móvil) al compilar con electron.js y
NativeScript: todo es JavaScript/TypeScript/CSS. Puedes usar Angular 2
Si te gusta. Para el estilo, usará CSS tanto para NativeScript como para
electrón. _Por lo general, lo único que será diferente es la interfaz de usuario
margen_. Incluso el diseño debería ser familiar ya que estamos lanzando FlexBox
diseño el próximo mes. Todo lo demás es código reutilizable y lo más importante
conjunto de habilidades reutilizables.

La segunda cosa a tener en cuenta aquí es que en realidad desea tener diferentes
Interfaz de usuario para dispositivos móviles y de escritorio, a la derecha. Entonces, en muchos/la mayoría de los casos, la interfaz de usuario
la parte no se reutilizará de todos modos y debería ser diferente.

Creo que esta es una historia bastante convincente y la exploraremos y
mostrar un ejemplo de la vida real muy pronto. Espero ver el código real y
La aplicación real ayudará a aclarar un poco si vale la pena explorarla o no.

En cualquier caso, la aplicación (o aplicaciones) final tendrá una interfaz de usuario nativa en todas partes.
Y creo que esto es lo que hace que esta solución sea única y que valga la pena explorarla. Eso
también es barato ser pirateado porque no es necesario realizar cambios en
tanto electron.js como NativeScript. Partiendo de esta primera solución,
puede encontrar áreas donde puede existir una colaboración más estrecha.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/electron/electron/issues/562#issuecomment-246093147 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript no es realmente una opción para el soporte móvil de Electron, porque
cambia completamente el paradigma de la tecnología web a JavaScript
enlaces para widgets nativos. En esencia, lo que tendremos ya no sería
"Electron", porque Electron en su núcleo es una pila de navegador que expone
Node.js _dentro_ de un contexto de navegador, y eso es lo que hace que Electron
Electrón.

Los enlaces NativeScript + Node.js se pueden considerar completamente diferentes
proyecto.

En primer lugar, usará casi el mismo conjunto de habilidades (lo que significa que un equipo puede hacerlo para escritorio, web y dispositivos móviles) cuando cree con electron.js y NativeScript: todo es JavaScript/TypeScript/CSS.

No es necesariamente cierto, porque con NativeScript debes tener algunos
comprensión de cómo se comportan los widgets nativos, independientemente del hecho de que
estás codificando en JavaScript. Esto significa que sin el conocimiento de la
widgets, y sin saber cómo modificar esos enlaces de widgets con
código nativo, entonces hacer algo personalizado se vuelve muy difícil, lo cual es
no es el caso con JS/HTML/CSS puro en una pila web, porque con una pila web
modificar las partes internas significa modificar el mismo tipo de código en el mismo entorno en el que ya se encuentra, sin tener que preocuparse por un idioma extranjero.

La segunda cosa a tener en cuenta aquí es que en realidad desea tener una interfaz de usuario diferente para dispositivos móviles y de escritorio, ¿verdad? Por lo tanto, en muchos/la mayoría de los casos, la parte de la interfaz de usuario no se reutilizará de todos modos y debería ser diferente.

Uno de los beneficios de usar Electron (con su front-end basado en la Web), es
que escribimos un código, y se comporta casi _exactamente igual_
En todas partes. Este no sería siempre el caso con NativeScript, que
trata de unir conjuntos de tecnologías completamente diferentes con un solo idioma.

Personalmente, me gusta mucho más la idea de usar una interfaz de usuario web en todas partes,
frente a diferentes interfaces de usuario nativas en todas partes. Algunas personas creen que las interfaces de usuario nativas
son mucho mejores que las interfaces de usuario web. Es cierto hasta cierto punto, y es el caso
con desarrolladores que no conocen todos los fundamentos de la web. Pero con
uso adecuado de las API web, de hecho, podemos hacer buenas interfaces de usuario. La web se está haciendo enorme
Progreso. WebGL es enormemente multiplataforma...

_/#!/_JoePea

El viernes 9 de septiembre de 2016 a las 23:17, Valentin Stoychev < [email protected]

escribió:

@hadees https://github.com/hadees sí, la idea es implementar el
interfaz de usuario móvil una vez para iOS y Android usando NativeScript y una vez para escritorio
utilizando electrones. Todo lo demás: datos, modelos, lógica empresarial, servicios,
el acceso a los datos debe ser el mismo.

Hay dos cosas a tener en cuenta aquí.

Primero, usará casi el mismo _skillset_ (significa que un equipo puede
hacerlo para escritorio, web y móvil) al compilar con electron.js y
NativeScript: todo es JavaScript/TypeScript/CSS. Puedes usar Angular 2
Si te gusta. Para el estilo, usará CSS tanto para NativeScript como para
electrón. _Por lo general, lo único que será diferente es la interfaz de usuario
margen_. Incluso el diseño debería ser familiar ya que estamos lanzando FlexBox
diseño el próximo mes. Todo lo demás es código reutilizable y lo más importante
conjunto de habilidades reutilizables.

La segunda cosa a tener en cuenta aquí es que en realidad desea tener diferentes
Interfaz de usuario para dispositivos móviles y de escritorio, a la derecha. Entonces, en muchos/la mayoría de los casos, la interfaz de usuario
la parte no se reutilizará de todos modos y debería ser diferente.

Creo que esta es una historia bastante convincente y la exploraremos y
mostrar un ejemplo de la vida real muy pronto. Espero ver el código real y
La aplicación real ayudará a aclarar un poco si vale la pena explorarla o no.

En cualquier caso, la aplicación (o aplicaciones) final tendrá una interfaz de usuario nativa en todas partes.
Y creo que esto es lo que hace que esta solución sea única y que valga la pena explorarla. Eso
también es barato ser pirateado porque no es necesario realizar cambios en
tanto electron.js como NativeScript. Partiendo de esta primera solución,
puede encontrar áreas donde puede existir una colaboración más estrecha.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/electron/electron/issues/562#issuecomment-246093147 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr Estoy totalmente de acuerdo. Creo que los desarrolladores ponen demasiado énfasis en parecer nativo. Nativo ni siquiera es un ideal consistente. En la última década, las interfaces móviles han cambiado docenas de veces y ni siquiera son consistentes de un teléfono Android a otro.

Hacer que su aplicación se vea consistente en todas las plataformas desde las que un usuario puede acceder a ella es un estándar mucho mejor para mantener. Hacer que aprendan dos conjuntos de símbolos y señales de la interfaz de usuario solo para operar una aplicación tanto en su iPhone como en su máquina de trabajo con Windows es terrible.

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

Históricamente, el código de Chrome para iOS se mantuvo separado del resto del proyecto Chromium debido a la complejidad adicional requerida por la plataforma. Después de años de refactorización cuidadosa, todo este código se reincorpora a Chromium y se traslada al repositorio de código abierto.

Debido a las limitaciones de la plataforma iOS, todos los navegadores deben construirse sobre el motor de renderizado WebKit. Para Chromium, esto significa admitir tanto WebKit como Blink, el motor de renderizado de Chrome para otras plataformas. Eso creó algunas complejidades adicionales que queríamos evitar colocar en la base de código de Chromium.

Dado el compromiso de Chrome con el código fuente abierto, dedicamos mucho tiempo durante los últimos años a realizar los cambios necesarios para transmitir el código de Chrome para iOS a Chromium. Hoy, esa actualización está completa y los desarrolladores pueden compilar la versión iOS de Chromium como pueden hacerlo con otras versiones de Chromium. La velocidad de desarrollo también es más rápida ahora que todas las pruebas de Chrome para iOS están disponibles para toda la comunidad de Chromium y se ejecutan automáticamente cada vez que se registra el código.

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

¿Primer gran paso? :]

Pero eso no significa nada ya que el cromo no está permitido en Apple Store.

Pero en Android, es muy necesario ahora.

Desarrollar con Cordova y la vista web predeterminada es un infierno, e Intel había descartado Crosswalk, que es el puerto de Chrome WebView de Intel como vista web predeterminada para Android.
https://crosswalk-project.org/blog/crosswalk-final-release.html

Problemas:

• La vista web predeterminada no es confiable gracias a diferentes proveedores que hacen cosas diferentes. No es estable hasta 6.0 de Android, que es solo el 20% de los teléfonos que usan.
• No todo el mundo está haciendo actualizaciones de paquetes o firmware de Android, especialmente en áreas con ancho de banda restringido con 3G costoso.

Lo que podemos hacer:

• Las API de electrones son imposibles de portar a Chrome (como dijo @zcbenz en 2014)
• chromuim para Android y chromium webview para Android ahora son completamente de código abierto: https://www.chromium.org/developers/how-tos/android-build-instructions
• Podemos bifurcarnos y continuar manteniendo el paso de peatones (que es básicamente un puerto de cromo para Android con menos restricciones) https://github.com/crosswalk-project , ya es bastante estable.
• Nuestra experiencia muestra que crosswalk y cordova con un buen marco JS brindan un rendimiento casi nativo (Emberjs/React/Angular/Vue).
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

necesitamos colaboradores y mantenedores en cruce de peatones, ese podría ser uno de los que está buscando.

Buenas noticias

Noticias relevantes, nuevo puerto de Node.js a iOS por @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/

Entonces, ¿el único esfuerzo que se debe hacer es asegurarse de que los navegadores móviles admitan electron si se emulan a través del enlace que publicó @mikeal ?

¿Es legal enviar otras máquinas virtuales JS en iOS hoy en día? ¿O Apple todavía requiere que uses el suyo?

@trusktr enviar máquinas virtuales que no generan código ejecutable no infringe las pautas de la tienda de aplicaciones. Ya hemos aprobado una aplicación de este tipo en la tienda de aplicaciones (aunque usamos SpiderMonkey y no ChakraCore).

¿Podemos reabrir este problema para continuar la discusión sobre si electron tendrá un marco móvil compatible en el futuro?

Secundo esto. ¿Qué necesita hacer? Estoy feliz de comenzar a probar o piratear esto con un poco de dirección.

@OtterCode , ¿tendría sentido crear un repositorio llamado electron-mobile y comenzar a piratear allí? Pude ver un paso necesario de planificación y preparación de aplicaciones de ejemplo para comenzar a descubrir qué se debe hacer. ¿Existe una biblioteca API de mayor nivel para electrones que podamos emular para comenzar? (Api docs, compilar objetivos, etc.)

@OtterCode y cualquier persona interesada que he creado, https://github.com/gabrielcsapo/electron-mobile , si alguien está interesado, puedo agregarlo como propietario y podemos comenzar a trabajar en un camino a seguir para la compilación de iOS y Android blancos para electrones.

Productos como Samsung Dex, http://www.samsung.com/global/galaxy/apps/samsung-dex/
Haga de esta una solicitud viable en mi opinión (al menos para Android).

Esto es definitivamente muy factible. La aplicación "Termux" de Google Play, por ejemplo, nos brinda un terminal completo basado en Debian directamente en la aplicación. Podemos apt-get install cualquier cosa que necesitemos (Node, Vim, Git, etc., siempre que lo que estemos instalando sea compatible con la arquitectura de CPU del dispositivo). Es completamente posible hacer que Electron se ejecute en su propio entorno de espacio aislado de aplicaciones similar a Termux.

Termux funciona sin rootear nuestros teléfonos, instala todo dentro de la caja de arena de la aplicación, e incluso podemos vincular nuestro almacenamiento externo a nuestra "carpeta de inicio" dentro de Termux y trabajar en nuestro almacenamiento externo usando todas las herramientas de línea de comando que Termux nos brinda.

Podemos abrir aplicaciones Node.js en nuestro navegador, en localhost, servidas directamente desde Termux.

Definitivamente es posible hacer algo como esto con Electron.

Realmente espero que esto suceda, he usado ElectronJS para mi proyecto anterior, que era un sistema computarizado de escritorio independiente. Electron fue extremadamente bueno, ahora una empresa quiere contratarme y quieren crear aplicaciones móviles, están pensando en usar PhoneGap porque no quieren tener la molestia de tener varios equipos para diferentes plataformas (iOS/Android) , tener una solución única para todos es extremadamente bueno, y espero que ElectronJS pueda tener una versión compatible con dispositivos móviles para no tener que cambiar entre diferentes plataformas e idiomas, a veces es realmente agotador.

react-native no es una solución permanente para este problema

@aprilmintacpineda , ¿ya ha investigado las aplicaciones web progresivas? https://developers.google.com/web/progressive-web-apps/

@Serkan-devel sí, no estaba al tanto de las aplicaciones web progresivas cuando vi este problema aquí. Decidí usar react-native en su lugar.

@aprilmintacpineda , también puedes probar las PWA, https://youtube.com/watch?v=vhg01Ml-8pI . También ayuda en el escritorio.

¿Cómo se integra nodejs-mobile con Chromium ? Esta parece ser la solución más cercana para llevar Node a dispositivos móviles en un entorno de navegador, similar a lo que Electron ha hecho para computadoras de escritorio.

(Soy consciente de lo que pueden hacer las PWA hoy en día , y existen marcos como Cordova para envolver aplicaciones web en aplicaciones móviles, pero las PWA no pueden acceder a los sistemas de archivos a nivel del sistema operativo o incrustar servidores HTTP, y Cordova es simplemente una exageración para mi proyecto actual, sin mencionar los procesos de configuración y compilación para Android e iOS).

Un paquete distribuible de navegador integrado en Node para dispositivos móviles habría hecho que el desarrollo fuera tan fácil como desarrollar aplicaciones de escritorio con Electron, que creo que es lo que hizo que Electron fuera tan popular. Una gran cantidad de código también sería reutilizable en lugar de escribir un código completamente diferente para dispositivos móviles.

Soy desarrollador web y no tengo la experiencia en la creación de aplicaciones nativas/de sistema, y ​​mucho menos en la integración de un navegador complejo con Node, por lo que agradecería mucho cualquier sugerencia. Si tiene la experiencia y desea ayudar a crear dicho proyecto, es más que bienvenido a contribuir.

Si bien esto es posible de lograr, creo que deberíamos pensarlo dos veces si realmente deberíamos hacer esto. En la aplicación de escritorio donde usé electron, experimenté retrasos, especialmente con animaciones css. Si hay una opción nativa, prefiero optar por la nativa, la nativa tiene mucho que ofrecer. O tal vez pruebe PWA. Es increíble, pero AÚN no es un reemplazo para las aplicaciones, pero creo que tiene un gran futuro.

marca

https://github.com/dna2github/dna2oslab

los nodejs que pueden funcionar bien en android

No es exactamente como Electron, pero para cualquiera que quiera crear aplicaciones de Android con Node.js, esta biblioteca parece funcionar bien en mis pruebas.