Electron: Мобильная поддержка

Я думаю, что atom-shell в первую очередь создавался для текстового редактора Atom, поэтому я не ожидал, что он будет поддерживать мобильные платформы. Есть Phonegap и Cordova для мобильных приложений HTML5.

Да, но речь идет об обмене кодом из модулей node.js и доступе к низкоуровневым ресурсам.

Для мобильной платформы почти все API-интерфейсы Atom-Shell неприменимы, поэтому я не думаю, что мы когда-либо будем поддерживать мобильные платформы.

Может быть, вы, ребята, сможете по крайней мере хорошо поиграть с Cordova и т. д., (каким-то образом) обнаружив среду (во время выполнения или указанную во время сборки), чтобы API-интерфейсы Electron просто вызывали модули Cordova (или собственный код) без нашего ведома. Это было бы безумно здорово.

+1 @trusktr

@trusktr Звучит как отличный сторонний модуль, который предоставит прокладки совместимости для Cordova.

Я очень надеюсь, что это произойдет. Я думаю, что будущее веб-платформы должно двигаться в этом направлении, чтобы мы могли писать ПО-НАСТОЯЩЕМУ кроссплатформенные приложения. Я очень надеюсь, что это не исключено.

Не верится, что уже 2016 год, а такого до сих пор нет.

@emin93 emin93 это неконструктивно, как уже указывал @zcbenz , было бы почти невозможно перенести API-интерфейсы Electron на мобильные устройства.
Вы не можете просто требовать функции, не имея хотя бы каких-то предложений о том, как это сделать.

@YuriSolovyov Я не имею в виду Электрона напрямую. На самом деле альтернатив нет, и это меня расстраивает. Но да, вы правы, это на самом деле не то место, чтобы обсуждать это.

Электрон для мобильных устройств был бы просто потрясающим. У меня есть несколько разработанных приложений Electron, и мне нравится этот фреймворк, но каждый день я хочу, чтобы он работал и на мобильных устройствах.

Единственная кроссплатформенная платформа, демонстрирующая сквозную кроссплатформенную поддержку (IOS, Android, Windows, OSX, Linux), — это Xamarin , но для этого требуется кодирование на C#. Я не удивлюсь, если Xamarin разрешит код JS вскоре после того, как Microsoft теперь владеет Xamarin, а также добилась больших успехов в переносе узла на свой собственный движок JS.

Я действительно надеюсь, что некоторые корпоративные спонсоры смогут профинансировать такой порт/форк электрона для мобильных устройств, который в конечном итоге будет встроен в ту же структуру, чтобы у нас была полноценная среда разработки кросс-платформенных приложений на основе JS.

Спасибо команде Электрон за отличную работу!

Повторяя исходный вопрос от @cjfromthesea , может ли кто-нибудь объяснить проблемы с API-интерфейсами Electron на мобильных устройствах (возможно, @zcbenz)? С некоторыми общими рекомендациями я и другие люди потенциально могут начать думать о способах решения проблем, взламывая и переделывая. Я немного разобрался с jxcore-cordova, но некоторые рекомендации были бы кстати. Что такое блокпосты?

@lastmjs огромным препятствием является то, что Electron использует V8, который не поддерживается на iOS. Это означает, что Chromium и Node.js также не будут работать на iOS, и эти три являются основными компонентами Electron.

Новая версия хрома для IOS была выпущена в январе, и node.app , возможно, может помочь с node.js. И Android не должен быть проблемой, учитывая, что поддерживается V8.
Тем временем мы могли бы написать документацию о том, как использовать Cordova с электроном для IOS (так как они мне действительно нужны, я был бы рад помочь).

@noelmace Chrome для iOS не использует движок Chromium, поскольку Apple этого не разрешает. Это просто WKWebView, который использует Safari, но с другим пользовательским интерфейсом.

@emin93 emin93 Позволяет ли Apply использовать любой пользовательский интерпретатор, такой как node.app?

У меня было несколько вопросов, на которые я хотел бы получить ответы от участников этой ветки:

• Вы хотите создать _одно приложение, которое работает везде_?
  
  
  
  • Дополнительный вопрос: есть ли примеры настольных приложений (не веб-приложений), которые также являются мобильными приложениями?
  
  
• Или вы ищете _опыт_ создания приложения Electron, но на мобильных устройствах?
  
  
  
  • Дополнительный вопрос, чем это будет отличаться от Cordova/PhoneGap (или других)?
  
  

Я определенно ищу одно приложение, которое может работать везде. Одна кодовая база, одна веб-платформа, любая среда.

Примеры хороших мобильных/настольных/веб-приложений, где размер экрана и устройство не имеют большого значения, но вам может понадобиться такая же функциональность:

• Хром
• Fire Fox
• Слабый
• Gmail
• Google Фото
• Карты Гугл

Не все вышеперечисленные приложения обязательно имеют настольную версию, работающую с собственным исполняемым файлом, но у них есть настольная версия в браузере. Для меня, конечно, это зависит от случая к случаю, но обычно я хочу, чтобы мое приложение было моим приложением, независимо от того, на каком устройстве оно находится. Я стремлюсь к одинаковым функциям на всех устройствах, насколько это возможно. Почему бы нет? Я хочу, чтобы Chrome работал на моем рабочем столе так же, как на моем Android, моем iPhone или планшете, так же, как в Firefox, Slack, Google Maps. Мне грустно, когда иногда функции Google Maps зависят от платформы. Вернемся к Chrome. Я хочу иметь возможность просматривать исходный код и даже использовать отладчик даже на своем телефоне. Иногда я думаю, что у нас не хватает предусмотрительности, чтобы соответствующим образом ограничить функциональность наших приложений. Что, если кому-то нужна функция, которая работает в настольной версии приложения на его телефоне? Конечно, приложения должны быть отзывчивыми, но, на мой взгляд, основная функциональность должна оставаться неизменной.

Спасибо @lastmjs. Я только что отредактировал свой вопрос, потому что я думал, но не уточнил, что это настольные приложения, которые также являются мобильными приложениями, но не являются веб-приложениями. Я думаю, что это важное различие.

но основная функциональность должна оставаться неизменной, насколько это возможно, на мой взгляд

Мысли вслух здесь: Electron создает API для общего поведения нативных приложений для настольных компьютеров — кажется, что если вы также добавите в мобильные устройства, то общее между ними сократится. Приложение, основанное на общих чертах между десктопом и мобильным телефоном, может в конечном итоге работать везде, но будет ли оно посредственным мобильным и десктопным опытом?

Основано ли обычное поведение нативных настольных приложений, о которых вы говорите, в основном на пользовательском интерфейсе? Я вижу, как родные меню и другие варианты поведения могут плохо переводиться. Самым большим преимуществом для меня было бы иметь одну консолидированную среду выполнения, где у меня есть доступ к Node.js и API Chromium, и указанная среда выполнения может быть развернута на всех основных платформах. Electron и Cordova в некотором смысле делают одно и то же для разных платформ, за исключением функциональности пользовательского интерфейса, о которой вы, возможно, говорили. С Cordova у вас есть единая кодовая база, которую можно развернуть в нескольких основных мобильных операционных системах, при этом мобильные операционные системы не слишком отличаются по функциональности от основных настольных операционных систем. Операционная система управляет процессами и их ресурсами и предоставляет доступ к оборудованию, которое может понадобиться процессам. Принципиальной разницы между мобильными и настольными операционными системами нет. А с появлением в браузерах аппаратных API веб-платформа становится все более и более универсальной в плане возможности развертывания во всех основных средах. Итак, как я понимаю, Cordova и Electron выполняют в основном одни и те же задачи, но в разных операционных системах, причем указанные операционные системы не отличаются принципиально, так почему бы не объединить их? 😃

@jlord

Я строю для мобильных и настольных компьютеров и хотел бы добавить комментарии от @lastmrs и @noelmace.

Вот мои мысли о том, как это могло бы работать для всех.

