Electron: Dukungan Seluler

Saya pikir atom-shell terutama dibuat untuk editor teks atom, jadi saya tidak berharap itu mendukung platform seluler. Ada Phonegap dan Cordova untuk aplikasi seluler HTML5.

Ya, tapi ini tentang berbagi kode dari modul node.js dan untuk mengakses sumber daya tingkat rendah

Untuk platform seluler, hampir semua API atom-shell tidak berlaku, jadi saya rasa kami tidak akan pernah mendukung platform seluler.

Mungkin kalian setidaknya bisa bermain baik dengan Cordova, dll, dengan (entah bagaimana) mendeteksi lingkungan (saat runtime, atau ditentukan selama build) sehingga Electron API cukup memanggil modul Cordova (atau kode asli) tanpa kita sadari. Itu akan sangat luar biasa.

+1 @trusktr

@trusktr Kedengarannya seperti modul pihak ketiga yang hebat yang akan memberikan shim kompatibilitas untuk Cordova

Saya sangat berharap ini terjadi. Saya pikir masa depan platform web perlu bergerak ke arah ini, sehingga kami dapat menulis aplikasi lintas platform yang BENAR-BENAR. Saya sangat berharap ini tidak dikesampingkan.

Saya tidak percaya ini sudah 2016 dan masih belum ada yang seperti itu.

@emin93 ini tidak konstruktif, seperti yang telah ditunjukkan oleh @zcbenz , hampir tidak mungkin untuk mem-porting Electron API ke seluler.
Anda tidak bisa hanya menuntut fitur tanpa setidaknya semacam saran tentang cara mewujudkannya.

@YuriSolovyov Saya tidak merujuk ke Elektron secara langsung. Sebenarnya tidak ada alternatif dan itulah yang membuat saya frustrasi. Tapi ya, Anda benar, itu sebenarnya bukan tempat yang tepat untuk membahas itu.

Elektron untuk seluler akan sangat mengagumkan. Saya memiliki beberapa Aplikasi Elektron yang dikembangkan dan menyukai kerangka kerja ini, tetapi setiap hari saya berharap kami akan melihatnya bekerja di Seluler juga.

Satu-satunya kerangka kerja lintas platform yang menunjukkan dukungan lintas platform ujung ke ujung (IOS, Android, Windows, OSX, Linux) adalah Xamarin tetapi memerlukan kode dalam C#. Saya tidak akan terkejut jika Xamarin mengizinkan kode JS segera setelah Microsoft sekarang memiliki Xamarin dan juga telah membuat langkah besar dengan porting node ke mesin JS mereka sendiri.

Saya sangat berharap bahwa beberapa sponsor korporat dapat bergabung untuk mendanai port/garpu elektron untuk seluler yang pada akhirnya akan dimasukkan ke dalam kerangka kerja yang sama sehingga kami dapat memiliki kerangka kerja pengembangan aplikasi lintas platform berbasis JS penuh.

Terima kasih tim Electron untuk pekerjaan hebat Anda!

Menggemakan pertanyaan awal dari @cjfromthesea , dapatkah seseorang menjelaskan masalah yang ada dengan API Electron di ponsel (mungkin @zcbenz)? Dengan beberapa panduan umum, saya dan orang lain berpotensi mulai memikirkan cara mengatasi masalah dengan meretas dan mengutak-atik. Saya sudah sedikit berurusan dengan jxcore-cordova, tetapi beberapa panduan akan menyenangkan. Apa penghalang jalan?

@lastmjs hambatan besar adalah bahwa Electron menggunakan V8 yang tidak didukung di iOS. Ini berarti Chromium dan Node.js juga tidak akan berfungsi di iOS dan ketiganya adalah komponen utama Electron.

Versi chromium baru untuk IOS dirilis pada bulan Januari, dan node.app mungkin dapat melakukan trik untuk node.js. Dan Android seharusnya tidak menjadi masalah mengingat V8 didukung.
Sementara itu, kami dapat menulis dokumentasi tentang cara menggunakan Cordova dengan elektron untuk IOS (karena saya sangat membutuhkannya, saya akan dengan senang hati membantu).

@noelmace Chrome untuk iOS tidak menggunakan mesin Chromium karena Apple tidak mengizinkannya. Hanya saja WKWebView seperti Safari menggunakannya, tetapi dengan UI yang berbeda.

@emin93 Apakah Terapkan mengizinkan penggunaan penerjemah khusus seperti node.app?

Saya memiliki beberapa pertanyaan yang ingin saya pikirkan dari mereka yang ada di utas ini—

