Electron: モバイルサポート

アトムシェルは主にアトムテキストエディタ用に構築されたと思うので、モバイルプラットフォームをサポートすることは期待していません。 HTML5モバイルアプリにはPhonegapとCordovaがあります。

ええ、でもそれはnode.jsモジュールからのコードを共有し、低レベルのリソースにアクセスするためのものです

モバイルプラットフォームの場合、アトムシェルのAPIのほとんどすべてが適用されないため、モバイルプラットフォームをサポートすることはないと思います。

たぶん皆さんは、Electron APIが知らないうちにCordovaモジュール（またはネイティブコード）を呼び出すように（実行時またはビルド中に指定された）環境を（何らかの方法で）検出することで、少なくともCordovaなどでうまく遊ぶことができます。 それはめちゃくちゃ素晴らしいでしょう。

+1 @trusktr

@trusktrCordovaに互換性のあるシムを提供する優れたサードパーティモジュールのように聞こえます

私は本当にこれが起こることを願っています。 本当にクロスプラットフォームのアプリを書けるように、Webプラットフォームの未来はこの方向に進む必要があると思います。 私はこれが除外されないことを本当に望んでいます。

すでに2016年だとは信じられませんが、まだそのようなことはありません。

@ emin93 @zc​​benzによってすでに指摘されているように、これは建設的なものではありません。ElectronAPIをモバイルに移植することはほぼ不可能です。
それを実現する方法について少なくとも何らかの提案がなければ、機能を要求することはできません。

@YuriSolovyov私はElectronを直接参照していません。 実際には代替手段はなく、それが私を苛立たせます。 しかし、ええ、あなたは正しいです、それは実際にそれを議論するのに適切な場所ではありません。

モバイル用の電子はとても素晴らしいでしょう。 私はいくつかのElectronアプリを開発していて、フレームワークが大好きですが、モバイルでも機能することを毎日望んでいます。

エンドツーエンドのクロスプラットフォームサポート（IOS、Android、Windows、OSX、Linux）を示す唯一のクロスプラットフォームフレームワークはXamarinですが、C＃でコーディングする必要があります。 MicrosoftがXamarinを所有し、ノードを独自のJSエンジンに移植することで大きな進歩を遂げているので、XamarinがすぐにJSコードを許可しても驚かないでしょう。

一部の企業スポンサーがこのようなモバイル用の電子のポート/フォークに資金を提供し、最終的には同じフレームワークに組み込まれることで、完全なJSベースのクロスプラットフォームアプリケーション開発フレームワークを実現できることを願っています。

素晴らしい仕事をしてくれたElectronチームに感謝します！

@cjfromtheseaからの元の質問をエコーし​​て、誰かがモバイル上のElectronのAPI（おそらく@zcbenz）にある問題を説明できますか？ いくつかの一般的なガイダンスがあれば、私や他の人は、ハッキングやいじくり回すことによって問題を回避する方法を考え始める可能性があります。 jxcore-cordovaについては少し説明しましたが、いくつかのガイダンスがあれば便利です。 障害は何ですか？

@lastmjsの大きな障害は、ElectronがiOSでサポートされていないV8を使用していることです。 つまり、ChromiumとNode.jsはiOSでも機能せず、これら3つがElectronの主要コンポーネントです。

iOS用の新しいクロムバージョンが1月にリリースされ、 node.appがnode.jsのトリックを実行できる可能性があります。 また、V8がサポートされていることを考えると、Androidは問題になりません。
それまでの間、IOSで電子を使用してCordovaを使用する方法に関するドキュメントを作成することができます（本当に必要なので、喜んでお手伝いします）。

@noelmace Chrome for iOSは、AppleがChromiumエンジンを許可していないため、Chromiumエンジンを使用しません。 Safariが使用するのと同じようにWKWebViewですが、UIが異なります。

@ emin93 Applyは、node.appのようなカスタムインタープリターの使用を許可しますか？

このスレッドの人たちからの考えが欲しいいくつかの質問がありました—