API, который предоставляет электрон, должен различаться в зависимости от того, является ли он мобильным или настольным. Таким образом, разработчик несет ответственность за обнаружение среды выполнения (которое обеспечивает электронный уровень) для вызова другого API в зависимости от контекста среды.
Опять же, чтобы быть ясным, разработка должна поступать правильно.

Что касается аспектов пользовательского интерфейса, опять же, разработчик должен поступить правильно. Я использую полимер для всех своих настольных и мобильных проектов, и от меня зависит, чтобы сделать это правильно.
Я также использую golang для написания любых скомпилированных материалов, которые мне нужны на настольных и мобильных устройствах для доступа к любому оборудованию.

Во время сборки я упаковываю для настольных компьютеров (amd 64 и т. д. и т. д.) и мобильных устройств (Android или iOS), где я делаю отдельный пакет для каждой ОС и архитектуры чипа. Я делаю то же самое с электроном. Это позволяет мне делать разницу во времени компиляции по мере необходимости, потому что некоторый код зависит от аппаратного обеспечения.
Я по-прежнему могу включать один и тот же код во все сборки и выполнять сниффинг во время выполнения, и именно здесь электрон предоставит мне контекст среды.

Самое замечательное, что это обеспечивает, — это общие инструменты во время разработки и во время компиляции. Это огромное повышение производительности для разработчиков, потому что вы можете установить электрон и запустить загрузочный bash-скрипт для установки битов iOS и Android, а также для написания приветствия, упаковки и развертывания на настольных и мобильных устройствах.

Я не знал, что команда Google обновила Chrome для iOS, чтобы он стал многопроцессорным. Я очень рад видеть это.

Если я могу помочь с чем-то из этого, я бы с радостью помог.

Это было бы огромным улучшением и для многих моих проектов. Уже нужно было бы вносить изменения в пользовательский интерфейс в зависимости от того, является ли он мобильным или нет, с тем же успехом можно было бы выполнять любые другие обнаружения/изменения.

Я не думаю, что иметь два отдельных API — хорошая идея (@joeblew99). Для конечного пользователя, я думаю, было бы лучше, если бы Electron заставил свои API работать поверх Cordova или Node, чтобы конечному пользователю нужно было знать только один API (Electron API). Затем, если что-то не охвачено API, конечные пользователи могут при необходимости погрузиться в Node или Cordova.

Кроме того, я думаю, что для Electron было бы важно определить, как использовать рабочий процесс NPM, который работает в любом случае (Cordova или непосредственно на Node). То есть, Electron должен был бы определить свою систему сборки, чтобы она была совместима с обоими, используя NPM (и модули ES6 тоже будут полезны), чтобы конечным пользователям не пришлось беспокоиться о том, как собирать для каждого из них. Случай Node, очевидно, уже обработан, но может потребоваться дополнительная работа, чтобы NPM нормально работал в Cordova.

Обратите внимание, что в Cordova API-интерфейсы Node.js недоступны, поэтому Electron потребуется заполнить некоторые нативные модули Node.js альтернативами, которые работают в Cordova, аналогично тому, что Browserify делает для браузера. Это помогло бы создать унифицированный API, потому что если есть что-то, что API Electron не покрывает, то, по крайней мере, полифиллы libs означают, что пользователь может вернуться к API на основе Node, которые за кулисами вызывают API Cordova.

Необходимость полифилла — это именно то, что я считаю разумнее начать с маршрута API. Это не обязательно должен быть отдельный API, просто некоторые функции недоступны сразу. Если вы пройдете и сделаете его на 100% совместимым, то это будет гораздо больший зверь, с которым придется иметь дело, когда в будущем будут добавлены новые функции.

Я также хотел бы отметить, что Android и IOS больше не просто мобильные устройства. Проект, над которым я работаю, будет отлично смотреться на Android TV, плюс я не понимаю, почему Github не хочет запускать Atom на телевизорах или планшетах.

Отличное замечание, речь больше не о размере экрана, мы начинаем иметь дело с операционными системами общего назначения.