• Apakah Anda ingin membangun _satu aplikasi yang berjalan di mana-mana_?
  
  
  
  • Pertanyaan lanjutan, apakah ada contoh aplikasi desktop (yang bukan aplikasi web) yang juga merupakan aplikasi seluler?
  
  
• Atau apakah Anda mencari aplikasi Electron yang membangun _experience_ tetapi di seluler?
  
  
  
  • Pertanyaan lanjutan, apa bedanya dengan Cordova/PhoneGap (atau lainnya)?
  
  

Saya pasti mencari satu aplikasi yang dapat berjalan di mana-mana. Satu basis kode, satu platform web, lingkungan apa pun.

Contoh aplikasi seluler/desktop/web yang bagus, di mana ukuran layar dan perangkat tidak terlalu penting, tetapi Anda mungkin menginginkan fungsi yang sama:

• Chrome
• Firefox
• Kendur
• Gmail
• Google Foto
• Google Maps

Tidak semua aplikasi di atas harus menjalankan versi desktop dengan executable asli, tetapi mereka memiliki versi desktop di browser. Bagi saya, tentu saja itu tergantung kasus per kasus, tetapi umumnya saya ingin aplikasi saya menjadi aplikasi saya, apa pun perangkatnya. Saya berusaha untuk fitur yang sama di semua perangkat sebanyak mungkin. Kenapa tidak? Saya ingin Chrome berfungsi sama di desktop saya seperti di Android, iPhone, atau tablet saya, sama untuk Firefox, slack, Google Maps. Saya merasa sedih ketika terkadang fitur Google Maps bersifat khusus untuk platform. Kembali ke Chrome, saya ingin dapat melihat sumber dan bahkan menggunakan debugger, bahkan di ponsel saya. Saya terkadang berpikir kita tidak memiliki pandangan ke depan untuk membatasi fungsionalitas aplikasi kita dengan tepat. Bagaimana jika seseorang menginginkan fitur yang berfungsi pada versi desktop aplikasi di ponsel mereka? Aplikasi harus responsif tentu saja, tetapi fungsionalitas inti harus tetap sama sejauh mungkin menurut saya.

Terima kasih @lastmjs. Saya baru saja mengedit pertanyaan saya karena apa yang saya pikirkan, tetapi belum ditentukan, adalah aplikasi desktop yang juga merupakan aplikasi seluler tetapi bukan aplikasi web. Saya pikir ini adalah perbedaan penting.

tetapi fungsionalitas inti harus tetap sama sejauh mungkin menurut saya

Berpikir keras di sini: Electron membuat API untuk perilaku aplikasi desktop asli yang umum—tampaknya jika Anda juga menambahkan di seluler, kesamaan di antara semua ini akan menyusut. Aplikasi yang didasarkan pada kesamaan antara desktop dan seluler mungkin pada akhirnya berfungsi di mana saja, tetapi menjadi pengalaman seluler di bawah standar dan pengalaman desktop di bawah standar?

Apakah perilaku aplikasi desktop asli umum yang Anda bicarakan sebagian besar berbasis UI? Saya dapat melihat bagaimana menu asli dan perilaku lainnya mungkin tidak diterjemahkan dengan baik. Manfaat terbesar bagi saya adalah memiliki satu runtime terkonsolidasi, di mana saya memiliki akses ke Node.js dan Chromium API, dan mengatakan runtime dapat diterapkan ke semua platform utama. Electron dan Cordova dengan cara yang sama melakukan hal yang sama untuk platform yang berbeda, minus fungsionalitas UI seperti yang mungkin telah Anda bicarakan. Dengan Cordova, Anda memiliki satu basis kode yang dapat digunakan ke beberapa sistem operasi seluler utama, kata sistem operasi seluler yang fungsinya tidak terlalu berbeda dari sistem operasi desktop utama. Sistem operasi mengelola proses dan sumber dayanya, dan memberikan akses ke perangkat keras yang mungkin dibutuhkan oleh proses tersebut. Tidak ada banyak perbedaan mendasar antara sistem operasi seluler dan desktop. Dan dengan browser yang mulai memiliki API perangkat keras, platform web menjadi semakin universal dalam kemampuannya untuk diterapkan di semua lingkungan utama. Jadi seperti yang saya lihat, Cordova dan Electron menyelesaikan sebagian besar tugas yang sama tetapi pada sistem operasi yang berbeda, mengatakan sistem operasi tidak berbeda secara fundamental, jadi mengapa tidak menggabungkannya? 😃.

@jlord

Saya membangun untuk seluler dan desktop dan ingin menambahkan komentar dari @lastmrs dan @noelmace

Inilah pemikiran saya tentang bagaimana ini bisa bekerja untuk semua orang.

