Electron: Suporte móvel

Eu acho que o atom-shell foi construído principalmente para o editor de texto do atom, então eu não esperaria que ele suportasse plataformas móveis. Existem Phonegap e Cordova para aplicativos móveis HTML5.

Sim, mas trata-se de compartilhar código de módulos node.js e acessar recursos de baixo nível

Para plataforma móvel, quase todas as APIs do atom-shell não se aplicam, então acho que nunca daremos suporte a plataformas móveis.

Talvez vocês possam pelo menos jogar bem com o Cordova, etc, detectando (de alguma forma) o ambiente (em tempo de execução ou especificado durante a compilação) para que as APIs do Electron simplesmente chamem os módulos do Cordova (ou código nativo) sem que saibamos. Isso seria insanamente incrível.

+1 @trusktr

@trusktr Parece um ótimo módulo de terceiros que forneceria calços de compatibilidade para o Cordova

Eu realmente espero que isso aconteça. Acho que o futuro da plataforma web precisa se mover nessa direção, para que possamos escrever aplicativos VERDADEIRAMENTE multiplataforma. Eu realmente espero que isso não seja descartado.

Eu não posso acreditar que já é 2016 e ainda não existe tal coisa.

@emin93 isso não é construtivo, como já apontado por @zcbenz , seria quase impossível portar APIs do Electron para dispositivos móveis.
Você não pode simplesmente exigir recursos sem pelo menos algum tipo de sugestão sobre como fazer isso acontecer.

@YuriSolovyov Não estou me referindo diretamente ao Electron. Na verdade, não há alternativas e é isso que me deixa frustrado. Mas sim, você está certo, esse não é o lugar certo para discutir isso.

Electron para celular seria tão incrível. Eu tenho alguns Electron Apps desenvolvidos e amo o framework, mas todos os dias eu gostaria de vê-lo funcionar no Mobile também.

A única estrutura de plataforma cruzada que mostra suporte de plataforma cruzada de ponta a ponta (IOS, Android, Windows, OSX, Linux) é o Xamarin , mas isso requer código em C#. Eu não ficaria surpreso se o Xamarin permitir o código JS assim que a Microsoft agora possui o Xamarin e também está fazendo grandes avanços com a portabilidade do nó para seu próprio mecanismo JS.

Eu realmente espero que alguns patrocinadores corporativos possam embarcar para financiar tal porta / bifurcação de elétron para dispositivos móveis que eventualmente seria incorporada à mesma estrutura para que possamos ter uma estrutura de desenvolvimento de aplicativos multiplataforma completa baseada em JS.

Obrigado equipe Electron por seu ótimo trabalho!

Ecoando a pergunta original de @cjfromthesea , alguém pode explicar os problemas que existem com as APIs do Electron no celular (talvez @zcbenz)? Com alguma orientação geral, eu e outros podemos potencialmente começar a pensar em maneiras de contornar os problemas hackeando e consertando. Eu lidei um pouco com o jxcore-cordova, mas algumas orientações seriam boas. Quais são os obstáculos?

@lastmjs um grande obstáculo é que o Electron usa o V8, que não é suportado no iOS. Isso significa que o Chromium e o Node.js também não funcionarão no iOS e esses três são os principais componentes do Electron.

Uma nova versão do chromium para IOS foi lançada em janeiro, e o node.app talvez possa fazer o truque para o node.js. E o Android não deve ser um problema, já que o V8 é suportado.
Nesse meio tempo, poderíamos escrever uma documentação sobre como usar Cordova com electron para IOS (como eu realmente preciso disso, ficaria feliz em ajudar).

@noelmace Chrome para iOS não usa o mecanismo Chromium, pois a Apple não permite isso. É apenas o WKWebView como o Safari o usa, mas com uma interface de usuário diferente.

@emin93 O Apply permite o uso de qualquer interpretador personalizado como node.app?

Eu tinha algumas perguntas sobre as quais adoraria pensar neste tópico—