• _どこでも実行できる1つのアプリ_を構築しようとしていますか？
  
  
  
  • フォローアップの質問ですが、モバイルアプリでもあるデスクトップアプリ（Webアプリではない）の例はありますか？
  
  
• それとも、Electronアプリの構築_エクスペリエンス_をモバイルで探していますか？
  
  
  
  • フォローアップの質問、それはCordova / PhoneGap（または他の人）とどのように異なりますか？
  
  

私は間違いなくどこでも実行できる1つのアプリを探しています。 1つのコードベース、1つのWebプラットフォーム、任意の環境。

画面サイズとデバイスは実際には重要ではありませんが、同じ機能が必要な場合がある、優れたモバイル/デスクトップ/ウェブアプリの例：

• クロム
• Firefox
• スラック
• Gmail
• Googleフォト
• グーグルマップ

上記のすべてのアプリで、ネイティブの実行可能ファイルで実行されるデスクトップバージョンが必要なわけではありませんが、ブラウザーにデスクトップバージョンがあります。 もちろん、私にとってはケースバイケースですが、一般的には、どのデバイスを使用していても、自分のアプリを自分のアプリにしたいと思っています。 私は可能な限りすべてのデバイスで同じ機能を目指しています。 なぜだめですか？ Chromeをデスクトップでも、Android、iPhone、タブレットでも同じように動作させたいのですが、Firefox、Slack、Googleマップでも同じように動作させたいです。 Googleマップの機能がプラットフォーム固有である場合があると、悲しいと思います。 Chromeに戻ります。携帯電話でも、ソースを表示したり、デバッガーを使用したりできるようにしたいと考えています。 アプリケーションの機能を適切に制限する先見性がないと思うことがあります。 誰かが自分の携帯電話のデスクトップバージョンのアプリで動作する機能が必要な場合はどうなりますか？ もちろん、アプリはレスポンシブである必要がありますが、私の意見では、コア機能は可能な限り同じままである必要があります。

@lastmjsに感謝します。 私が考えていたのは、指定していなかったので、モバイルアプリでもあるがWebアプリではないデスクトップアプリだったので、質問を編集しました。 これは重要な違いだと思います。

しかし、私の意見では、コア機能は可能な限り同じままにする必要があります

ここで大声で考える：Electronは、一般的なネイティブデスクトップアプリケーションの動作用のAPIを作成します。モバイルも追加すると、これらすべての共通点が縮小するようです。 デスクトップとモバイルの共通点に基づくアプリは、最終的にはどこでも機能する可能性がありますが、モバイルエクスペリエンスとデスクトップエクスペリエンスは標準以下ですか？

あなたが話している一般的なネイティブデスクトップアプリケーションの動作は、主にUIベースですか？ ネイティブメニューやその他の動作がうまく翻訳されない可能性があることがわかります。 私にとっての最大のメリットは、Node.jsとChromium APIにアクセスできる1つの統合されたランタイムがあり、そのランタイムがすべての主要なプラットフォームにデプロイ可能であることです。 ElectronとCordovaは、あなたが話していたかもしれないUI機能を除いて、異なるプラットフォームに対して同じことをしている方法です。 Cordovaを使用すると、いくつかの主要なモバイルオペレーティングシステムに展開できる1つのコードベースがあります。モバイルオペレーティングシステムは、主要なデスクトップオペレーティングシステムと機能がそれほど変わらないと述べています。 オペレーティングシステムは、プロセスとそのリソースを管理し、プロセスが必要とする可能性のあるハードウェアへのアクセスを許可します。 モバイルオペレーティングシステムとデスクトップオペレーティングシステムの間に根本的な違いはあまりありません。 また、ブラウザにハードウェアAPIが導入されるにつれ、Webプラットフォームは、すべての主要な環境に展開できるという点でますます普遍的になっています。 私が見ているように、CordovaとElectronはほぼ同じタスクを実行していますが、異なるオペレーティングシステムで動作していると、オペレーティングシステムは根本的に異なるわけではないので、それらを組み合わせてみませんか？ 😃

@jlord

私はモバイルとデスクトップ向けに構築しており、 @lastmrsと@noelmaceからのコメントに追加したいと思います