Я смущен статусом Electron на Android?

Это то, что активно рассматривается, или просто о чем говорят?

Сделать приложения Electron действительной целью для приложений PhoneGap или Cordova примерно в 1000 раз проще!
т.е. cordova platform add electron-osx electron-win electron-linux

@purplecabbage конечно, но тогда вы потеряете все дополнительные преимущества управления всем стеком браузера.

RE: Полифиллы Node.js.

Мы должны начать список необходимых _native_ polyfills, чтобы это работало. У Browserify уже есть чистые веб-версии _lot_ ядра Node.js. Единственные, которые, как мне кажется, нам понадобятся:

• dns
• net
• fs

Что-нибудь еще?

Глобальные объекты:

• __имя_каталога
• __имя файла
• обработать

@purplecabbage выглядит так, как будто у этих 3 есть браузерные реализации. https://github.com/substack/browserify-handbook#__имя_каталога. Должны ли мы давать им разные значения в зависимости от устройств?

да, __dirname и __filename не важны.
процесс является базовым в браузере, разве мы не хотели бы поддерживать события?
https://github.com/defunctzombie/node-process/blob/master/browser.js

Я думаю, что для приложений Native Mobile, совместно использующих код с electro.js, лучше всего будет изучить маршрут, объединив Electron.js с NativeScript — http://github.com/NativeScript/NativeScript.

Мы (команда NativeScript) планируем создать образец демонстрационного приложения, если вам интересно, прокомментируйте эту проблему — https://github.com/NativeScript/NativeScript/issues/2695.

На самом деле, уже есть расширенный начальный код Angular 2, который позволяет это сделать — https://github.com/NathanWalker/angular2-seed-advanced. Но angular 2 ни в коем случае не является требованием для реализации такого решения.

Есть ли в этом смысл?

Я думаю, что ключевой момент в том, что ваша команда проделала большую работу по добавлению нативных API. Я полностью за вашу идею.

@valentinstoychev , это действительно интересная идея, хотя в основном это означает, что любым электронным приложениям придется переделывать весь свой пользовательский интерфейс, верно? Было бы очень интересно, если бы вы каким-то образом могли включить libchromiumcontent для создания webview , похожего на electron . Тогда было бы проще использовать оба в одном приложении.

Как насчет виджета Android WebView и его эквивалента на iOS? На самом деле Android-это уже хром. :)

@hadees да, идея состоит в том, чтобы реализовать мобильный пользовательский интерфейс один раз для iOS и Android с помощью NativeScript и один раз для рабочего стола с помощью электрона. Все остальное — данные, модели, бизнес-логика, сервисы, доступ к данным — должно быть одинаковым.

Здесь следует отметить две вещи.

Во-первых, вы будете использовать почти один и тот же набор навыков (это означает, что одна команда может сделать это для настольных компьютеров, веб-сайтов и мобильных устройств) при создании с помощью electronic.js и NativeScript — это все JavaScript/TypeScript/CSS. Вы можете использовать Angular 2, если хотите. Для стилизации вы будете использовать CSS как для NativeScript, так и для электрона. _Поэтому обычно единственное, что будет отличаться, — это разметка пользовательского интерфейса_. Даже макет должен быть вам знаком, поскольку в следующем месяце мы выпускаем макет FlexBox. Все остальное — повторно используемый код и, самое главное, повторно используемый набор навыков. Инструментальная часть также должна быть вам знакома, так как в NativeScript мы используем Chrome Devtools...

Второе, на что следует обратить внимание, это то, что вы на самом деле хотите иметь разные пользовательские интерфейсы для мобильных устройств и компьютеров, верно. Таким образом, во многих/большинстве случаев часть пользовательского интерфейса все равно не будет использоваться повторно и должна быть другой.

Я считаю, что это довольно убедительная история, и мы очень скоро рассмотрим ее и покажем пример из реальной жизни. Я надеюсь, что просмотр фактического кода и фактического приложения поможет немного прояснить, стоит ли его изучать или нет.