• Você deseja criar _um aplicativo que funcione em todos os lugares_?
  
  
  
  • Pergunta de acompanhamento, existem exemplos de aplicativos de desktop (que não são aplicativos da Web) que também são aplicativos móveis?
  
  
• Ou você está procurando o aplicativo Electron construindo _experiência_, mas no celular?
  
  
  
  • Pergunta de acompanhamento, como isso seria diferente do Cordova/PhoneGap (ou outros)?
  
  

Definitivamente, estou procurando um aplicativo que possa ser executado em todos os lugares. Uma base de código, uma plataforma web, qualquer ambiente.

Exemplos de bons aplicativos móveis/desktop/web, onde o tamanho da tela e o dispositivo não importam, mas você pode querer a mesma funcionalidade:

• cromada
• Raposa de fogo
• Folga
• Gmail
• Google Fotos
• Google Maps

Nem todos os aplicativos acima necessariamente têm uma versão de desktop executada com um executável nativo, mas eles têm uma versão de desktop no navegador. Para mim, é claro que depende caso a caso, mas geralmente quero que meu aplicativo seja meu aplicativo, independentemente do dispositivo em que estiver. Eu me esforço para obter os mesmos recursos em todos os dispositivos, tanto quanto possível. Por que não? Quero que o Chrome funcione na minha área de trabalho da mesma forma que no meu Android, iPhone ou tablet, o mesmo para Firefox, slack, Google Maps. Acho triste quando, às vezes, os recursos do Google Maps são específicos da plataforma. De volta ao Chrome, quero poder ver o código-fonte e até usar o depurador, mesmo no meu telefone. Às vezes acho que não temos a previsão de limitar a funcionalidade de nossos aplicativos adequadamente. E se alguém quiser um recurso que funcione na versão desktop do aplicativo em seu telefone? Os aplicativos devem ser responsivos, é claro, mas a funcionalidade principal deve permanecer a mesma na minha opinião.

Obrigado @lastmjs. Acabei de editar minha pergunta porque o que eu estava pensando, mas não havia especificado, eram aplicativos de desktop que também são aplicativos móveis, mas não são aplicativos da web. Acho que essa é uma distinção importante.

mas a funcionalidade principal deve permanecer a mesma, tanto quanto possível, na minha opinião

Pensando em voz alta aqui: o Electron cria uma API para comportamentos comuns de aplicativos de desktop nativos - parece que, se você também adicionar dispositivos móveis, o terreno comum entre todos eles diminuirá. Um aplicativo baseado no terreno comum entre desktop e celular pode, no final, funcionar em qualquer lugar, mas ser uma experiência móvel abaixo da média e uma experiência inferior da área de trabalho?

Os comportamentos comuns de aplicativos de desktop nativos dos quais você está falando são baseados principalmente na interface do usuário? Eu posso ver como menus nativos e outros comportamentos podem não traduzir bem. O maior benefício para mim seria ter um runtime consolidado, onde eu teria acesso a Node.js e Chromium APIs, e dito runtime ser implantável em todas as principais plataformas. Electron e Cordova estão de certa forma fazendo a mesma coisa para diferentes plataformas, menos a funcionalidade da interface do usuário, como você pode estar falando. Com o Cordova, você tem uma base de código que pode ser implantada em alguns dos principais sistemas operacionais móveis, sendo que os sistemas operacionais móveis não são muito diferentes em funcionalidade dos principais sistemas operacionais de desktop. Um sistema operacional gerencia processos e seus recursos e concede acesso ao hardware que os processos podem precisar. Não há muita diferença fundamental entre os sistemas operacionais móveis e de desktop. E com os navegadores começando a ter APIs de hardware, a plataforma web está se tornando cada vez mais universal em sua capacidade de implantação em todos os principais ambientes. Então, como eu vejo, Cordova e Electron estão realizando basicamente as mesmas tarefas, mas em sistemas operacionais diferentes, esses sistemas operacionais não sendo fundamentalmente diferentes, então por que não combiná-los? 😃