これが、それがすべての人にとってどのように機能するかについての私の考えです。

電子が公開するAPIは、モバイルかデスクトップかによって異なります。 したがって、環境コンテキストに応じて異なるAPIを呼び出すために、ランタイム環境検出（電子層が提供する）を実行するのは開発者の責任です。
もう一度明確にするために、正しいことをするのは開発次第です

UIの側面に関しては、やはり開発者が正しいことを行う必要があります。 私はすべてのデスクトップおよびモバイルプロジェクトにポリマーを使用していますが、それを正しく行うのは私次第です。
また、golangを使用して、ハードウェアにアクセスするためにデスクトップとモバイルで必要なコンパイル済みのものを記述します。

ビルド時に、デスクトップ（amd 64など）とモバイル（androidまたはiOS）用にパッケージ化し、OSとチップアーキテクチャごとに個別のパッケージを作成します。 私は電子でも同じことをします。 これにより、一部のコードはハードウェアに依存するため、必要に応じてコンパイル時の違いを実行できます。
すべてのビルドに同じコードを含めてランタイムスニッフィングを行うことができます。これは、electronが環境コンテキストを提供する場所です。

これが提供する素晴らしい点は、設計時とコンパイル時の一般的なツールです。 これは、electronをインストールし、ブートストラップbashスクリプトを実行して、iOSとAndroidのビットをインストールし、Hello Worldを作成し、パッケージ化してデスクトップとモバイルにデプロイできるため、開発者にとって生産性が大幅に向上します。

GoogleチームがiOS用のChromeをマルチプロセスに更新したことを知りませんでした。 私はこれを見てとても興奮しています。

私がこれのいずれかを手伝うことができれば、私は喜んで助けます。

これは、私の多くのプロジェクトにとっても非常に大きな改善になるでしょう。 モバイルかどうかに基づいてUIに変更を加える必要があり、他の検出/変更も行う可能性があります。

2つの別々のAPIを持つことは良い考えではないと思います（@ joeblew99）。 エンドユーザーにとっては、ElectronがAPIをCordovaまたはNode上で機能させ、エンドユーザーが1つのAPI（Electron API）を知っていればよいようにしたほうがよいと思います。 その後、APIでカバーされていないものがある場合、エンドユーザーは必要に応じてNodeまたはCordovaに飛び込むことができます。

また、Electronにとって、どちらの場合でも（Cordovaまたは直接Nodeで）機能するNPMワークフローの使用方法を定義することが重要だと思います。 つまり、Electronは、エンドユーザーがそれぞれのビルド方法について心配する必要がないように、NPMを使用して両方と互換性のあるビルドシステムを定義する必要があります（ES6モジュールも便利です）。 明らかに、Nodeのケースはすでに処理されていますが、NPMがCordovaで正常に機能するように、追加の作業が必要になる場合があります。

CordovaではNode.jsAPIを使用できないため、Electronは、Browserifyがブラウザーに対して行うのと同様に、Cordovaで機能する代替手段でネイティブNode.jsモジュールの一部をポリフィルする必要があることに注意してください。 これは、統合APIの作成に役立ちます。これは、Electron APIでカバーされていないものがある場合、少なくともポリフィルされたライブラリは、ユーザーが舞台裏でCordovaAPIと呼ばれるノードベースのAPIにフォールバックできることを意味します。

ポリフィルの必要性は、APIルートから始める方が賢明だと私が思うものです。 個別のAPIである必要はなく、一部の機能がすぐに利用できない場合があります。 経験を積み、100％互換性を持たせると、将来的に新しい機能が追加されたときに対処するのははるかに大きな獣になります。

また、AndroidとIOSはもはやモバイルだけではないことを指摘したいと思います。 私が取り組んでいるプロジェクトは、Android TVで見栄えがするだけでなく、GithubがAtomをテレビやタブレットで実行したくない理由がわかりません。

素晴らしい点は、もはや画面サイズではなく、汎用オペレーティングシステムを扱い始めていることです。

AndroidのElectronに関するステータスについて混乱していますか？