В любом случае конечное приложение (или приложения) будет везде с родным пользовательским интерфейсом. И я думаю, именно это делает это решение уникальным и заслуживающим изучения. Взлом также обходится дешево, потому что нет необходимости вносить изменения как в electro.js, так и в NativeScript. Начиная с этого первого решения, мы можем найти области, в которых может существовать более тесное сотрудничество.

Я использовал полимер для рабочего стола и мобильного графического интерфейса с Cordova. Кордова
поддерживает настольные и мобильные устройства.

Ключевым для меня было использование grpc в качестве технологии привязки. Это сделало его намного
легче, потому что клиенты и серверы могут взаимодействовать.

Для всего этого мне просто нужен плагин прокси-сервера grpc, который будет выступать в качестве посредника.

Сб, 10 Сен 2016, 08:17 Валентин Стойчев, уведомления@github.com
написал:

@hadees https://github.com/hadees да, идея в том, чтобы реализовать
мобильный пользовательский интерфейс один раз для iOS и Android с использованием NativeScript и один раз для рабочего стола
с помощью электрона. Все остальное — данные, модели, бизнес-логика, сервисы,
доступ к данным должен быть одинаковым.

Здесь следует отметить две вещи.

Во-первых, вы будете использовать почти один и тот же _skillset_ (это означает, что одна команда может
сделать это для настольных компьютеров, веб-сайтов и мобильных устройств) при создании с помощью electronic.js и
NativeScript — это всё JavaScript/TypeScript/CSS. Вы можете использовать угловой 2
если хочешь. Для стилизации вы будете использовать CSS как для NativeScript, так и для
электрон. _Так что, как правило, единственное, что будет отличаться, — это пользовательский интерфейс.
разметка_. Даже макет должен быть знаком, так как мы выпускаем FlexBox
макет в следующем месяце. Все остальное является повторно используемым кодом и, самое главное,
многоразовый набор навыков.

Второе, на что следует обратить внимание, это то, что вы на самом деле хотите иметь разные
Пользовательский интерфейс для мобильных и настольных компьютеров, верно. Таким образом, во многих/большинстве случаев пользовательский интерфейс
часть не будет повторно использоваться в любом случае и должна быть другой.

Я считаю, что это довольно убедительная история, и мы рассмотрим ее и
покажите реальный пример очень скоро. Я надеюсь увидеть фактический код и
фактическое приложение поможет немного прояснить, стоит ли его изучать или нет.

В любом случае конечное приложение (или приложения) будет везде с родным пользовательским интерфейсом.
И я думаю, именно это делает это решение уникальным и заслуживающим изучения. Это
также дешево взломать, потому что нет необходимости вносить изменения в
как electronic.js, так и NativeScript. Начиная с этого первого решения, мы
могут найти области, где может существовать более тесное сотрудничество.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/electron/electron/issues/562#issuecomment-246093147 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript на самом деле не подходит для мобильной поддержки Electron, потому что
он полностью меняет парадигму с веб-технологий на JavaScript
привязки для нативных виджетов. По сути, то, что у нас будет, больше не будет
«Электрон», потому что Электрон по своей сути представляет собой стек браузера, который предоставляет
Node.js _внутри_ контекста браузера, и именно это делает Electron
Электрон.

Связки NativeScript + Node.js можно считать совершенно разными
проект.

Во-первых, вы будете использовать почти один и тот же набор навыков (это означает, что одна команда может сделать это для настольных компьютеров, веб-сайтов и мобильных устройств) при создании с помощью electronic.js и NativeScript — это все JavaScript/TypeScript/CSS.

Не обязательно так, потому что с NativeScript у вас должны быть некоторые
понимание того, как ведут себя нативные виджеты, вне зависимости от того, что
вы кодируете на JavaScript. Это означает, что без ведома
виджеты и не зная, как изменить эти привязки виджетов с помощью
нативный код, то сделать что-то нестандартное становится очень сложно, что
не в случае с чистым JS/HTML/CSS в веб-стеке, потому что с веб-стеком
изменение внутреннего устройства означает изменение того же типа кода в той же среде, в которой вы уже находитесь, не беспокоясь об иностранном языке.