@jlord

Eu construo para celular e desktop e gostaria de adicionar comentários de @lastmrs e @noelmace

Aqui estão meus pensamentos sobre como isso poderia funcionar para todos.

A API que o elétron expõe tem que variar dependendo se é móvel ou desktop. Portanto, é responsabilidade do desenvolvedor fazer a detecção do ambiente de tempo de execução (que a camada eletrônica fornece) para chamar uma API diferente dependendo do contexto do ambiente.
Mais uma vez, para ser claro, cabe ao desenvolvedor fazer a coisa certa

No que diz respeito aos aspectos da interface do usuário, novamente cabe ao desenvolvedor fazer a coisa certa. Eu uso o polímero para todos os meus projetos de desktop e móveis, e cabe a mim fazê-lo corretamente.
Eu também uso golang para escrever qualquer coisa compilada que eu preciso no desktop e no celular para acessar qualquer hardware.

Em tempo de compilação, faço pacotes para desktop ( amd 64, etc, etc ) e mobile ( android ou iOS) onde faço um pacote separado para cada SO e arquitetura de chip. Eu faço o mesmo com o elétron. Isso me permite compilar diferenças de tempo conforme necessário, pois alguns códigos dependem do hardware.
Ainda posso incluir o mesmo código em todas as compilações e fazer sniffing em tempo de execução, e é aí que o electron me forneceria o contexto do ambiente.

A grande coisa que isso fornece são ferramentas comuns em tempo de design e tempo de compilação. Esta é uma grande melhoria de produtividade para os desenvolvedores porque você pode instalar o electron e executar um script bash de bootstrap para instalar os bits do iOS e do Android e sua escrita hello world e empacotamento e implantação para desktop e dispositivos móveis.

Eu não sabia que a equipe do Google havia atualizado o chrome para iOS para ser multi-processo. Estou super ansiosa para ver isso.

Se eu puder ajudar em alguma dessas coisas, ficarei feliz em ajudar.

Isso seria uma melhoria tão grande para muitos dos meus projetos também. Alguém já teria que fazer alterações na interface do usuário com base no fato de ser móvel ou não, também poderia fazer qualquer outra detecção/alteração.

Não acho que ter duas APIs separadas seja uma boa ideia (@joeblew99). Para o usuário final, acho que seria melhor se o Electron fizesse suas APIs funcionarem em cima do Cordova ou do Node, para que o usuário final só precisasse conhecer uma API (API do Electron). Então, se algo não for coberto pela API, os usuários finais podem mergulhar no Node ou no Cordova conforme necessário.

Além disso, acho que seria importante para o Electron definir como usar um fluxo de trabalho NPM que funcione em ambos os casos (Cordova ou diretamente no Node). Ou seja, a Electron teria que definir seu sistema de compilação para ser compatível com ambos, usando NPM (e módulos ES6 também seriam benéficos) para que os usuários finais não precisassem se preocupar em como compilar para cada um. O caso do Node já foi tratado, obviamente, mas pode ser necessário trabalho adicional para que o NPM funcione bem no Cordova.

Observe que no Cordova Node.js as APIs não estão disponíveis, então o Electron precisaria preencher alguns dos módulos nativos do Node.js com alternativas que funcionam no Cordova, semelhante ao que o Browserify faz para o navegador. Isso ajudaria a criar uma API unificada, porque se houver algo que a API Electron não cobre, pelo menos as bibliotecas polyfilled significam que o usuário pode recorrer a APIs baseadas em Node que, nos bastidores, chamam APIs Cordova.

A necessidade de polyfill é exatamente o que acho mais inteligente começar com a rota da API. Não precisa ser uma API separada, apenas alguns recursos não estão disponíveis imediatamente. Se você fizer isso e torná-lo 100% compatível, será uma fera muito maior para lidar quando novos recursos forem adicionados no futuro.