API yang diekspos elektron harus bervariasi berdasarkan apakah itu seluler atau desktop. Jadi, pengembang bertanggung jawab untuk melakukan deteksi lingkungan waktu proses (yang disediakan oleh lapisan elektron) untuk memanggil API yang berbeda tergantung pada konteks lingkungan.
Sekali lagi untuk menjadi jelas, terserah pada pengembangan untuk melakukan hal yang benar

Sejauh aspek UI, sekali lagi terserah pengembang untuk melakukan hal yang benar. Saya menggunakan polimer untuk semua proyek desktop dan seluler saya, dan saya harus melakukannya dengan benar.
Saya juga menggunakan golang untuk menulis hal-hal terkompilasi yang saya butuhkan di desktop dan seluler untuk mengakses perangkat keras apa pun.

Saat membangun, saya mengemas untuk desktop ( amd 64, dll, dll) dan seluler (Android atau iOS) di mana saya membuat paket terpisah untuk setiap OS dan arsitektur chip. Saya melakukan hal yang sama dengan elektron. Ini memungkinkan saya untuk melakukan kompilasi perbedaan waktu yang saya butuhkan karena beberapa kode bergantung pada perangkat keras.
Saya masih dapat memasukkan kode yang sama di semua build dan melakukan runtime sniffing, dan di sinilah elektron akan memberi saya konteks lingkungan.

Hal hebat yang disediakan ini adalah perkakas umum pada waktu desain dan waktu kompilasi. Ini adalah peningkatan produktivitas yang sangat besar bagi pengembang karena Anda dapat menginstal elektron dan menjalankan skrip bootstrap bash untuk menginstal bit iOS dan Android dan tulisan Anda hello world serta mengemas dan menyebarkan ke desktop dan seluler.

Saya tidak tahu bahwa tim Google telah memperbarui chrome untuk iOS menjadi multi-proses. Saya sangat bersemangat untuk melihat ini.

Jika saya dapat membantu dengan semua ini, saya akan dengan senang hati membantu.

Ini akan menjadi peningkatan besar untuk banyak proyek saya juga. Seseorang sudah harus membuat perubahan pada UI berdasarkan apakah itu seluler atau tidak, mungkin juga melakukan deteksi/perubahan lain juga.

Saya tidak berpikir memiliki dua API terpisah adalah ide yang bagus (@ joeblew99). Untuk end user, saya rasa akan lebih baik jika Electron membuat API-nya bekerja di atas Cordova atau Node, sehingga end user hanya perlu mengetahui satu API (Electron API). Kemudian jika ada sesuatu yang tidak tercakup oleh API, pengguna akhir dapat menyelami Node atau Cordova sesuai kebutuhan.

Juga, saya pikir akan penting bagi Electron untuk menentukan cara menggunakan alur kerja NPM yang berfungsi di kedua kasus (Cordova atau langsung di Node). Yaitu, Electron harus mendefinisikan sistem build-nya agar kompatibel dengan keduanya, menggunakan NPM (dan modul ES6 juga akan lebih baik) sehingga pengguna akhir tidak perlu khawatir tentang bagaimana membangun masing-masing. Kasing Node sudah ditangani, tentu saja, tetapi mungkin perlu ada pekerjaan tambahan agar NPM berfungsi dengan baik di Cordova.

Perhatikan bahwa di Cordova Node.js API tidak tersedia, jadi Electron perlu polifill beberapa modul Node.js asli dengan alternatif yang berfungsi di Cordova, mirip dengan apa yang dilakukan Browserify untuk browser. Ini akan membantu dalam membuat API terpadu, karena jika ada sesuatu yang tidak dicakup oleh API Elektron, maka setidaknya lib yang diisi poli berarti pengguna dapat kembali ke API berbasis Node yang di belakang layar memanggil Cordova API.

Kebutuhan untuk polyfill adalah apa yang menurut saya lebih cerdas untuk memulai dengan rute API. Itu tidak harus menjadi API yang terpisah, hanya beberapa fitur yang tidak langsung tersedia. Jika Anda melakukannya dan membuatnya 100% kompatibel, maka itu adalah masalah yang jauh lebih besar untuk dihadapi ketika fitur-fitur baru ditambahkan di kemudian hari.

Saya juga ingin menunjukkan bahwa Android dan iOS tidak hanya mobile lagi. Proyek yang sedang saya kerjakan akan terlihat luar biasa di TV Android, ditambah lagi saya tidak mengerti mengapa Github tidak ingin membuat Atom berjalan di TV atau Tablet.

Poin bagus, ini bukan tentang ukuran layar lagi, kami mulai berurusan dengan sistem operasi tujuan umum.

Saya bingung dengan status Electron di Android?