Второе, на что следует обратить внимание, это то, что вы на самом деле хотите иметь разные пользовательские интерфейсы для мобильных устройств и компьютеров, верно. Таким образом, во многих/большинстве случаев часть пользовательского интерфейса все равно не будет использоваться повторно и должна быть другой.

Одним из преимуществ использования Electron (с его веб-интерфейсом) является
что мы пишем один код, и он ведет себя почти _точно так же_
где угодно. Это не всегда будет иметь место с NativeScript, который
пытается соединить совершенно разные наборы технологий с одним языком.

Лично мне гораздо больше нравится идея везде использовать веб-интерфейс,
по сравнению с разными родными пользовательскими интерфейсами повсюду. Некоторые люди считают, что нативные пользовательские интерфейсы
намного лучше, чем веб-интерфейсы. В какой-то степени это правда, и это так
с разработчиками, которые не знают всех основ Интернета. Но с
при правильном использовании веб-API мы действительно можем создавать красивые пользовательские интерфейсы. Сеть делает огромные
прогресс. WebGL чрезвычайно кроссплатформенный...

_/#!/_ДжоПи

Пт, 9 сентября 2016 г., 23:17, Валентин Стойчев < [email protected]

написал:

@hadees https://github.com/hadees да, идея в том, чтобы реализовать
мобильный пользовательский интерфейс один раз для iOS и Android с использованием NativeScript и один раз для рабочего стола
с помощью электрона. Все остальное — данные, модели, бизнес-логика, сервисы,
доступ к данным должен быть одинаковым.

Здесь следует отметить две вещи.

Во-первых, вы будете использовать почти один и тот же _skillset_ (это означает, что одна команда может
сделать это для настольных компьютеров, веб-сайтов и мобильных устройств) при создании с помощью electronic.js и
NativeScript — это всё JavaScript/TypeScript/CSS. Вы можете использовать угловой 2
если хочешь. Для стилизации вы будете использовать CSS как для NativeScript, так и для
электрон. _Так что, как правило, единственное, что будет отличаться, — это пользовательский интерфейс.
разметка_. Даже макет должен быть знаком, так как мы выпускаем FlexBox
макет в следующем месяце. Все остальное является повторно используемым кодом и, самое главное,
многоразовый набор навыков.

Второе, на что следует обратить внимание, это то, что вы на самом деле хотите иметь разные
Пользовательский интерфейс для мобильных и настольных компьютеров, верно. Таким образом, во многих/большинстве случаев пользовательский интерфейс
часть не будет повторно использоваться в любом случае и должна быть другой.

Я считаю, что это довольно убедительная история, и мы рассмотрим ее и
покажите реальный пример очень скоро. Я надеюсь увидеть фактический код и
фактическое приложение поможет немного прояснить, стоит ли его изучать или нет.

В любом случае конечное приложение (или приложения) будет везде с родным пользовательским интерфейсом.
И я думаю, именно это делает это решение уникальным и заслуживающим изучения. Это
также дешево взломать, потому что нет необходимости вносить изменения в
как electronic.js, так и NativeScript. Начиная с этого первого решения, мы
могут найти области, где может существовать более тесное сотрудничество.

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/electron/electron/issues/562#issuecomment-246093147 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr Полностью согласен. Я думаю, что разработчики слишком много внимания уделяют тому, чтобы выглядеть нативным. Натив — это даже не последовательный идеал. За последнее десятилетие мобильные интерфейсы менялись десятки раз и даже не совпадают от одного телефона Android к другому.

Если ваше приложение выглядит одинаково на всех платформах, с которых пользователь может получить к нему доступ, это гораздо лучший стандарт. Заставлять их изучать два набора символов и сигналов пользовательского интерфейса только для того, чтобы управлять приложением как на их iPhone, так и на рабочей машине Windows, ужасно.

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