Também gostaria de salientar que o Android e o IOS não são mais apenas móveis. O projeto em que estou trabalhando ficaria incrível em uma Android TV, além disso, não vejo por que o Github não gostaria de fazer o Atom rodar em TVs ou tablets.

Ótimo ponto, não se trata mais do tamanho da tela, estamos começando a lidar com sistemas operacionais de uso geral.

Estou confuso quanto ao status do Electron no Android?

É algo que está sendo considerado ativamente ou apenas algo sobre o qual se fala?

Tornar os aplicativos Electron um alvo válido para aplicativos PhoneGap ou Cordova é cerca de 1000 vezes mais fácil!
ou seja. cordova platform add electron-osx electron-win electron-linux

@purplecabbage com certeza, mas você perde todos os benefícios adicionais de controlar toda a pilha do navegador.

RE: Polyfills Node.js.

Devemos iniciar uma lista dos polyfills _native_ necessários para que isso funcione. O Browserify já possui versões web puras de um _lot_ do Node.js Core. Os únicos que consigo pensar que precisaríamos são:

• dns
• net
• fs

Algo mais?

Objetos Globais:

• __dirname
• __nome do arquivo
• processar

@purplecabbage parece que esses 3 têm implementações de browserify. https://github.com/substack/browserify-handbook#__dirname. Devemos dar-lhes valores diferentes com base nos dispositivos?

sim, __dirname e __filename não são grandes.
o processo é básico no browserify, não gostaríamos de oferecer suporte a eventos?
https://github.com/defunctzombie/node-process/blob/master/browser.js

Para aplicativos Native Mobile que compartilham código com electron.js, acho que o melhor será explorar a rota combinando Electron.js com NativeScript - http://github.com/NativeScript/NativeScript.

Nós (a equipe NativeScript) estamos planejando criar um aplicativo de demonstração de amostra, se você estiver interessado, por favor, comente sobre este problema - https://github.com/NativeScript/NativeScript/issues/2695

Na verdade, já existe a semente avançada do Angular 2 disponível que permite isso - https://github.com/NathanWalker/angular2-seed-advanced. Mas o angular 2 não é de forma alguma um requisito para implementar esse tipo de solução.

Isso é algo que faz sentido?

Acho que o principal é que sua equipe fez o trabalho de perna para adicionar as APIs nativas. Sou a favor da sua ideia.

@valentinstoychev , essa é uma ideia realmente interessante, embora basicamente signifique que qualquer aplicativo eletrônico terá que refazer toda a interface do usuário, certo? Seria muito interessante se de alguma forma vocês pudessem incluir libchromiumcontent para criar um webview similar a electron . Então seria mais fácil usar os dois em um aplicativo.

E o widget Android WebView e o equivalente no iOS? Na verdade, o Android já é cromo. :)

@hadees sim, a ideia é implementar a interface do usuário móvel uma vez para iOS e Android usando NativeScript e uma vez para desktop usando electron. Todo o resto - dados, modelos, lógica de negócios, serviços, acesso a dados deve ser o mesmo.

Há duas coisas a serem observadas aqui.

Primeiro, você usará quase o mesmo conjunto de habilidades (significa que uma equipe pode fazer isso para desktop, web e dispositivos móveis) ao construir com electron.js e NativeScript - é tudo JavaScript/TypeScript/CSS. Você pode usar o Angular 2, se quiser. Para estilização, você usará CSS tanto para NativeScript quanto para electron. _Então, geralmente, a única coisa que será diferente é a marcação da interface do usuário_. Até o layout deve ser familiar, pois lançaremos o layout FlexBox no próximo mês. Todo o resto é código reutilizável e, o mais importante, conjunto de habilidades reutilizáveis. A parte de ferramentas também deve ser familiar, pois no NativeScript estamos usando o Chrome Devtools ...

A segunda coisa a ser observada aqui é que você realmente deseja ter uma interface de usuário diferente para dispositivos móveis e desktop, certo. Portanto, na maioria dos casos, a parte da interface do usuário não será reutilizada de qualquer maneira e deve ser diferente.