Apakah itu sesuatu yang secara aktif sedang dipertimbangkan atau hanya sesuatu yang dibicarakan?

Menjadikan aplikasi Electron sebagai target yang valid untuk aplikasi PhoneGap atau Cordova adalah sekitar 1000X lebih mudah!
yaitu. cordova platform add electron-osx electron-win electron-linux

@purplecabbage yakin tetapi kemudian Anda kehilangan semua manfaat tambahan dari mengendalikan seluruh browserstack.

RE: Node.js Polyfill.

Kita harus memulai daftar _native_ polyfill yang diperlukan agar ini berfungsi. Browserify sudah memiliki versi web murni dari _lot_ Node.js Core. Satu-satunya yang dapat saya pikirkan yang kita perlukan adalah:

• dns
• net
• fs

Ada yang lain?

Objek Global:

• __dirname
• __nama file
• proses

@purplecabbage sepertinya ketiganya memiliki implementasi browserify. https://github.com/substack/browserify-handbook#__dirname. Haruskah kita memberi mereka nilai yang berbeda berdasarkan perangkat?

ya, __dirname dan __filename bukan masalah besar.
prosesnya barebone di browserify, bukankah kami ingin mendukung acara?
https://github.com/defunctzombie/node-process/blob/master/browser.js

Untuk aplikasi Native Mobile yang berbagi kode dengan electron.js, saya pikir yang terbaik adalah menjelajahi rute dengan menggabungkan Electron.js dengan NativeScript - http://github.com/NativeScript/NativeScript.

Kami (tim NativeScript) berencana untuk membuat aplikasi demo sampel, jika Anda tertarik, beri komentar tentang masalah ini - https://github.com/NativeScript/NativeScript/issues/2695

Sebenarnya, sudah tersedia benih lanjutan Angular 2 yang memungkinkan ini - https://github.com/NathanWalker/angular2-seed-advanced. Tetapi angular 2 sama sekali bukan persyaratan untuk mengimplementasikan solusi semacam itu.

Apakah ini sesuatu yang masuk akal?

Saya pikir kuncinya adalah tim Anda telah melakukan kerja keras untuk menambahkan API asli. Saya mendukung ide Anda.

@valentinstoychev itu ide yang sangat menarik meskipun pada dasarnya berarti setiap aplikasi elektron harus mengulang seluruh UI kan? Akan sangat menarik jika Anda bisa memasukkan libchromiumcontent untuk membuat webview yang mirip dengan electron . Maka akan lebih mudah untuk menggunakan keduanya dalam satu aplikasi.

Bagaimana dengan widget Android WebView dan yang setara di iOS? Padahal yang Android sudah chromium. :)

@hadees ya, idenya adalah untuk mengimplementasikan UI seluler sekali untuk iOS dan Android menggunakan NativeScript dan sekali untuk desktop menggunakan elektron. Segala sesuatu yang lain - data, model, logika bisnis, layanan, akses data harus sama.

Ada dua hal yang perlu diperhatikan di sini.

Pertama, Anda akan menggunakan keahlian yang hampir sama (artinya satu tim dapat membuatnya untuk desktop, web, dan seluler) saat membangun dengan electron.js dan NativeScript - semuanya adalah JavaScript/TypeScript/CSS. Anda dapat menggunakan Angular 2 jika Anda mau. Untuk penataan, Anda akan menggunakan CSS untuk NativeScript dan elektron. _Jadi umumnya satu-satunya hal yang akan berbeda adalah markup UI_. Bahkan tata letaknya harus familier karena kami akan merilis tata letak FlexBox bulan depan. Segala sesuatu yang lain adalah kode yang dapat digunakan kembali dan yang paling penting adalah kumpulan keterampilan yang dapat digunakan kembali. Bagian perkakas juga harus familier karena di NativeScript kami menggunakan Chrome Devtools...

Hal kedua yang perlu diperhatikan di sini adalah Anda sebenarnya ingin memiliki UI yang berbeda untuk seluler dan desktop, bukan. Jadi, dalam banyak/sebagian besar kasus, bagian UI tidak akan digunakan kembali dan harus berbeda.

Saya percaya ini adalah cerita yang cukup menarik dan kami akan menjelajahinya dan menunjukkan contoh kehidupan nyata segera. Saya harap melihat kode aktual dan aplikasi aktual akan membantu sedikit memperjelas apakah perlu ditelusuri atau tidak.

Bagaimanapun, aplikasi akhir (atau aplikasi) akan dengan UI asli di mana saja. Dan saya pikir inilah yang membuat solusi ini unik dan layak untuk ditelusuri. Juga murah untuk diretas karena tidak ada perubahan yang perlu dilakukan pada electron.js dan NativeScript. Mulai dari solusi pertama ini, kami dapat menemukan area di mana kolaborasi yang lebih erat dapat terjalin.