それは積極的に検討されているものなのか、それとも単に話題になっているものなのか。

ElectronアプリをPhoneGapまたはCordovaアプリの有効なターゲットにするのは、約1000倍簡単です。
すなわち。 cordova platform add electron-osx electron-win electron-linux

@purplecabbageは確かですが、ブラウザスタック全体を制御することによる追加のメリットはすべて失われます。

RE：Node.jsポリフィル。

これが機能するために必要な_ネイティブ_ポリフィルのリストを開始する必要があります。 Browserifyには、Node.jsCoreの_lot_の純粋なWebバージョンがすでにあります。 私たちが必要だと思うことができるのは次のとおりです。

• dns
• net
• fs

他に何か？

グローバルオブジェクト：

• __dirname
• __ファイル名
• 処理する

@purplecabbageは、これら3つにbrowserifyの実装があるように見えます。 https://github.com/substack/browserify-handbook#__dirname。 デバイスに基づいて異なる値を与える必要がありますか？

ええ、__dirnameと__filenameは大したことではありません。
プロセスはbrowserifyの基本ですが、イベントをサポートしたいと思いませんか？
https://github.com/defunctzombie/node-process/blob/master/browser.js

electronic.jsとコードを共有するネイティブモバイルアプリの場合、Electron.jsとNativeScript（ http://github.com/NativeScript/NativeScript）を組み合わせてルートを探索するのが最善だと思います。

私たち（NativeScriptチーム）はサンプルのデモアプリを作成することを計画しています。興味がある場合は、この問題についてコメントしてください-https://github.com/NativeScript/NativeScript/issues/2695

実際、これを可能にするAngular2の高度なシードがすでに利用可能です-https ://github.com/NathanWalker/angular2-seed-advanced。 しかし、Angular 2は、そのような種類のソリューションを実装するための要件ではありません。

これは理にかなっていることですか？

重要なのは、チームがネイティブAPIを追加するための作業を完了したことだと思います。 私はあなたの考えにすべてです。

@valentinstoychevこれは本当に興味深いアイデアですが、基本的には、電子アプリはUI全体をやり直す必要があるということです。 electron webview libchromiumcontentを含めることができれば本当に興味深いでしょう。 そうすれば、1つのアプリで両方を使用する方が簡単になります。

Android WebViewウィジェットとそれに相当するiOSのウィジェットはどうですか？ 実際、Androidのものはすでにクロムです。 :)

@hadeesはい、アイデアは、NativeScriptを使用してiOSとAndroidに1回、electronを使用してデスクトップに1回モバイルUIを実装することです。 他のすべて-データ、モデル、ビジネスロジック、サービス、データアクセスは同じである必要があります。

ここで注意すべきことが2つあります。

まず、electron.jsとNativeScriptを使用してビルドする場合、ほぼ同じスキルセットを使用します（つまり、1つのチームがデスクトップ、Web、およびモバイル用に作成できます）。これはすべてJavaScript / TypeScript/CSSです。 必要に応じてAngular2を使用できます。 スタイリングには、NativeScriptとelectronの両方にCSSを使用します。 _したがって、一般的に異なるのはUIマークアップだけです_。 来月FlexBoxレイアウトをリリースするので、レイアウトもおなじみのはずです。 他のすべては再利用可能なコードであり、最も重要なのは再利用可能なスキルセットです。 Chrome Devtoolsを使用しているNativeScriptのように、ツールの部分もよく知っている必要があります...

ここで2つ目の注意点は、実際にはモバイルとデスクトップで異なるUIを使用したいということです。 したがって、多くの場合/ほとんどの場合、UI部分はとにかく再利用されず、異なるはずです。

これはかなり説得力のある話だと思います。私たちはそれを探求し、実際の例をすぐに示します。 実際のコードと実際のアプリを確認することで、調査する価値があるかどうかを少し明確にするのに役立つことを願っています。