Исторически сложилось так, что код для Chrome для iOS хранился отдельно от остальной части проекта Chromium из-за дополнительной сложности, необходимой для платформы. После многих лет тщательного рефакторинга весь этот код воссоединяется с Chromium и перемещается в репозиторий с открытым исходным кодом.

Из-за ограничений платформы iOS все браузеры должны быть построены на основе механизма рендеринга WebKit. Для Chromium это означает поддержку как WebKit, так и Blink, механизма рендеринга Chrome для других платформ. Это создало некоторые дополнительные сложности, которых мы хотели избежать в кодовой базе Chromium.

Учитывая приверженность Chrome открытому исходному коду, за последние несколько лет мы потратили много времени на внесение изменений, необходимых для переноса кода Chrome для iOS в Chromium. Сегодня этот апстрим завершен, и разработчики могут скомпилировать версию Chromium для iOS так же, как и для других версий Chromium. Скорость разработки также выше, поскольку все тесты для Chrome для iOS доступны всему сообществу Chromium и автоматически запускаются каждый раз, когда этот код регистрируется.

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

Первый большой шаг? :]

Но это ничего не значит, поскольку хром нельзя размещать в магазине Apple.

Но в андроиде сейчас это очень нужно.

Разработка с Cordova и веб-просмотром по умолчанию — это ад, и Intel отказалась от Crosswalk, который является портом Intel для веб-просмотра хрома в качестве веб-просмотра по умолчанию для Android.
https://crosswalk-project.org/blog/crosswalk-final-release.html

Проблемы:

• Веб-просмотр по умолчанию ненадежен из-за того, что разные поставщики делают разные вещи. Он нестабилен до версии 6.0 для Android, которую используют только 20% телефонов.
• не все делают обновления прошивки или пакетов Android, особенно в зонах с ограниченной пропускной способностью и дорогим 3G.

Что мы можем сделать:

• Электронные API невозможно портировать на хром (как сказал @zcbenz в 2014 году)
• chromuim для Android и веб-просмотр хрома для Android теперь полностью открыты: https://www.chromium.org/developers/how-tos/android-build-instructions
• Мы можем разветвить и продолжить поддерживать пешеходный переход (который в основном является портом хрома на андроид с меньшими ограничениями) https://github.com/crosswalk-project , он уже достаточно стабилен.
• Наш опыт показывает, что crosswalk и cordova с хорошим JS Framework дают почти нативную производительность (Emberjs/React/Angular/Vue).
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

нам нужны участники и сопровождающие в пешеходном переходе, это может быть тот, кого вы ищете.

Хорошие новости

Актуальные новости, новый порт Node.js на iOS от @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/

так что единственное усилие, которое нужно будет сделать, это убедиться, что мобильные браузеры поддерживают электрон, если они эмулируются по ссылке, которую разместил @mikeal ?

Законно ли в настоящее время поставлять другие виртуальные машины JS на iOS? Или Apple по-прежнему требует, чтобы вы использовали их?

@trusktr поставляет виртуальные машины, которые не генерируют исполняемый код, не является нарушением правил магазина приложений. Мы уже получали одобрение такого приложения в магазине приложений (правда, используя SpiderMonkey, а не ChakraCore).

Можем ли мы вновь открыть этот вопрос, чтобы продолжить обсуждение того, будет ли в будущем поддерживаться мобильная платформа электрона?

Я поддерживаю это. Что нужно сделать? Я рад начать тестирование или взлом этого с небольшим направлением.

@OtterCode , имеет ли смысл создать репозиторий под названием «электрон-мобиль» и начать взламывать там? Я мог видеть необходимый шаг планирования и подготовки примеров приложений, чтобы начать выяснять, что нужно сделать. Есть ли библиотека API более высокого уровня для электрона, которую мы могли бы эмулировать для начала? (Документы API, цели сборки и т. д.)

@OtterCode и всех, кому интересно, я создал, https://github.com/gabrielcsapo/electron-mobile , если кому-то интересно, я могу добавить вас в качестве владельца, и мы можем начать работать над продвижением для сборки iOS и Android. мишени для электрона.