Saya telah menggunakan polimer untuk GUI desktop dan seluler, dengan Cordova. Cordova
mendukung desktop dan seluler.

Kuncinya bagi saya adalah menggunakan grpc sebagai teknologi pengikatan. Ini membuatnya banyak
lebih mudah karena klien dan server dapat saling beroperasi.

Untuk semua, saya hanya membutuhkan plugin proxy grpc untuk bertindak sebagai perantara

Pada Sabtu, 10 Sep 2016, 08:17 Valentin Stoychev, [email protected]
menulis:

@hadees https://github.com/hadees ya, idenya adalah untuk mengimplementasikan
UI seluler sekali untuk iOS dan Android menggunakan NativeScript dan sekali untuk desktop
menggunakan elektron. Segala sesuatu yang lain - data, model, logika bisnis, layanan,
akses data harus sama.

Ada dua hal yang perlu diperhatikan di sini.

Pertama, Anda akan menggunakan _skillset_ yang hampir sama (artinya satu tim bisa
membuatnya untuk desktop, web, dan seluler) saat membangun dengan electron.js dan
NativeScript - semuanya adalah JavaScript/TypeScript/CSS. Anda dapat menggunakan Sudut 2
jika kamu suka. Untuk penataan, Anda akan menggunakan CSS untuk NativeScript dan
elektron. _Jadi umumnya satu-satunya hal yang akan berbeda adalah UI
markup_. Bahkan tata letaknya harus familier saat kami merilis FlexBox
tata letak bulan depan. Yang lainnya adalah kode yang dapat digunakan kembali dan yang paling penting
keterampilan yang dapat digunakan kembali.

Hal kedua yang perlu diperhatikan di sini adalah Anda benar-benar ingin memiliki yang berbeda
UI untuk seluler dan desktop, kan. Jadi, dalam banyak/sebagian besar kasus, UI
bagian tidak akan digunakan kembali pula dan harus berbeda.

Saya percaya ini adalah cerita yang cukup menarik dan kami akan menjelajahinya dan
menunjukkan contoh kehidupan nyata segera. Saya harap melihat kode yang sebenarnya dan
aplikasi yang sebenarnya akan membantu menghapus sedikit jika perlu ditelusuri atau tidak.

Bagaimanapun, aplikasi akhir (atau aplikasi) akan dengan UI asli di mana saja.
Dan saya pikir inilah yang membuat solusi ini unik dan layak untuk ditelusuri. Dia
juga murah untuk diretas karena tidak ada perubahan yang perlu dilakukan pada
baik electron.js dan NativeScript. Mulai dari solusi pertama ini, kami
mungkin menemukan area di mana kolaborasi yang lebih erat dapat terjalin.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/electron/electron/issues/562#issuecomment -246093147,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ALcac7syNn7D8eztsREVxIyrrl7mBJs4ks5qokuQgaJpZM4CVUMK
.

NativeScript sebenarnya bukan pilihan untuk dukungan seluler Electron, karena
itu benar-benar mengubah paradigma dari teknologi web ke JavaScript
binding untuk widget asli. Intinya, apa yang kita miliki tidak akan lagi
"Elektron", karena Elektron pada intinya adalah tumpukan browser yang mengekspos
Node.js _inside_ dari konteks browser, dan itulah yang membuat Electron
Elektron.

Binding NativeScript + Node.js dapat dianggap sama sekali berbeda
proyek.

Pertama, Anda akan menggunakan keahlian yang hampir sama (artinya satu tim dapat membuatnya untuk desktop, web, dan seluler) saat membangun dengan electron.js dan NativeScript - semuanya adalah JavaScript/TypeScript/CSS.

Belum tentu benar, karena dengan NativeScript Anda harus memilikinya
pemahaman tentang bagaimana widget asli berperilaku, terlepas dari kenyataan bahwa
Anda mengkode dalam JavaScript. Artinya, tanpa sepengetahuan
widget, dan tanpa pengetahuan tentang cara memodifikasi ikatan widget tersebut dengan
kode asli, kemudian melakukan sesuatu yang khusus menjadi sangat sulit, yaitu
tidak demikian halnya dengan JS/HTML/CSS murni dalam tumpukan web, karena dengan tumpukan web
memodifikasi internal berarti memodifikasi jenis kode yang sama di lingkungan yang sama dengan tempat Anda berada, tidak perlu khawatir tentang bahasa asing.

Hal kedua yang perlu diperhatikan di sini adalah Anda sebenarnya ingin memiliki UI yang berbeda untuk seluler dan desktop, bukan. Jadi, dalam banyak/sebagian besar kasus, bagian UI tidak akan digunakan kembali dan harus berbeda.