Acredito que esta é uma história bastante convincente e vamos explorá-la e mostrar um exemplo da vida real muito em breve. Espero que ver o código real e o aplicativo real ajudem a esclarecer um pouco se vale a pena explorar ou não.

De qualquer forma, o aplicativo (ou aplicativos) final estará com UI nativa em todos os lugares. E acho que é isso que torna essa solução única e digna de ser explorada. Também é barato ser hackeado porque não há necessidade de fazer alterações no electron.js e no NativeScript. A partir desta primeira solução, podemos encontrar áreas onde uma colaboração mais estreita pode existir.

Eu usei o polímero para a GUI de desktop e móvel, com o Cordova. Córdoba
suporta desktop e celular.

A chave para mim era usar grpc como a tecnologia de ligação. Isso tornou muito
mais fácil porque clientes e servidores podem interoperar.

Para tudo, eu só precisava de um plugin de proxy grpc para atuar como intermediário

No sábado, 10 de setembro de 2016, 08:17 Valentin Stoychev, [email protected]
escrevi:

@hadees https://github.com/hadees sim, a ideia é implementar o
UI móvel uma vez para iOS e Android usando NativeScript e uma vez para desktop
usando elétron. Todo o resto - dados, modelos, lógica de negócios, serviços,
o acesso aos dados deve ser o mesmo.

Há duas coisas a serem observadas aqui.

Primeiro, você usará quase o mesmo _skillset_ (significa que uma equipe pode
torná-lo para desktop, web e mobile) ao construir com electron.js e
NativeScript - é tudo JavaScript/TypeScript/CSS. Você pode usar Angular 2
se você gostar. Para estilização, você usará CSS para NativeScript e
elétron. _Então, geralmente, a única coisa que será diferente é a interface do usuário
marcação_. Até o layout deve ser familiar, pois estamos lançando o FlexBox
layout no próximo mês. Todo o resto é código reutilizável e o mais importante
conjunto de habilidades reutilizáveis.

A segunda coisa a notar aqui é que você realmente quer ter diferentes
UI para celular e desktop, certo. Assim, em muitos/a maioria dos casos, a interface do usuário
parte não será reutilizada de qualquer maneira e deve ser diferente.

Acredito que esta é uma história bastante convincente e vamos explorá-la e
mostrar um exemplo da vida real muito em breve. Espero ver o código real e
aplicativo real ajudará a esclarecer um pouco se vale a pena explorar ou não.

De qualquer forma, o aplicativo (ou aplicativos) final estará com UI nativa em todos os lugares.
E acho que é isso que torna essa solução única e digna de ser explorada. Isto
também é barato ser hackeado porque não há mudanças que precisam ser feitas no
tanto electron.js quanto NativeScript. A partir desta primeira solução,
pode encontrar áreas onde uma colaboração mais estreita pode existir.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/electron/electron/issues/562#issuecomment -246093147,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript não é realmente uma opção para o suporte móvel da Electron, porque
ele muda completamente o paradigma da tecnologia da web para JavaScript
ligações para widgets nativos. Em essência, o que teremos não seria mais
"Electron", porque o Electron em seu núcleo é uma pilha de navegador que expõe
Node.js _dentro_ de um contexto de navegador, e é isso que faz o Electron
Elétron.

As vinculações NativeScript + Node.js podem ser consideradas completamente diferentes
projeto.

Primeiro, você usará quase o mesmo conjunto de habilidades (significa que uma equipe pode fazer isso para desktop, web e dispositivos móveis) ao construir com electron.js e NativeScript - é tudo JavaScript/TypeScript/CSS.

Não necessariamente verdade, porque com NativeScript você deve ter alguns
compreensão de como os widgets nativos se comportam, independentemente do fato de que
você está codificando em JavaScript. Isso significa que sem o conhecimento do
widgets e sem conhecimento de como modificar essas ligações de widget com
código nativo, então fazer algo personalizado se torna muito difícil, o que é
não é o caso de JS/HTML/CSS puro em uma pilha da web, porque com uma pilha da web
modificar os internos significa modificar o mesmo tipo de código no mesmo ambiente em que você já está, sem ter que se preocupar com uma língua estrangeira.