いずれにせよ、最終的なアプリ（または複数のアプリ）はどこでもネイティブUIを使用します。 そして、これがこのソリューションをユニークで探求する価値のあるものにしているのだと思います。 また、electron.jsとNativeScriptの両方で変更を行う必要がないため、ハッキングするのも安価です。 この最初のソリューションから始めて、より緊密なコラボレーションが存在できる領域が見つかる可能性があります。

私はCordovaを使用して、デスクトップおよびモバイルGUIにポリマーを使用しました。 コルドバ
デスクトップとモバイルをサポートします。

私にとっての鍵は、バインディングテクノロジーとしてgrpcを使用することでした。 これはそれをたくさんしました
クライアントとサーバーが相互運用できるため、より簡単です。

すべてのために私は仲介者として機能するためにgrpcプロキシプラグインが必要でした

2016年9月10日土曜日、08：17 Valentin Stoychev、 notifications @ github.com
書きました：

@hadees https://github.com/hadeesはい、アイデアは実装することです
NativeScriptを使用するiOSおよびAndroid用に1回、デスクトップ用に1回のモバイルUI
電子を使用します。 その他すべて-データ、モデル、ビジネスロジック、サービス、
データアクセスは同じである必要があります。

ここで注意すべきことが2つあります。

まず、ほぼ同じ_スキルセット_を使用します（つまり、1つのチームが
electronic.jsを使用してビルドする場合は、デスクトップ、Web、およびモバイル用に作成してください。
NativeScript-すべてJavaScript/TypeScript/CSSです。 Angular2を使用できます
もし良かったら。 スタイリングには、NativeScriptとNativeScriptの両方にCSSを使用します
電子。 _したがって、一般的に異なるのはUIだけです
markup_。 FlexBoxをリリースするので、レイアウトもおなじみのはずです。
来月のレイアウト。 他のすべては再利用可能なコードであり、最も重要なのは
再利用可能なスキルセット。

ここで注意すべき2つ目のことは、実際には別のものにしたいということです。
モバイルとデスクトップのUIですね。 したがって、多くの場合/ほとんどの場合、UI
一部はとにかく再利用されないため、異なる必要があります。

これはかなり説得力のある話だと思います。
すぐに実際の例を示してください。 実際のコードを見て、
実際のアプリは、探索する価値があるかどうかを少し明確にするのに役立ちます。

いずれにせよ、最終的なアプリ（または複数のアプリ）はどこでもネイティブUIを使用します。
そして、これがこのソリューションをユニークで探求する価値のあるものにしているのだと思います。 これ
変更を加える必要がないため、ハッキングされるのも安価です。
electronic.jsとNativeScriptの両方。 この最初のソリューションから始めて、
より緊密なコラボレーションが存在できる領域が見つかる可能性があります。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/electron/electron/issues/562#issuecomment -246093147、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
。

NativeScriptは、Electronのモバイルサポートのオプションではありません。
パラダイムをWebテクノロジーからJavaScriptに完全にシフトします
ネイティブウィジェットのバインディング。 本質的に、私たちが持っているものはもはやありません
「Electron」、そのコアのElectronは、公開するブラウザスタックであるため
ブラウザコンテキストのNode.js_inside_であり、それがElectronの特徴です。
電子。

NativeScript+Node.jsバインディングは完全に異なると見なすことができます
事業。

まず、electron.jsとNativeScriptを使用してビルドする場合、ほぼ同じスキルセットを使用します（つまり、1つのチームがデスクトップ、Web、およびモバイル用に作成できます）。これはすべてJavaScript / TypeScript/CSSです。

NativeScriptでは、いくつかの必要があるため、必ずしも正しいとは限りません。
ネイティブウィジェットがどのように動作するかを理解している
JavaScriptでコーディングしています。 これは、知識がなくても
ウィジェット、およびそれらのウィジェットバインディングを変更する方法の知識がなくても
ネイティブコードの場合、カスタムを実行することは非常に困難になります。
Webスタックを使用するため、Webスタック内の純粋なJS / HTML/CSSの場合はそうではありません。
内部を変更するということは、外国語を気にすることなく、すでに使用しているのと同じ環境で同じタイプのコードを変更することを意味します。