Salah satu keuntungan menggunakan Electron (dengan front-end berbasis Web-nya), adalah
bahwa kita menulis satu kode, dan perilakunya hampir _persis sama_
di mana pun. Ini tidak akan selalu terjadi dengan NativeScript, yang
mencoba menjembatani rangkaian teknologi yang sama sekali berbeda dengan satu bahasa.

Saya pribadi lebih menyukai ide menggunakan web-ui di mana saja,
versus UI asli yang berbeda di mana-mana. Beberapa orang percaya bahwa UI Asli
jauh lebih baik daripada UI Web. Memang benar sampai batas tertentu, dan memang begitu
dengan pengembang yang tidak mengetahui dasar-dasar web sepenuhnya. Tetapi dengan
penggunaan yang tepat dari web API sebenarnya kita bisa membuat UI yang bagus. Web menjadi besar
kemajuan. WebGL sangat lintas platform...

_/#!/_JoePea

Pada Jum, 9 Sep 2016 jam 23:17, Valentin Stoychev < [email protected]

menulis:

@hadees https://github.com/hadees ya, idenya adalah untuk mengimplementasikan
UI seluler sekali untuk iOS dan Android menggunakan NativeScript dan sekali untuk desktop
menggunakan elektron. Segala sesuatu yang lain - data, model, logika bisnis, layanan,
akses data harus sama.

Ada dua hal yang perlu diperhatikan di sini.

Pertama, Anda akan menggunakan _skillset_ yang hampir sama (artinya satu tim bisa
membuatnya untuk desktop, web, dan seluler) saat membangun dengan electron.js dan
NativeScript - semuanya adalah JavaScript/TypeScript/CSS. Anda dapat menggunakan Sudut 2
jika kamu suka. Untuk penataan, Anda akan menggunakan CSS untuk NativeScript dan
elektron. _Jadi umumnya satu-satunya hal yang akan berbeda adalah UI
markup_. Bahkan tata letaknya harus familier saat kami merilis FlexBox
tata letak bulan depan. Yang lainnya adalah kode yang dapat digunakan kembali dan yang paling penting
keterampilan yang dapat digunakan kembali.

Hal kedua yang perlu diperhatikan di sini adalah Anda benar-benar ingin memiliki yang berbeda
UI untuk seluler dan desktop, kan. Jadi, dalam banyak/sebagian besar kasus, UI
bagian tidak akan digunakan kembali pula dan harus berbeda.

Saya percaya ini adalah cerita yang cukup menarik dan kami akan menjelajahinya dan
menunjukkan contoh kehidupan nyata segera. Saya harap melihat kode yang sebenarnya dan
aplikasi yang sebenarnya akan membantu menghapus sedikit jika perlu ditelusuri atau tidak.

Bagaimanapun, aplikasi akhir (atau aplikasi) akan dengan UI asli di mana saja.
Dan saya pikir inilah yang membuat solusi ini unik dan layak untuk ditelusuri. Dia
juga murah untuk diretas karena tidak ada perubahan yang perlu dilakukan pada
baik electron.js dan NativeScript. Mulai dari solusi pertama ini, kami
mungkin menemukan area di mana kolaborasi yang lebih erat dapat terjalin.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/electron/electron/issues/562#issuecomment -246093147,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AASKzg6ISiScLgMY1lz83Ff3MxHq3e0Mks5qokuPgaJpZM4CVUMK
.

@trusktr Saya sepenuh hati setuju. Saya pikir ada terlalu banyak stok yang dimasukkan ke dalam tampilan asli oleh pengembang. Asli bahkan bukan ideal yang konsisten. Dalam satu dekade terakhir, antarmuka seluler telah berubah puluhan kali, dan bahkan tidak konsisten dari satu ponsel Android ke ponsel lainnya.

Membuat aplikasi Anda terlihat konsisten di semua platform tempat pengguna dapat mengaksesnya adalah standar yang jauh lebih baik untuk dipegang. Membuat mereka mempelajari dua set simbol dan sinyal UI hanya untuk mengoperasikan aplikasi di mesin kerja iPhone dan Windows mereka sangat buruk.

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

Secara historis, kode untuk Chrome untuk iOS disimpan terpisah dari proyek Chromium lainnya karena kompleksitas tambahan yang diperlukan untuk platform. Setelah bertahun-tahun melakukan pemfaktoran ulang secara hati-hati, semua kode ini bergabung kembali dengan Chromium dan dipindahkan ke repositori sumber terbuka.