A segunda coisa a ser observada aqui é que você realmente deseja ter uma interface de usuário diferente para dispositivos móveis e desktop, certo. Portanto, na maioria dos casos, a parte da interface do usuário não será reutilizada de qualquer maneira e deve ser diferente.

Um dos benefícios de usar o Electron (com seu front-end baseado na Web), é
que escrevemos um código, e ele se comporta quase _exatamente o mesmo_
em todos os lugares. Isso nem sempre seria o caso do NativeScript, que
tenta unir conjuntos completamente diferentes de tecnologias com uma linguagem.

Eu pessoalmente gosto muito mais da ideia de usar um web-ui em todos os lugares,
versus diferentes UIs nativas em todos os lugares. Algumas pessoas acreditam que as UIs nativas
são muito melhores do que UIs da Web. É verdade até certo ponto, e é o caso
com desenvolvedores que não conhecem todos os fundamentos da web. Mas com
uso adequado de APIs da Web, podemos, de fato, criar interfaces de usuário agradáveis. A web está fazendo enorme
progresso. WebGL é extremamente multiplataforma...

_/#!/_JoePea

Em sex, 9 de setembro de 2016 às 23h17, Valentin Stoychev < [email protected]

escrevi:

@hadees https://github.com/hadees sim, a ideia é implementar o
UI móvel uma vez para iOS e Android usando NativeScript e uma vez para desktop
usando elétron. Todo o resto - dados, modelos, lógica de negócios, serviços,
o acesso aos dados deve ser o mesmo.

Há duas coisas a serem observadas aqui.

Primeiro, você usará quase o mesmo _skillset_ (significa que uma equipe pode
torná-lo para desktop, web e mobile) ao construir com electron.js e
NativeScript - é tudo JavaScript/TypeScript/CSS. Você pode usar Angular 2
se você gostar. Para estilização, você usará CSS para NativeScript e
elétron. _Então, geralmente, a única coisa que será diferente é a interface do usuário
marcação_. Até o layout deve ser familiar, pois estamos lançando o FlexBox
layout no próximo mês. Todo o resto é código reutilizável e o mais importante
conjunto de habilidades reutilizáveis.

A segunda coisa a notar aqui é que você realmente quer ter diferentes
UI para celular e desktop, certo. Assim, em muitos/a maioria dos casos, a interface do usuário
parte não será reutilizada de qualquer maneira e deve ser diferente.

Acredito que esta é uma história bastante convincente e vamos explorá-la e
mostrar um exemplo da vida real muito em breve. Espero ver o código real e
aplicativo real ajudará a esclarecer um pouco se vale a pena explorar ou não.

De qualquer forma, o aplicativo (ou aplicativos) final estará com UI nativa em todos os lugares.
E acho que é isso que torna essa solução única e digna de ser explorada. Isto
também é barato ser hackeado porque não há mudanças que precisam ser feitas no
tanto electron.js quanto NativeScript. A partir desta primeira solução,
pode encontrar áreas onde uma colaboração mais estreita pode existir.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/electron/electron/issues/562#issuecomment -246093147,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr Concordo plenamente. Eu acho que há muito estoque colocado em aparência nativa pelos desenvolvedores. Nativo nem é um ideal consistente. Na última década, as interfaces móveis mudaram dezenas de vezes e nem são consistentes de um telefone Android para outro.

Ter seu aplicativo consistente em todas as plataformas que um usuário pode acessá-lo é um padrão muito melhor de se manter. Fazê-los aprender dois conjuntos de símbolos e sinais de interface do usuário apenas para operar um aplicativo no iPhone e na máquina de trabalho do Windows é terrível.

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

Historicamente, o código do Chrome para iOS era mantido separado do restante do projeto Chromium devido à complexidade adicional necessária para a plataforma. Após anos de refatoração cuidadosa, todo esse código está se juntando ao Chromium e sendo movido para o repositório de código aberto.