ここで2つ目の注意点は、実際にはモバイルとデスクトップで異なるUIを使用したいということです。 したがって、多くの場合/ほとんどの場合、UI部分はとにかく再利用されず、異なるはずです。

Electron（Webベースのフロントエンドを使用）を使用する利点の1つは、次のとおりです。
1つのコードを記述し、それがほぼ_まったく同じ_動作をすること
どこにでも。 これは、NativeScriptでは常に当てはまるとは限りません。
完全に異なるテクノロジーのセットを1つの言語で橋渡ししようとします。

個人的には、どこでもWebUIを使用するというアイデアがもっと好きです。
どこでも異なるネイティブUIと比較して。 一部の人々はネイティブUIを信じています
WebUIよりもはるかに優れています。 それはある程度真実であり、そうです
Webの完全な基礎を知らない開発者と。 しかし、
Web APIを適切に使用することで、実際に優れたUIを作成できます。 ウェブは巨大になっています
進捗。 WebGLは非常にクロスプラットフォームです...

_ /＃！/ _ JoePea

2016年9月9日金曜日午後11時17分、Valentin Stoychev < [email protected]

書きました：

@hadees https://github.com/hadeesはい、アイデアは実装することです
NativeScriptを使用するiOSおよびAndroid用に1回、デスクトップ用に1回のモバイルUI
電子を使用します。 その他すべて-データ、モデル、ビジネスロジック、サービス、
データアクセスは同じである必要があります。

ここで注意すべきことが2つあります。

まず、ほぼ同じ_スキルセット_を使用します（つまり、1つのチームが
electronic.jsを使用してビルドする場合は、デスクトップ、Web、およびモバイル用に作成してください。
NativeScript-すべてJavaScript/TypeScript/CSSです。 Angular2を使用できます
もし良かったら。 スタイリングには、NativeScriptとNativeScriptの両方にCSSを使用します
電子。 _したがって、一般的に異なるのはUIだけです
markup_。 FlexBoxをリリースするので、レイアウトもおなじみのはずです。
来月のレイアウト。 他のすべては再利用可能なコードであり、最も重要なのは
再利用可能なスキルセット。

ここで注意すべき2つ目のことは、実際には別のものにしたいということです。
モバイルとデスクトップのUIですね。 したがって、多くの場合/ほとんどの場合、UI
一部はとにかく再利用されないため、異なる必要があります。

これはかなり説得力のある話だと思います。
すぐに実際の例を示してください。 実際のコードを見て、
実際のアプリは、探索する価値があるかどうかを少し明確にするのに役立ちます。

いずれにせよ、最終的なアプリ（または複数のアプリ）はどこでもネイティブUIを使用します。
そして、これがこのソリューションをユニークで探求する価値のあるものにしているのだと思います。 これ
変更を加える必要がないため、ハッキングされるのも安価です。
electronic.jsとNativeScriptの両方。 この最初のソリューションから始めて、
より緊密なコラボレーションが存在できる領域が見つかる可能性があります。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/electron/electron/issues/562#issuecomment -246093147、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
。

@trusktr私は心から同意します。 開発者がネイティブに見えるようにするための在庫が多すぎると思います。 ネイティブは一貫した理想でさえありません。 過去10年間で、モバイルインターフェースは何十回も変更されており、Androidフォンごとに一貫性がありません。

ユーザーがアプリにアクセスする可能性のあるすべてのプラットフォームでアプリの外観を一貫させることは、保持するのにはるかに優れた基準です。 iPhoneとWindowsの両方の作業用マシンでアプリを操作するためだけに2セットのUI記号と信号を学習させるのはひどいことです。

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

これまで、Chrome for iOSのコードは、プラットフォームに必要な追加の複雑さのために、Chromiumプロジェクトの他の部分から分離されていました。 何年にもわたる慎重なリファクタリングの後、このコードはすべてChromiumに再結合され、オープンソースリポジトリに移動されます。