Karena keterbatasan platform iOS, semua browser harus dibangun di atas mesin rendering WebKit. Untuk Chromium, ini berarti mendukung WebKit serta Blink, mesin rendering Chrome untuk platform lain. Itu menciptakan beberapa kerumitan ekstra yang ingin kami hindari untuk ditempatkan di basis kode Chromium.

Mengingat komitmen Chrome terhadap kode sumber terbuka, kami telah menghabiskan banyak waktu selama beberapa tahun terakhir untuk membuat perubahan yang diperlukan untuk meningkatkan kode Chrome untuk iOS ke Chromium. Hari ini, upstreaming itu selesai, dan pengembang dapat mengompilasi Chromium versi iOS seperti yang mereka bisa untuk versi Chromium lainnya. Kecepatan pengembangan juga lebih cepat sekarang karena semua pengujian untuk Chrome untuk iOS tersedia untuk seluruh komunitas Chromium dan dijalankan secara otomatis setiap kali kode tersebut diperiksa.

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

Langkah besar pertama? :]

Tapi itu tidak berarti apa-apa karena chromium tidak boleh ditaruh di apple store.

Tapi di android, itu sangat dibutuhkan sekarang.

Berkembang dengan cordova dan tampilan web default adalah neraka , dan intel telah menghapus Crosswalk , yang merupakan port intel dari chromium webview sebagai tampilan web default untuk Android.
https://crosswalk-project.org/blog/crosswalk-final-release.html

Masalah:

• tampilan web default tidak dapat diandalkan berkat vendor yang berbeda melakukan hal yang berbeda. ini tidak stabil hingga 6.0 android, yang hanya 20% ponsel yang menggunakan.
• tidak semua orang melakukan pembaruan firmware atau paket android, terutama di area terbatas bandwidth dengan 3G yang mahal.

Apa yang bisa kita lakukan:

• API Elektron tidak mungkin di-port ke chrome ( seperti yang dikatakan @zcbenz pada tahun 2014 )
• chromium untuk android dan tampilan web chromium untuk android sepenuhnya opensource sekarang: https://www.chromium.org/developers/how-tos/android-build-instructions
• Kami dapat bercabang dan terus memelihara penyeberangan (Yang pada dasarnya adalah port chromium ke android dengan batasan yang lebih sedikit) https://github.com/crosswalk-project , ini sudah cukup stabil.
• Pengalaman kami menunjukkan bahwa penyeberangan dan cordova dengan Kerangka JS yang baik memberikan kinerja Near-Native ( Emberjs / React / Angular /Vue ) .
  https://github.com/crosswalk-project/cordova-plugin-crosswalk-webview

kami membutuhkan kontributor dan pengelola di penyeberangan, yang mungkin Anda cari.

Kabar baik

Berita yang relevan, port baru Node.js ke iOS oleh @orangemocha http://www.janeasystems.com/blog/node-js-meets-ios/

jadi satu-satunya upaya yang perlu dilakukan adalah memastikan bahwa browser seluler mendukung elektron jika ditiru melalui tautan yang diposting @mikeal ?

Apakah legal untuk mengirim VM JS lain di iOS saat ini? Atau apakah Apple masih mengharuskan Anda untuk menggunakan milik mereka?

@trusktr pengiriman VM yang tidak menghasilkan kode yang dapat dieksekusi tidak melanggar pedoman toko aplikasi. Kami telah mendapatkan aplikasi seperti itu disetujui di app store sebelumnya (meskipun menggunakan SpiderMonkey dan bukan ChakraCore).

Bisakah kita membuka kembali masalah ini untuk melanjutkan diskusi tentang apakah elektron akan memiliki kerangka kerja seluler yang didukung di masa depan?

Saya kedua ini. Apa yang perlu dilakukan? Saya senang untuk mulai menguji atau meretas ini dengan sedikit arahan.

@OtterCode apakah masuk akal untuk membuat repo yang disebut elektron-mobile dan mulai meretas di sana? Saya dapat melihat langkah perencanaan yang diperlukan dan menyiapkan contoh aplikasi untuk mulai mencari tahu apa yang perlu dilakukan. Apakah ada perpustakaan api tingkat yang lebih tinggi untuk elektron yang dapat kita tiru untuk memulai? (Api docs, membangun target, dll)

@OtterCode dan siapa pun yang tertarik telah saya buat, https://github.com/gabrielcsapo/electron-mobile , jika ada yang tertarik, saya dapat menambahkan Anda sebagai pemilik dan kami dapat mulai mengerjakan jalur ke depan untuk iOS dan Android build target untuk elektron.

Produk seperti Samsung Dex, http://www.samsung.com/global/galaxy/apps/samsung-dex/
Jadikan ini sebagai permintaan IMO yang layak (setidaknya untuk Android).