Такие продукты, как Samsung Dex, http://www.samsung.com/global/galaxy/apps/samsung-dex/
Сделайте это жизнеспособным запросом IMO (по крайней мере, для Android).

Это определенно очень выполнимо. Приложение «Termux» из Google Play, например, дает нам целый терминал на основе Debian прямо в приложении. Мы можем apt-get install все, что нам нужно (Node, Vim, Git и т. д., если то, что мы устанавливаем, поддерживает архитектуру процессора устройства). Вполне возможно запустить Electron в собственной изолированной среде приложений, аналогичной Termux.

Termux работает без рутирования наших телефонов, он устанавливает все внутри песочницы приложения, и мы даже можем символически связать наше внешнее хранилище с нашей «домашней папкой» в Termux и работать в нашем внешнем хранилище, используя все инструменты командной строки, которые дает нам Termux.

Мы можем открывать приложения Node.js в нашем браузере на локальном хосте прямо из Termux.

Определенно возможно сделать что-то подобное с Electron.

Я очень надеюсь, что это произойдет, я использовал ElectronJS для своего предыдущего проекта, который был автономной компьютеризированной системой на базе рабочего стола. Electron был очень хорош, теперь компания хочет нанять меня, и они хотят создавать мобильные приложения, они думают об использовании PhoneGap для этого, так как они не хотят иметь несколько команд для разных платформ (iOS/Android). , иметь универсальное решение — это очень здорово, и я надеюсь, что у ElectronJS может быть версия, поддерживающая мобильные устройства, поэтому мне не нужно переключаться между разными платформами и языками, что иногда очень утомительно.

react-native не является постоянным решением этой проблемы

@aprilmintacpineda вы уже изучили прогрессивные веб-приложения? https://developers.google.com/web/progressive-web-apps/

@ Serkan-devel да, я знал, я не знал о прогрессивных веб-приложениях, когда увидел эту проблему здесь. Вместо этого я решил использовать react-native.

@aprilmintacpineda , вы все еще можете попробовать PWA, https://youtube.com/watch?v=vhg01Ml-8pI . Это также помогает на рабочем столе

Как интегрировать nodejs-mobile с Chromium ? Похоже, это самое близкое решение для переноса Node на мобильные устройства в среде браузера, аналогично тому, что Electron сделал для настольных компьютеров.

(Я знаю, что PWA могут делать сегодня , и существуют такие фреймворки, как Cordova, для переноса веб-приложений в мобильные приложения, но PWA не могут получить доступ к файловым системам на уровне ОС или встраивать HTTP-серверы, а Cordova — это просто излишество. для моего текущего проекта, не говоря уже о процессах установки и сборки для Android и iOS.)

Распространяемый пакет встроенного в Node браузера для мобильных устройств сделал бы разработку такой же простой, как разработка настольных приложений с помощью Electron, что, я считаю, сделало Electron таким популярным. Много кода можно было бы использовать повторно вместо того, чтобы писать совершенно другой код для мобильных устройств.

Я веб-разработчик и не имею опыта в создании системных/нативных приложений, не говоря уже об интеграции сложного браузера с Node, поэтому любые указатели будут очень признательны. Если у вас есть опыт и вы хотите помочь в создании такого проекта, вы можете внести свой вклад.

Хотя этого можно добиться, я думаю, что нам следует дважды подумать, действительно ли мы должны это делать. В настольном приложении, где я использовал электрон, я столкнулся с задержками, особенно с анимацией CSS. Если есть нативный вариант, я бы предпочел нативный, нативный может многое предложить. Или, может быть, попробовать PWA. Это круто, но ПОКА НЕ заменит приложения, но я думаю, что у него большое будущее.

отметка

https://github.com/dna2github/dna2oslab

nodejs, который может хорошо работать на Android

Это не совсем так, как Electron, но для тех, кто хочет создавать приложения для Android с помощью Node.js, эта библиотека хорошо работает в моем тестировании.