Devido às restrições da plataforma iOS, todos os navegadores devem ser construídos com base no mecanismo de renderização WebKit. Para o Chromium, isso significa suportar tanto o WebKit quanto o Blink, o mecanismo de renderização do Chrome para outras plataformas. Isso criou algumas complexidades extras que queríamos evitar colocar na base de código do Chromium.

Dado o compromisso do Chrome com o código-fonte aberto, passamos muito tempo nos últimos anos fazendo as alterações necessárias para fazer o upstream do código do Chrome para iOS no Chromium. Hoje, esse upstreaming está completo e os desenvolvedores podem compilar a versão iOS do Chromium como podem para outras versões do Chromium. A velocidade de desenvolvimento também é mais rápida agora que todos os testes do Chrome para iOS estão disponíveis para toda a comunidade Chromium e são executados automaticamente sempre que o código é verificado.

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

Primeiro grande passo? :]

Mas isso não significa nada, já que o cromo não pode ser colocado na loja da Apple.

Mas no Android, é muito necessário agora.

Desenvolver com cordova e webview padrão é um inferno, e a intel havia descartado o Crosswalk, que é a porta da intel de chromium webview como webview padrão para android.
https://crosswalk-project.org/blog/crosswalk-final-release.html

Problemas:

• O webview padrão não é confiável graças a diferentes fornecedores fazendo coisas diferentes. Não é estável até 6.0 do Android, que é apenas 20% dos telefones usando.
• nem todo mundo está fazendo atualizações de firmware ou pacote do Android, especialmente em áreas restritas de largura de banda com 3G caro.

O que podemos fazer:

• APIs de elétrons são impossíveis de portar para o chrome (como @zcbenz disse em 2014)
• chromuim para android e chromium webview para android é totalmente opensource agora: https://www.chromium.org/developers/how-tos/android-build-instructions
• Podemos bifurcar e continuar mantendo a faixa de pedestres (que é basicamente a porta do chromium para o Android com menos restrições) https://github.com/crosswalk-project , já é bastante estável.
• Nossa experiência mostra que crosswalk e cordova com um bom JS Framework oferece desempenho Near-Native ( Emberjs / React / Angular / Vue ).
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

precisamos de contribuidores e mantenedores na faixa de pedestres, que pode ser o que você está procurando.

Boas notícias

Notícias relevantes, nova porta de Node.js para iOS por @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/

então o único esforço que precisaria ser feito é garantir que os navegadores móveis suportem elétron se emulados por meio do link que @mikeal postou?

É legal enviar outras VMs JS no iOS hoje em dia? Ou a Apple ainda exige que você use o deles?

As VMs de envio do @trusktr que não geram código executável não violam as diretrizes da loja de aplicativos. Já obtivemos tal aplicativo aprovado na loja de aplicativos antes (embora usando SpiderMonkey e não ChakraCore).

Podemos reabrir esta questão para continuar a discussão sobre se o elétron terá uma estrutura móvel suportada no futuro?

Eu apoio isso. O que precisa ser feito? Fico feliz em começar a testar ou hackear isso com um pouco de direção.

@OtterCode faria sentido criar um repositório chamado electron-mobile e começar a hackear lá? Eu pude ver uma etapa necessária de planejamento e preparação de aplicativos de exemplo para começar a descobrir o que precisa ser feito. Existe uma biblioteca de API de nível superior para elétrons que possamos emular para começar? (Documentos de API, destinos de compilação, etc.)

@OtterCode e qualquer pessoa interessada eu criei, https://github.com/gabrielcsapo/electron-mobile , se alguém estiver interessado, posso adicioná-lo como proprietário e podemos começar a trabalhar em um caminho a seguir para iOS e Android build alvos para elétrons.

Produtos como Samsung Dex, http://www.samsung.com/global/galaxy/apps/samsung-dex/
Faça disso uma solicitação IMO viável (pelo menos para Android).