iOSプラットフォームの制約により、すべてのブラウザーはWebKitレンダリングエンジンの上に構築する必要があります。 Chromiumの場合、これはWebKitと、他のプラットフォーム用のChromeのレンダリングエンジンであるBlinkの両方をサポートすることを意味します。 そのため、Chromiumコードベースに配置することを避けたかったいくつかの余分な複雑さが作成されました。

Chromeのオープンソースコードへの取り組みを考えると、過去数年間、ChromeforiOSのコードをChromiumにアップストリームするために必要な変更を加えるために多くの時間を費やしてきました。 現在、そのアップストリームは完了しており、開発者は他のバージョンのChromiumと同じようにiOSバージョンのChromiumをコンパイルできます。 Chrome for iOSのすべてのテストがChromiumコミュニティ全体で利用可能になり、コードがチェックインされるたびに自動的に実行されるようになったため、開発速度も速くなりました。

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

最初の大きな一歩？ ：]

しかし、クロムはアップルストアに置くことが許可されていないので、それは何の意味もありません。

しかし、アンドロイドでは、それは今、切実に必要とされています。

CordovaとデフォルトのWebビューを使用した開発は地獄であり、IntelはCrosswalkを廃止しました。これは、AndroidへのデフォルトのWebビューとしてのIntelのクロムWebビューの移植版です。
https://crosswalk-project.org/blog/crosswalk-final-release.html

問題：

• デフォルトのwebviewは、さまざまなベンダーがさまざまなことを行っているため、信頼性が低くなっています。Androidの6.0までは安定していません。これは、使用している電話の20％にすぎません。
• 特に高価な3Gの帯域幅が制限されている地域では、すべての人がAn​​droidファームウェアやパッケージの更新を行っているわけではありません。

私たちにできること：

• Electron APIをchromeに移植することは不可能です（ @zcbenzが2014年に言ったように）
• Android用のchromuimとAndroid用のchromumwebviewが完全にオープンソースになりました： https ：//www.chromium.org/developers/how-tos/android-build-instructions
• 横断歩道をフォークして維持することができます（これは基本的に制限の少ないAndroidへのクロムの移植です） https://github.com/crosswalk-project 、それはすでにかなり安定しています。
• 私たちの経験では、優れたJSフレームワークを備えた横断歩道とコルドバがネイティブに近いパフォーマンス（Emberjs / React / Angular / Vue）を提供することが示されています。
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

横断歩道には寄稿者とメンテナーが必要です。それはあなたが探しているものかもしれません。

良いニュース

関連ニュース、 @orangemochaによるiOSへのNode.jsの新しい移植http://www.janeasystems.com/blog/node-js-meets-ios/

したがって、実行する必要がある唯一の作業は、 @ mikealが投稿したリンクを介してエミュレートされた場合に、モバイルブラウザがelectronをサポートすることを確認することです。

最近、iOSで他のJS VMを出荷することは合法ですか？ それとも、Appleはまだあなたに彼らのものを使うことを要求していますか？

実行可能コードを生成しない@trusktr出荷VMは、アプリストアのガイドラインに違反していません。 このようなアプリは以前にアプリストアで承認されています（ただし、ChakraCoreではなくSpiderMonkeyを使用しています）。

この問題を再開して、電子が将来サポートされるモバイルフレームワークを持つかどうかについての議論を続けることはできますか？

私はこれを2番目にします。 何をする必要がありますか？ 少しの指示でこれをテストまたはハッキングし始めることができてうれしいです。

@OtterCodeは、electron-mobileというリポジトリを作成し、そこでハッキングを開始するのが理にかなっていますか？ 何をする必要があるかを理解するために、サンプルアプリケーションを計画して準備するために必要なステップを見ることができました。 開始するためにエミュレートできる電子用のより高いレベルのAPIライブラリはありますか？ （APIドキュメント、ビルドターゲットなど）

@OtterCodeと私が作成した興味のある人、 https：//github.com/gabrielcsapo/electron-mobile 、興味のある人はあなたを所有者として追加でき、iOSとAndroidのビルドに向けた道を歩み始めることができます電子のターゲット。

Samsung Dex、 http：//www.samsung.com/global/galaxy/apps/samsung-dex/などの製品
これを実行可能なリクエストIMOにします（少なくともAndroidの場合）。