Ini pasti sangat bisa dilakukan. Aplikasi "Termux" dari Google Play, misalnya, memberi kita seluruh terminal berbasis Debian tepat di aplikasi. Kita dapat apt-get install apa pun yang kita butuhkan (Node, Vim, Git, dll, selama hal yang kita instal mendukung arsitektur CPU perangkat). Sangat mungkin untuk menjalankan Electron di lingkungan kotak pasir aplikasinya sendiri yang mirip dengan Termux.

Termux bekerja tanpa me-rooting ponsel kita, menginstal semua yang ada di dalam kotak pasir aplikasi, dan kita bahkan dapat menghubungkan penyimpanan eksternal kita ke "folder rumah" kita di dalam Termux dan bekerja di penyimpanan eksternal kita menggunakan semua alat baris perintah yang diberikan Termux kepada kita.

Kami dapat membuka aplikasi Node.js di browser kami, di localhost, dilayani langsung dari di Termux.

Sangat mungkin untuk melakukan sesuatu seperti ini dengan Electron.

Saya sangat berharap ini akan terjadi, saya telah menggunakan ElectronJS untuk proyek saya sebelumnya yang merupakan sistem komputerisasi berbasis desktop yang berdiri sendiri. Electron sangat hebat, sekarang sebuah perusahaan ingin mempekerjakan saya dan mereka ingin membuat aplikasi seluler, mereka berpikir untuk menggunakan PhoneGap untuk itu karena mereka tidak ingin menanggung kesulitan memiliki banyak tim untuk platform yang berbeda (iOS/Android) , memiliki solusi satu-untuk-semua sangat hebat, dan saya berharap ElectronJS dapat memiliki versi yang mendukung seluler sehingga saya tidak perlu beralih di antara platform dan bahasa yang berbeda, terkadang sangat melelahkan.

react-native bukan perbaikan permanen untuk masalah ini

@aprilmintacpineda apakah Anda sudah melihat Aplikasi Web Progresif? https://developers.google.com/web/progressive-web-apps/

@Serkan-devel ya saya punya, saya tidak mengetahui aplikasi web progresif ketika saya melihat masalah ini di sini. Saya memutuskan untuk menggunakan reaksi-asli sebagai gantinya.

@aprilmintacpineda Anda masih bisa mencoba PWA juga, https://youtube.com/watch?v=vhg01Ml-8pI . Ini juga membantu di desktop

Bagaimana cara mengintegrasikan nodejs-mobile dengan Chromium ? Ini sepertinya solusi terdekat untuk membawa Node ke seluler di lingkungan browser, mirip dengan apa yang telah dilakukan Electron untuk desktop.

(Saya mengetahui apa yang dapat dilakukan PWA hari ini , dan ada kerangka kerja seperti Cordova untuk membungkus aplikasi web ke dalam aplikasi seluler, tetapi PWA tidak dapat mengakses sistem file tingkat OS atau menyematkan server HTTP, dan Cordova hanyalah pekerjaan yang berlebihan. untuk proyek saya saat ini, belum lagi proses penyiapan dan pembuatan untuk Android & iOS.)

Bundel browser terintegrasi Node yang dapat didistribusikan untuk seluler akan membuat pengembangan semudah mengembangkan aplikasi desktop dengan Electron, yang menurut saya itulah yang membuat Electron begitu populer. Banyak kode juga dapat digunakan kembali alih-alih menulis kode yang sama sekali berbeda untuk seluler.

Saya seorang pengembang web dan tidak memiliki keahlian dalam membangun sistem/aplikasi asli, apalagi mengintegrasikan browser yang kompleks dengan Node, jadi petunjuk apa pun akan sangat dihargai. Jika Anda memiliki keahlian dan ingin membantu membuat proyek semacam itu, Anda dipersilakan untuk berkontribusi.

Meskipun ini mungkin untuk dicapai, saya pikir kita harus berpikir dua kali jika kita benar-benar harus melakukan ini. Pada aplikasi desktop tempat saya menggunakan elektron, saya mengalami kelambatan, terutama dengan animasi css. Jika ada opsi asli, saya lebih suka memilih yang asli, yang asli memiliki banyak hal untuk ditawarkan. Atau mungkin mencoba PWA. Ini luar biasa, tetapi BELUM pengganti untuk aplikasi, tetapi saya pikir ini memiliki masa depan yang cerah.

tanda

https://github.com/dna2github/dna2oslab

nodejs yang dapat bekerja dengan baik di android

Ini tidak persis seperti Electron, tetapi bagi siapa saja yang ingin membangun aplikasi Android dengan Node.js, perpustakaan ini tampaknya berfungsi dengan baik dalam pengujian saya.