Isso é definitivamente muito factível. O aplicativo "Termux" do Google Play, por exemplo, nos dá todo um terminal baseado em Debian diretamente no aplicativo. Podemos apt-get install qualquer coisa que precisarmos (Node, Vim, Git, etc, desde que a coisa que estamos instalando suporte a arquitetura de CPU do dispositivo). É completamente possível fazer o Electron rodar em seu próprio ambiente de sandbox de aplicativos semelhante ao Termux.

O Termux funciona sem fazer root em nossos telefones, instala tudo dentro da caixa de proteção do aplicativo e podemos até vincular nosso armazenamento externo à nossa "pasta inicial" no Termux e trabalhar em nosso armazenamento externo usando todas as ferramentas de linha de comando que o Termux nos fornece.

Podemos abrir aplicativos Node.js em nosso navegador, no localhost, servido diretamente no Termux.

É definitivamente possível fazer algo assim com o Electron.

Eu realmente espero que isso aconteça, eu usei o ElectronJS para meu projeto anterior, que era um sistema computadorizado baseado em desktop autônomo. A Electron foi muito boa, agora uma empresa quer me contratar e quer criar aplicativos móveis, estão pensando em usar o PhoneGap para isso, pois não querem ter o problema de ter várias equipes para diferentes plataformas (iOS/Android) , ter uma solução única para todos é extremamente grande, e espero que o ElectronJS possa ter uma versão que suporte dispositivos móveis para que eu não precise alternar entre diferentes plataformas e idiomas, às vezes é realmente cansativo.

react-native não é uma correção permanente para este problema

@aprilmintacpineda você já olhou para Progressive Web Apps? https://developers.google.com/web/progressive-web-apps/

@Serkan-devel sim, eu tenho, eu não estava ciente dos aplicativos da web progressivos quando vi esse problema aqui. Eu decidi usar react-native em vez disso.

@aprilmintacpineda você ainda pode experimentar PWAs também, https://youtube.com/watch?v=vhg01Ml-8pI . Também ajuda na área de trabalho

Como integrar o nodejs-mobile com o Chromium ? Esta parece ser a solução mais próxima para trazer o Node para dispositivos móveis em um ambiente de navegador, semelhante ao que o Electron fez para desktop.

(Estou ciente do que os PWAs podem fazer hoje , e existem estruturas como o Cordova para envolver aplicativos da Web em aplicativos móveis, mas os PWAs não podem acessar sistemas de arquivos no nível do sistema operacional ou incorporar servidores HTTP, e o Cordova é apenas um exagero para meu projeto atual, sem mencionar os processos de configuração e compilação para Android e iOS.)

Um pacote distribuível de navegador integrado ao Node para dispositivos móveis tornaria o desenvolvimento tão fácil quanto desenvolver aplicativos de desktop com o Electron, que acredito ser o que tornou o Electron tão popular. Muito código também seria reutilizável em vez de escrever um código completamente diferente para dispositivos móveis.

Eu sou um desenvolvedor web e não tenho experiência em construir sistemas/aplicativos nativos, muito menos integrar um navegador complexo com o Node, então qualquer indicação seria muito apreciada. Se você tem experiência e quer ajudar a criar tal projeto, você é mais do que bem-vindo para contribuir.

Embora isso seja possível de ser alcançado, acho que devemos pensar duas vezes se realmente devemos fazer isso. No aplicativo de desktop em que usei o electron, experimentei atrasos, especialmente com animações css. Se houver uma opção nativa, prefiro optar pelo nativo, o nativo tem muito a oferecer. Ou talvez experimente o PWA. É incrível, mas ainda não substitui os aplicativos, mas acho que tem um grande futuro.

marca

https://github.com/dna2github/dna2oslab

os nodejs que podem funcionar bem no android

Não é exatamente como o Electron, mas para quem quer construir aplicativos Android com Node.js, esta biblioteca parece funcionar bem nos meus testes.