これは間違いなく非常に実行可能です。 たとえば、Google Playのアプリケーション「Termux」は、Debianベースのターミナル全体をアプリ内に提供します。 必要なものは何でもapt-get installできます（インストールするものがデバイスのCPUアーキテクチャをサポートしている限り、Node、Vim、Gitなど）。 Termuxと同様の独自のアプリサンドボックス環境でE​​lectronを実行することは完全に可能です。

Termuxは電話をルート化せずに動作し、アプリサンドボックス内にすべてをインストールします。また、外部ストレージをTermux内の「ホームフォルダー」にシンボリックリンクし、Termuxが提供するすべてのコマンドラインツールを使用して外部ストレージで作業することもできます。

Node.jsアプリは、Termuxから直接提供されるローカルホストのブラウザーで開くことができます。

Electronでこのようなことをすることは間違いなく可能です。

私はこれが起こることを本当に望んでいます、私はスタンドアロンのデスクトップベースのコンピュータ化されたシステムであった私の前のプロジェクトのためにElectronJSを使用しました。 Electronは非常に素晴らしかったです。今、会社は私を雇いたいと思っており、モバイルアプリを作成したいと考えています。彼らは、異なるプラットフォーム（iOS / Android）で複数のチームを持つという問題に耐えたくないので、PhoneGapを使用することを考えています。 、万能のソリューションを持つことは非常に素晴らしいことです。ElectronJSがモバイルをサポートするバージョンを持っていることを願っています。そのため、異なるプラットフォームや言語を切り替える必要がなく、本当に疲れることがあります。

react-nativeはこの問題の恒久的な修正ではありません

@aprilmintacpinedaすでにプログレッシブウェブアプリを調べましたか？ https://developers.google.com/web/progressive-web-apps/

@ Serkan-develはい、私はこの問題をここで見たとき、プログレッシブWebアプリに気づいていませんでした。 代わりにreact-nativeを使用することにしました。

@aprilmintacpinedaまだPWAを試すことができます、 https： //youtube.com/watch？v=vhg01Ml-8pI。 デスクトップでも役立ちます

nodejs-mobileをChromiumとどのように統合しますか？ これは、Electronがデスクトップに対して行ったことと同様に、ブラウザ環境でノードをモバイルに移行するための最も近いソリューションのようです。

（私はPWAが今日何ができるかを知っています、そしてWebアプリをモバイルアプリにラップするCordovaのようなフレームワークがありますが、PWAはOSレベルのファイルシステムにアクセスしたりHTTPサーバーを埋め込んだりすることはできません。私の現在のプロジェクトでは、AndroidとiOSの両方のセットアップとビルドのプロセスは言うまでもありません。）

モバイル向けのノード統合ブラウザの配布可能なバンドルにより、Electronを使用したデスクトップアプリの開発と同じくらい簡単に開発できたはずです。これがElectronの人気の理由だと思います。 モバイル用にまったく異なるコードを書く代わりに、多くのコードも再利用可能です。

私はWeb開発者であり、複雑なブラウザーをNodeと統合することは言うまでもなく、システム/ネイティブアプリケーションの構築に関する専門知識を持っていないため、ポインターをいただければ幸いです。 あなたが専門知識を持っていて、そのようなプロジェクトの作成を手伝いたいのであれば、あなたは貢献することを歓迎します。

これは達成可能ですが、本当にこれを行うべきかどうかを考え直す必要があると思います。 電子を使用したデスクトップアプリでは、特にcssアニメーションでラグが発生しました。 ネイティブオプションがある場合は、ネイティブを選択したいと思います。ネイティブには提供できるものがたくさんあります。 または、PWAを試してみてください。 それは素晴らしいですが、まだアプリの代わりにはなりませんが、素晴らしい未来があると思います。

マーク

https://github.com/dna2github/dna2oslab

Androidでうまく機能するnodejs

これはElectronとまったく同じではありませんが、Node.jsを使用してAndroidアプリを構築したい人にとって、このライブラリは私のテストではうまく機能しているようです。