Flutter: Kode Push / Pembaruan Panas / pembaruan di luar band

cc @floitschG

lihat juga
https://groups.google.com/forum/#!msg/flutter -dev/YwzItp1pxJo/7bFGDLvxBAAJ
Saya akan sangat bersemangat tentang ini.

Saya akan berpikir ini akan cukup penting karena ini mungkin satu-satunya fitur yang benar-benar khas dari reaksi asli, dan sayangnya beberapa perusahaan mungkin menganggap ini sebagai dealbreaker.

Gunakan kasus

• bug kritis, terutama di iOS, terutama untuk VIP atau situasi mendesak, sensitif waktu, kritis bisnis, dan/atau pengguna yang tidak dapat menggunakan aplikasi sama sekali karena alasan tertentu.
• Pengujian fitur yang lebih dinamis daripada peluncuran bertahap
• ini akan menjadi sentuhan yang bagus untuk mempersiapkan Fuschia, dan/atau Chromebook. mungkin ada skenario di mana flutter "bersaing" dengan aplikasi web bukan hanya solusi pwas/Kotlin/Swift/React/Xamarin/other-junkier-hybrid

Dalam pertempuran epik yaitu Flutter vs React Native, code push adalah alat yang sangat berguna (:
Sebagai pengembang RN, saya tidak bisa cukup menekankan pentingnya fitur ini. Banyak yang akan melewati Flutter hanya karena tidak adanya hot push. Setelah Anda terbiasa dengan cepat memperbaiki bug dan mendorong fitur baru, Anda tidak dapat kembali.

kompilasi ke jalur javascript akan mengurangi keuntungan dart kan?
saya menemukan beberapa aplikasi asli yang dulu dapat memuat ulang kode menggunakan Rollout.io tetapi diblokir oleh Apple: https://news.ycombinator.com/item?id=13817557
melihat pola ini, sepertinya flutter tidak akan memiliki fitur push kode yang mulus seperti yang kita lihat di reaksi asli.
ingin mendapatkan lebih banyak wawasan tentang kemungkinan fitur ini dari pengelola inti (:

kompilasi ke jalur javascript akan mengurangi keuntungan dart kan?

Keuntungan apa yang Anda bicarakan?

Codepush sangat dibutuhkan. Senang melihat kemungkinan rilis peningkatan over-the-air di Flutter.

kami baru saja memiliki kasus penggunaan langsung dengan aplikasi produksi di mana kami mendapatkan banyak ulasan buruk untuk fitur yang tampaknya sedikit kasus tepi (terkait dengan penolakan izin lokasi dalam kasus penggunaan yang tidak dimiliki setiap akun pengujian) tetapi sebenarnya tidak' T.

fitur codepush dapat mendorong perbaikan penting bagi pengguna dengan segera daripada menunggu mereka meningkatkan versi; untuk beberapa alasan sepertinya pengguna terkadang lambat untuk memutakhirkan :(

Tidak ada dukungan push kode panas adalah NO GO :-(

Sepertinya JavascriptCore mungkin tidak lagi diperlukan untuk kode yang ditafsirkan: https://www.theregister.co.uk/2017/06/07/apple_relaxes_developer_rules/?page=2

Jika ekosistem iOS menjadi penghalang, mengapa tidak diimplementasikan di Android saja untuk saat ini? Sesuatu yang lebih baik daripada tidak sama sekali dan ini adalah titik awal.

Sangat dihargai bagi tim untuk mengimplementasikan fitur ini secepatnya.

Kami telah membangun beberapa prototipe dasar di sini, tetapi tidak memiliki apa pun untuk dibagikan saat ini. Untuk melakukan ini dengan sangat baik akan memerlukan beberapa pekerjaan di rantai alat kompiler Dart. Saya berharap butuh berbulan-bulan sebelum kami memiliki banyak hal untuk dibagikan di sini. Tim saat ini fokus pada stabilisasi untuk 1.0.

Semua yang dikatakan, kami mendengar Anda. :) Ini jelas merupakan fitur yang dihargai banyak orang dan kami tertarik untuk menyediakan fungsionalitas seperti ini pada akhirnya.

Dukungan "Code Push" untuk Flutter bisa menjadi paku terakhir di peti mati terkait React Native.

Dengan semua kecintaan saya pada RN dan komunitas RN, sebagai pengubah permainan, ini bukan tandingan Flutter.
Flutter hanya memakukannya dalam aspek apa pun (perkakas, kinerja, bahasa ...).

Setelah 1.0 hit dan komunitas tumbuh sedikit lebih banyak + Dukungan Code Push = Tidak ada alasan untuk memulai proyek seluler baru dengan apa pun selain Flutter.

ada kemajuan pada "Code Push" ??

Seberapa layak untuk memiliki .so penuh diganti secara dinamis? Seluruh rantai alat kompiler, pengocokan kode, dll. tidak boleh diarahkan ke kasus tepi yang bisa dibilang menguntungkan orang atau mungkin tidak, mengingat akan selalu ada tiket di bagian atas daftar prioritas.

Saya pikir harus ada ruang untuk "mengalihkan" file .so penuh, sehingga build dari dart ke kode mesin masih bisa persis sama. Sebuah komponen kecil tapi benar-benar independen dapat diberikan "fitur minimum yang layak" berikut: unduh .so dan ganti yang awalnya dikirimkan dengannya, dan mulai ulang aplikasi dengan maksud peluncuran utama.

Tanggung jawab ekstra: mengunduh aset, memverifikasi tanda tangan, dan apa yang tidak. Perbarui mesin flutter/dart/skia dan yang tidak.

Kedengarannya bagi saya itu melanggar pedoman iOS, tetapi saya sebenarnya bukan penggemar apa pun yang ditafsirkan, atau iOS secara umum. Dan saya lebih suka memilikinya di Android daripada tidak memilikinya sama sekali, hanya karena itu keren.

Setidaknya bagian unduhan tampaknya dapat dilakukan sekarang karena kami memiliki beberapa pekerjaan isolasi yang diizinkan di latar belakang, tetapi akan menarik untuk melihat bagaimana menukar .so asli dengan yang diunduh. Mungkin kode .so atau java tambahan dapat melakukan bagian itu, tetapi itu akan berada di folder kode, tidak yakin aplikasi itu sendiri dapat memodifikasinya jadi mungkin perlu beberapa penyesuaian sehingga mesin flutter memuat semua aplikasi .so dari internal data?

Mulai mengubah aplikasi perusahaan saya menggunakan flutter. Namun permintaan utama kami untuk memiliki fitur pembaruan terbaru karena kami masih dalam versi beta dan terus menguji UI dan fitur baru dengan cepat. Akan hidup untuk memiliki fitur ini.

Ada pembaruan?
(Saya berani bertaruh fitur ini sudah selesai dan akan menjadi kejutan ketika 1.0 hits)
😁

suara terbanyak

Hanya ada satu alasan untuk mencegah kami menggunakan Flutter: Kode push

Jika kalian tidak dapat mendukung Code Push, apakah ada cara untuk membuat Parser untuk menghasilkan dari beberapa kamus (seperti json, xml ...) ke Flutter Widget? Apakah ini tidak mungkin atau ide yang bagus?

Ini terdengar agak menjanjikan. Konfigurasi jarak jauh Firebase ke widget jika diperlukan.
Meskipun membuat perusahaan memiliki gagasan tentang apa yang mereka inginkan juga membantu :)

Pada Jum, 12 Okt 2018, 3:45 Hưng Lương Minh [email protected]
menulis:

Jika kalian tidak dapat mendukung Code Push, apakah ada cara untuk membuat Parser?
hasilkan dari beberapa kamus (seperti json, xml...) ke Flutter Widget? Adalah
ini tidak mungkin atau ide yang bagus?

—
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-429251785 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AC4TYe9qDMi4bt2U5qyyAnJisN3ys_Z5ks5ukFavgaJpZM4RxUZi
.

Saya pikir setidaknya UI/Tampilan yang ditulis dalam Dart dapat diunduh melalui jaringan dari server.
Untuk inspirasi, lihat bagaimana kerangka kerja Qt Quick melakukannya.

QtDD12 - Melayani aplikasi QML melalui jaringan - Jeremy Laine:

• Video
• Slide

berharap itu dapat dimasukkan dalam rilis 1.0 yang akan datang!

Banyak pelanggan kami akan menggunakan aplikasi Flutter kami di perangkat kios di belakang firewall ketat yang akan mencegah mekanisme pembaruan aplikasi Google Store. Pelanggan ini tidak akan memasukkan Play Store ke daftar putih. Kami pada akhirnya akan memiliki 100-an perangkat keras dengan aplikasi Flutter, dan memiliki cara untuk mendorong pembaruan ke aplikasi sambil mematuhi batasan firewall pelanggan akan luar biasa!

@eseidelGoogle - sudah lama sejak kalian memberikan beberapa pembaruan di sini.

Apakah kalian masih mengerjakan ini? Bagaimana kabarnya?

Kemajuan berlanjut. Tidak ada pembaruan untuk dibagikan saat ini.

Kami datang dengan tiga istilah yang jelas untuk apa yang orang-orang telah mengelompokkan ke dalam bug ini sebelumnya hari ini:

• "Penambalan dinamis": kemampuan untuk memperbarui kode Dart aplikasi di lapangan dengan mengunduh tambalan (semacam) dan menyediakannya ke Dart VM. Ini akan membutuhkan pemuatan ulang aplikasi agar berlaku.
• "Pemuatan ekstensi dinamis": kemampuan untuk mengunduh beberapa kode Dart yang tidak ditulis saat aplikasi pertama kali diterbitkan, yang menambahkan fitur baru ke aplikasi. Ini bisa dilakukan dengan cepat. Mungkin memerlukan aplikasi inti yang lebih besar karena kami tidak dapat mengetahui sebelumnya apa yang dibutuhkan oleh setiap ekstensi di masa mendatang.
• "Pengiriman aplikasi modular": kemampuan untuk mengemas satu aplikasi menjadi beberapa arsip terpisah saat mengompilasinya, dan mengunduhnya secara independen sesuai kebutuhan.

Kami mungkin harus membagi masalah ini menjadi tiga bug yang dapat kami lacak secara terpisah.

Apakah ini benar-benar layak untuk iOS? Terlepas dari kemungkinan Apple melarang ini seperti yang mereka lakukan dengan rollout.io , javascript harus berjalan tanpa JIT apa pun (tidak ada penulisan ke halaman yang dapat dieksekusi di iOS). Juga karakteristik GC yang berbeda dari inti Javascript sementara Flutter membuat banyak objek berumur pendek mungkin bukan pertanda baik.

Apa yang Apple lakukan/tidak izinkan saat ini (atau di masa depan) sepenuhnya terpisah dari implementasi teknis. Flutter berjalan di banyak tempat selain iOS. Jelas kami ingin selalu merancang teknologi yang dapat bekerja di iOS (seperti yang saya yakini banyak kemungkinan solusi "kode push"), tetapi iOS bukan satu-satunya pertimbangan. Semoga membantu?

Sangat sedih tidak melihat Code Push dirilis di 1.0. Seperti yang lain, ini adalah alasan utama saya tidak dapat menggunakannya pada proyek yang membutuhkan kemampuan untuk menambal tanpa menunggu toko aplikasi.
Saya menghargai bahwa itu adalah tumpangan yang berat untuk sampai ke sana, semoga berhasil.

Hanya ada satu alasan untuk mencegah kami menggunakan Flutter: Kode push

Ingin meninggalkan umpan balik saya hanya untuk menunjukkan minat saya pada topik ini.
Perusahaan saya mengembangkan aplikasi multipelanggan khusus android untuk mengelola tim pemeliharaan. Pada tahun 2018 kami merilis sekitar 100 pembaruan, tidak ada yang meminta versi baru melalui Google Play karena kebanyakan dari mereka adalah sedikit penyesuaian dan penyesuaian yang dibutuhkan setiap pelanggan, yang tidak dapat diprediksi sebelumnya.
Menulis ulang aplikasi ini di Flutter akan menjadi mimpi, tetapi selain biaya penulisan ulang, membuang-buang uang untuk menunggu perbaikan atau penyesuaian yang akan diterbitkan melalui GPlay akan menjadi mimpi buruk.

Semoga tercapai secepatnya

Poin lain: Jika tim Flutter menyediakan solusi hot-fix secara resmi, saya pikir Apple dapat menolak semua Aplikasi yang dibuat oleh Flutter pada suatu waktu, karena hot-fix jelas melanggar Pedoman Peninjauan AppStore, pengembang dapat melewati tinjauan AppStore dan memodifikasi mereka aplikasi, itu tidak aman bagi pengguna.

Saat ini Apple menolak semua Aplikasi dengan JsPatch, yang merupakan solusi hot-fix paling populer di China. JsPatch dibangun di atas runtime JsCore dan OC.

Saya ingin membuat Aplikasi Flutter tanpa fungsi hot-fix, daripada Aplikasi yang mungkin ditolak oleh Apple di masa mendatang.

@MaxZeng Senang mengetahui tentang JsPatch. Tapi untuk saat ini, sepertinya hot patching diperbolehkan. Ada banyak aplikasi React Native di toko Apple dan semuanya menggunakan hot patching melalui CodePush.

Kalau saja iOS/android support seperti contoh ini:
MyFlutterApplication meminta izin/ingin memperbarui aplikasi Anda
Changelogs: tambahkan kucing dan anjing (v1.0)
Izinkan | Jangan izinkan

setelah meninjau pedoman untuk kedua belah pihak.

@MaxZeng Senang mengetahui tentang JsPatch. Tapi untuk saat ini, sepertinya hot patching diperbolehkan. Ada banyak aplikasi React Native di toko Apple dan semuanya menggunakan hot patching melalui CodePush.

Ya, ReactNative adalah pengecualian dari kode push untuk saat ini, tetapi itu tidak berarti bahwa Apple mendukungnya secara resmi. Aplikasi perusahaan kami ditolak oleh AppStore lebih dari 3 kali baru-baru ini karena kerangka kerja seperti RN, dan kami harus menulis ulang fungsi-fungsi ini oleh OC/H5, ini adalah mimpi buruk bagi pengembang.

React Native masih merupakan framework AMAN untuk Apple, karena akhirnya dirender di atas UIKit, tetapi Flutter benar-benar berbeda:
1、Pertama, Ini merusak ekosistem pengembang Apple, Ini melewati kerangka kerja UIKit, dan itu KELUAR dari kendali Apple, misalnya akan ada lebih banyak dan lebih banyak Aplikasi gaya MD di AppStore, dan ini mungkin bertentangan dengan Pedoman Antarmuka Manusia Apple. Apple adalah perusahaan terkenal karena desainnya yang hebat.
2、Kedua, jika hot-reload didukung oleh Flutter secara resmi, Apple dapat menggunakan alasan ini untuk menolak Aplikasi Flutter secara langsung.

Dari sudut pandang saya, Flutter harus mengikuti Pedoman Tinjauan AppStore daripada melanggarnya, ini penting untuk kerangka kerja seluler lintas platform, Anda tidak boleh merusak ekosistem Apple karena kami dapat melakukannya. Jika Apple menolak Flutter, keuntungan utama Flutter akan hilang.

CodePush bukanlah teknik yang sulit atau misterius, Apple dapat menerapkannya dengan mudah (terutama berdasarkan OC), satu-satunya alasan Apple melarangnya adalah karena tidak aman bagi pengguna akhir, dan ini merusak AppStore/Google Play sepenuhnya. Ini adalah bencana jika banyak aplikasi dapat mengubah fungsinya kapan saja dan di mana saja, dan sulit untuk melacak dan membatasi tindakan berbahaya ini setelah Aplikasi diizinkan untuk dipublikasikan.

CodePush bukan hanya sebuah teknik, ini adalah bagian penting dari ekosistem seluler. Saya pikir tim Flutter seharusnya tidak memberikan teknik seperti itu secara resmi, meskipun mungkin diterapkan oleh beberapa pengembang secara pribadi, ini tidak masalah karena tidak akan digunakan secara liar.

@MaxZeng Senang mengetahui tentang JsPatch. Tapi untuk saat ini, sepertinya hot patching diperbolehkan. Ada banyak aplikasi React Native di toko Apple dan semuanya menggunakan hot patching melalui CodePush.

Ya, ReactNative adalah pengecualian dari kode push untuk saat ini, tetapi itu tidak berarti bahwa Apple mendukungnya secara resmi. Aplikasi perusahaan kami ditolak oleh AppStore lebih dari 3 kali baru-baru ini karena kerangka kerja seperti RN, dan kami harus menulis ulang fungsi-fungsi ini oleh OC/H5, ini adalah mimpi buruk bagi pengembang.

React Native masih merupakan kerangka kerja _SAFE_ untuk Apple, karena akhirnya dirender di atas UIKit, tetapi Flutter benar-benar berbeda:
1、Pertama, Ini merusak ekosistem pengembang Apple, Ini melewati kerangka kerja UIKit, dan itu KELUAR dari kendali Apple, misalnya akan ada lebih banyak dan lebih banyak Aplikasi gaya MD di AppStore, dan ini mungkin bertentangan dengan Pedoman Antarmuka Manusia Apple. Apple adalah perusahaan terkenal karena desainnya yang hebat.
2、Kedua, jika hot-reload didukung oleh Flutter secara resmi, Apple dapat menggunakan alasan ini untuk menolak Aplikasi Flutter secara langsung.

Dari sudut pandang saya, Flutter harus mengikuti Pedoman Tinjauan AppStore daripada melanggarnya, ini penting untuk kerangka kerja seluler lintas platform, Anda tidak boleh merusak ekosistem Apple karena kami dapat melakukannya. Jika Apple menolak Flutter, keuntungan utama Flutter akan hilang.

CodePush bukanlah teknik yang sulit atau misterius, Apple dapat menerapkannya dengan mudah (terutama berdasarkan OC), satu-satunya alasan Apple melarangnya adalah karena tidak aman bagi pengguna akhir, dan ini merusak AppStore/Google Play sepenuhnya. Ini adalah bencana jika banyak aplikasi dapat mengubah fungsinya kapan saja dan di mana saja, dan sulit untuk melacak dan membatasi tindakan berbahaya ini setelah Aplikasi diizinkan untuk dipublikasikan.

CodePush bukan hanya sebuah teknik, ini adalah bagian penting dari ekosistem seluler. Saya pikir tim Flutter seharusnya tidak memberikan teknik seperti itu secara resmi, meskipun mungkin diterapkan oleh beberapa pengembang secara pribadi, ini tidak masalah karena tidak akan digunakan secara liar.

Poin yang sangat menarik dan terdengar masuk akal dalam beberapa hal, tetapi juga memiliki beberapa kesalahan.

1. Flutter juga mendukung Apple's Cupertino , MD bukan satu-satunya yang dipilih.
2. Anda mungkin tahu Unity di area Gaming, sistem render Flutter bekerja serupa dalam beberapa hal.
3. Faktanya dan untuk saat ini, menggunakan web(JS) dapat mengimplementasikan CodePush dan melewati ulasan AppStore untuk memodifikasi aplikasi mereka. Jadi mengapa menolak Flutter(dart) dan melepaskan JS.

Jadi mengapa menolak Flutter(dart) dan melepaskan JS.

JS berjalan di kotak pasir dan karenanya aman. (seperti setiap halaman web yang dimuat di Safari)

Dart mengkompilasi ke kode biner dan tidak dibatasi oleh kotak pasir seperti itu.

Saya seorang pengembang android selama bertahun-tahun. Saya pikir Code push tidak begitu penting.
Jika tanpa Code Push, Anda tidak dapat mengembangkan? Jika demikian, itu terlalu bodoh.
Flutter adalah kerangka kerja untuk seluler, jadi pertama-tama Anda harus belajar lebih banyak untuk mengembangkan pengetahuan seluler.
Tanpa kode push, Anda dapat menggunakan Pembaruan penuh.
Seperti yang dikatakan iklan: seberangi jembatan ketika seseorang datang ke sana.
Sebagai pengembang, saya pikir lebih penting menggunakan cara berbeda untuk menyelesaikan masalah yang sama.

Flutter bukan React Native, Anda tidak dapat menggunakan pengalaman untuk React Native (atau framework lain) untuk melihat Flutter. Mereka adalah hal yang berbeda.

@MaxZeng Mungkin flutter dapat mengaktifkan pembaruan panas secara eksklusif untuk Android.

Tanpa hot update seperti RN, kami tidak akan pindah ke Flutter! Kerangka kerja harus membuat hidup pengembang lebih mudah!!

Bunga-bunga yang saya tunggu semuanya hilang.

@MaxZeng Mungkin flutter dapat mengaktifkan pembaruan panas secara eksklusif untuk Android.

1、Sebenarnya itu akan merusak ekosistem Google Play Store juga, itu akan membuat tim Android sulit untuk mengontrol perilaku Aplikasi.
2、CodePush tidak diperlukan untuk sebagian besar Aplikasi，teknologi ini akan digunakan secara jahat oleh beberapa pengembang.
3、Ini dapat menyebabkan “Man In The Middle Attack” besar jika pengembang tidak mengenkripsi patch dengan benar，peretas ganas dapat memodifikasi kode yang didorong untuk membajak Aplikasi Flutter.

Saya hanya ingin mengatakan hotfix adalah fitur impor untuk sebagian besar perusahaan Cina. lebih dari 70% Perangkat Android Cina tidak mendukung Google Play

@act64 periksa https://github.com/flutter/flutter/wiki/Roadmap

@act64 periksa https://github.com/flutter/flutter/wiki/Roadmap

Peta jalan mengatakan perbaikan terbaru di Android. Semoga iOS akan segera didukung.

@taibaiyinxing Flutter tidak dapat menyediakan fitur yang tidak diizinkan oleh Apples App-store.

@taibaiyinxing Flutter tidak dapat menyediakan fitur yang tidak diizinkan oleh Apples App-store.

@zoechi Kami menggunakan aplikasi perusahaan dan kami tidak perlu mengunggah ke app-store.

Patching dinamis di Android, memungkinkan pembaruan kode di-deploy ke aplikasi Flutter yang berjalan di Android langsung dari server.
🎉

https://github.com/flutter/flutter/wiki/Roadmap

Tampaknya tidak ada rencana untuk mendukung CODE PUSH di iOS pada tahun ini.

https://github.com/flutter/flutter/wiki/Roadmap

"Daftar di sini tidak boleh dianggap lengkap, atau janji bahwa kami akan menyelesaikan semua pekerjaan ini." :)

Pekerjaan code-push masih dalam tahap pengujian yang relatif awal. Platform apa yang akan/tidak akan kami gunakan untuk pekerjaan itu pada tahun 2019 belum ditentukan. Lagipula ini baru Februari. 10 bulan adalah waktu yang lama!

Saat ini para insinyur berfokus untuk membangun teknologi inti untuk mendukung 3 kasus penggunaan @Hixie yang diuraikan dalam: https://github.com/flutter/flutter/issues/14330#issuecomment -442274897
Saya berharap kami akan mulai melakukan beberapa pengujian terbatas setidaknya satu dari kasus penggunaan tersebut dalam beberapa bulan mendatang.

Karena teknologi pengembangan flutter kami tidak terlalu matang, APP sering diperbarui, dan banyak yang merupakan pembaruan mendesak. Dan aplikasi kami tidak berencana untuk mengunggah toko aplikasi. Jadi fitur ini sangat penting. Ini dapat meningkatkan kecepatan iterasi APP. Jika tidak, fragmentasi APP menyebabkan api kita tertunda.

Seperti yang saya pikir kita semua bisa setuju, penyebab masalah ini adalah bahwa mengirimkan aplikasi seluler apa pun ke pengguna akhir melalui taman bertembok yang dikelola oleh Google dan Apple (toko), merupakan ketidaknyamanan besar bagi pengembang aplikasi (belum lagi layanan yang buruk kepada pengguna akhir aplikasi yang bagus/inovatif), Apple menjadi yang paling merepotkan (hari untuk Apple dibandingkan dengan jam untuk Google).

Sebagai poin tambahan, solusi yang mungkin adalah jika toko menyediakan jalur untuk pembaruan instan bagi pengembang 'tepercaya' (seperti layanan jalur cepat). Google dan Apple kemudian dapat melakukan audit realtime (otomatis,... seperti AI??... dengan auto-rollback post-facto seperlunya) dari aplikasi. Tetapi ini tampaknya tidak mungkin karena banyak alasan teknis dan lainnya. Kedua toko tentu saja memiliki jalur cepat ke penguji beta.

Jadi... sambil menunggu fitur dalam masalah ini, salah satu cara untuk mengurangi ketidaknyamanan yang terkait dengan pengiriman aplikasi seluler apa pun ke pengguna akhir adalah dengan mengotomatiskan langkah-langkahnya.

Untuk contoh alat yang melakukan otomatisasi semacam ini untuk Flutter, lihat:
https://github.com/mmcc007/fledge
Sebagai catatan, ini mencakup dokumentasi untuk banyak langkah penyiapan satu kali yang terlibat yang tidak dapat dengan mudah diotomatisasi:
https://mmcc007.github.io/fledge/

@charliezzo Menggunakan alat ini, atau alat seperti itu, aplikasi Flutter (dan pembaruan, dll.) dapat dikirimkan ke penguji beta android dan ios dalam beberapa menit.

Ini juga memiliki alur kerja untuk mengotomatiskan pengiriman ke pengguna akhir melalui toko (jam+ untuk Google, hari+ untuk Apple 😂👍).

@mmcc007
Oh terima kasih. tetapi saya katakan saya tidak ingin mendorong aplikasi saya ke google play dan app store.
saya perlu menjual aplikasi saya dengan cara lain.
dan saya tidak perlu google play dan app store untuk memperbarui aplikasi saya.
saya hanya ingin memperbarui aplikasi saya sendiri ketika pengguna menginstalnya dan memulainya.
dan, flutter adalah 60FPS atau kerangka kerja yang lebih tinggi, itu dapat membuat game online, kami tidak ingin memiliki sedikit tambalan oleh google play dan app store.
Anda tahu setiap tambalan dalam waktu singkat oleh google play dan app store lambat dan keras.
sebenarnya Anda tahu kami tidak bisa menggunakan google play di cina. dan toko aplikasi sangat lambat.
ada banyak toko aplikasi seperti google play di cina. kami tidak punya waktu untuk mendorong pembaruan ke setiap toko aplikasi.

Code Push harus menjadi fitur utama di Flutter. Letakkan di atas.

Kita bisa membuatnya dengan mengganti semua file di app_flutters di Android

hai dapatkah Anda memberi saya email Anda untuk diskusi lebih lanjut，tim kami juga menemukan solusi ini， tetapi itu hanya dapat berfungsi ketika aplikasi harus dimatikan dan memulai ulang aplikasi。tks @LNeway

hai dapatkah Anda memberi saya email Anda untuk diskusi lebih lanjut, tim kami juga menemukan solusi ini, tetapi hanya dapat berfungsi ketika aplikasi harus dimatikan dan memulai ulang aplikasi. tks @LNeway
@KinsomyJS
Saya juga menjalankan demo untuk memverifikasi kelayakannya. Hahaha~

Silakan berbagi dengan cuplikan singkat atau posting blog atau komentar di sini atau cc [email protected] di email...

@LNeway @KinsomyJS Bisakah salah satu dari Anda memberikan detail lebih lanjut?
Terima kasih

@taibaiyinxing Flutter tidak dapat menyediakan fitur yang tidak diizinkan oleh Apples App-store.

@zoechi Apakah Anda mengatakan Anda dan/atau tim Flutter memiliki analisis yang menyimpulkan bahwa teknik codepush yang dapat dilakukan oleh Flutter pada dasarnya berbeda dari yang dilakukan oleh React-native dan dilarang - dan oleh karena itu, karena Apple, mungkin tidak akan pernah datang ke iPhone?

Jika fitur ini ditambahkan, apakah akan mendukung beta 1.0.0?

@dahabdev

Untuk apa nilainya, dari pengalaman saya dengan Ionic, saya percaya "code push" terlalu berlebihan, dan saya berharap tim Flutter tidak menghabiskan terlalu banyak waktu untuk mengerjakannya sementara masih ada begitu banyak fitur dasar dan penting lainnya yang hilang.

Kembali ketika saya mengembangkan UAVForecast, saya menggunakan Ionic, tertarik dengan fitur "ionic deploy" yang menawarkan untuk memperbarui seluruh konten aplikasi dari jarak jauh. Saat itu (ini tahun 2014), waktu peninjauan App Store Apple berada di urutan 2 minggu. Saya ingin mengulang dengan cepat, bergerak cepat, dan memecahkan banyak hal, seperti yang mereka katakan.

Pada awalnya "penyebaran ionik" sangat bagus, tetapi segera, saya melihat beberapa masalah besar. Ini menyebabkan kebingungan bagi pengguna saya ("aplikasi mengatakan telah memperbarui dirinya sendiri, jadi mengapa ada pembaruan lain yang tertunda di Play Store / App Store?"); kadang-kadang merusak aplikasi, misalnya ketika metadata aplikasi (misalnya izin) diam-diam diubah oleh plugin Cordova tetapi tidak diperbarui oleh hot code push; melacak nomor versi itu rumit dan mereka akan tidak sinkron dengan apa yang saya dorong ke toko; itu membuat saya malas untuk menguji, karena saya selalu bisa "menyebarkan ion" sendiri dari bug; dan terkadang saya akhirnya mendorong bug yang lebih buruk, yang mungkin telah ditangkap oleh tim peninjau aplikasi jika saya memberi mereka kesempatan untuk melihatnya.

Sekitar setahun setelah saya merilis versi pertama, waktu peninjauan App Store telah meningkat secara signifikan. Hari ini, hanya beberapa hari, dan tentu saja di Google Play Store hanya beberapa jam. Mengingat semua masalah yang saya alami, saya memutuskan untuk menghapus fungsionalitas "penyebaran ionik" dari aplikasi saya, dan dengan beberapa juta unduhan sekarang di belakang saya, saya belum melihat ke belakang.

Meskipun saya menyukai Ionic dan sangat menghargai semua yang telah dilakukan oleh pengembangnya, Drifty (terima kasih!), saya berpendapat Drifty membuat kesalahan dengan menginvestasikan terlalu banyak waktu ke dalam fitur-fitur mengkilap seperti dorongan kode yang menarik pengguna, dan tidak cukup waktu untuk mendapatkan mur dan baut rangka tepat untuk menghindari masalah yang pada akhirnya membuat mereka menjauh. Sekarang dalam versi keempatnya, Ionic telah ditulis ulang berkali-kali dengan cara yang tidak kompatibel sehingga saya berhenti mencoba untuk mengikutinya - versi terbaru masih memiliki beberapa masalah serius yang menghalangi saya untuk meningkatkan, dan sekarang saya menulis ulang seluruh aplikasi saya di Berdebar.

Pengalaman sejauh ini luar biasa, dan saya sangat bersenang-senang, tetapi masih ada beberapa celah dan kelalaian besar di Flutter, terutama di plugin. Misalnya: tidak ada integrasi bidang teks dengan pengisian otomatis kata sandi, plugin Google Maps adalah barebone (dan ada bug rendering kerangka kerja terkait), WebView asli tidak mendukung file:// URL untuk memuat aset, bilah tab tidak mendukung transparansi atau latar belakang gradien, sel tabel tidak mendukung colspan, ThemeData tidak dapat diperluas dengan warna khusus aplikasi untuk digunakan dengan animasi, satu-satunya perpustakaan DateTime yang sepenuhnya menyadari zona waktu tidak memiliki banyak fitur penting dari momen dan zona waktu, ada begitu banyak pendekatan untuk manajemen negara sehingga membingungkan bagi pendatang baru, Anda harus sering "bersemangat bersih" untuk menghindari pengecualian yang aneh, hot-swap sering tidak berfungsi sebagaimana mestinya, dan saya bisa melanjutkan ...

Saya akan memberi peringkat _semua_ ini sebagai lebih penting daripada "push kode", terutama jika itu berisiko Apple menolak aplikasi Flutter, jika memerlukan perubahan besar pada kerangka kompiler yang pada akhirnya dapat membuat pengoptimalan yang meningkatkan kinerja aplikasi menjadi lebih sulit (saya akan mengambil Peningkatan kinerja 5% dari "dorongan kode" setiap hari), atau membutuhkan waktu lama untuk menyelesaikan fitur kerangka kerja.

Di sisi lain, saya dapat melihat bahwa beberapa pengembang mungkin benar-benar membutuhkannya dalam beberapa situasi, terutama jika mereka beroperasi di luar toko, jadi saya dapat memahami antusiasme di sini.

@matthewlloyd banyak poin bagus!

Jika kalian tidak dapat mendukung Code Push, apakah ada cara untuk membuat Parser untuk menghasilkan dari beberapa kamus (seperti json, xml ...) ke Flutter Widget? Apakah ini tidak mungkin atau ide yang bagus?

--Apakah ada yang punya pendapat tentang yang satu ini?
https://pub.dartlang.org/packages/dynamic_widget
tampaknya menjanjikan, meskipun tidak mengatasi ketakutan 'bug kritis'.

Itu bagian yang gila adalah bahwa dorongan kode adalah gajah di dalam ruangan, yang merupakan masalah bisnis/proses dan teknis, dan satu sisi cenderung mengabaikan yang lain ...

tidak ada integrasi bidang teks dengan isi otomatis kata sandi, plugin Google Maps adalah barebone (dan ada bug rendering kerangka kerja terkait), WebView asli tidak mendukung file:// URL untuk memuat aset, bilah tab tidak mendukung transparansi atau latar belakang gradien, sel tabel tidak mendukung colspan, ThemeData tidak dapat diperluas dengan warna khusus aplikasi untuk digunakan dengan animasi, satu-satunya perpustakaan DateTime yang sepenuhnya menyadari zona waktu tidak memiliki banyak fitur penting dari momen dan zona waktu momen, ada begitu banyak pendekatan untuk manajemen negara itu membingungkan bagi pendatang baru, Anda harus sering "berkibar bersih" untuk menghindari pengecualian aneh, hot-swap sering tidak berfungsi sebagaimana mestinya, dan saya bisa melanjutkan ...

Semoga semua ini sudah memiliki masalah Github :D

Ini sebelumnya ada di peta jalan kami untuk tahun 2019. Setelah menyelidiki ini secara lebih rinci, kami telah memutuskan untuk tidak melanjutkan pekerjaan ini untuk saat ini.

Ada beberapa faktor yang membuat kami mengambil keputusan ini:

• Untuk mematuhi pemahaman kami tentang kebijakan toko di Android dan iOS, solusi apa pun akan dibatasi pada kode JIT di Android dan kode yang ditafsirkan di iOS. Kami tidak yakin bahwa karakteristik kinerja dari solusi semacam itu di iOS akan mencapai kualitas yang kami minta dari produk kami. (Dengan kata lain, "itu akan terlalu lambat".)

• Ada beberapa masalah keamanan yang serius. Karena patch ini pada dasarnya akan memungkinkan eksekusi kode arbitrer, mereka akan menjadi vektor malware yang sangat menarik. Kami dapat menguranginya dengan mengharuskan patch ditandatangani menggunakan kunci yang sama dengan paket aslinya, tetapi ini rawan kesalahan dan kesalahan apa pun akan memiliki konsekuensi serius. Ini, pada dasarnya, adalah masalah yang sama yang menjangkiti platform yang memungkinkan eksekusi kode dari sumber pihak ketiga. Masalah ini dapat dikurangi dengan mengintegrasikan dengan mekanisme pembaruan platform, tetapi ini mengalahkan tujuan mekanisme penambalan out-of-band.

• Saat ini tidak ada solusi hosting open source out-of-the-box untuk menambal aplikasi, jadi kami harus bergantung pada orang yang mengonfigurasi server Web mereka sesuai, atau kami harus membuat integrasi untuk layanan pihak ketiga berpemilik, atau kami harus membuat solusi pesanan kami sendiri. Tambalan hosting adalah ruang yang tidak ingin kami masuki. Memiliki orang-orang yang mengonfigurasi server mereka sendiri membuat mereka terbuka untuk membuat kesalahan dengan implikasi yang berpotensi serius seperti yang dijelaskan pada poin sebelumnya tentang keamanan. Bergantung pada layanan pihak ketiga menempatkan Flutter dalam posisi canggung karena harus memilih pemenang dan menghadapkan kita pada risiko proyek itu sendiri membuat perubahan kebijakan yang akan memengaruhi fitur ini.

Kami lebih suka menghabiskan upaya rekayasa kami pada masalah lain untuk saat ini. Kami berharap untuk terus bereksperimen di bidang ini dan mungkin akan menjadi serius lagi di masa mendatang (misalnya, kami mungkin memerlukan solusi pembaruan untuk aplikasi desktop), tetapi mungkin tidak tahun ini.

Meskipun saya memahami alasan di balik penghentian fitur ini, itu masih mengecewakan. Play Store dan App Store adalah pertimbangan penting tetapi tidak semua aplikasi didistribusikan dengan cara ini. Untuk kasus penggunaan kami, kami menyediakan perangkat dan aplikasi yang sudah diinstal kepada pelanggan. Memiliki mekanisme untuk mendorong pembaruan secara dinamis kepada pengguna adalah fitur yang sangat penting karena kami tidak ingin melalui toko. Fitur ini akan sangat berharga. Saya berharap ini ditinjau kembali di masa depan seperti yang Anda sebutkan.

Terima kasih telah mengkomunikasikan rasional tim secara transparan.

@eseidelGoogle Apakah kode JavaScript yang dikompilasi dari Dart dapat menggunakan Skia untuk merender halaman?

Ini cukup mengecewakan.

Mengenai semua masalah kepatuhan keamanan dan toko yang Anda sebutkan, itu mungkin valid dan sah, tetapi pada akhirnya ada contoh teknologi "pembaruan panas" yang sudah berfungsi: kode push.

React Native + layanan kode push berfungsi dan membuktikan dirinya di dunia nyata. Ini pertempuran diuji. Tampaknya tidak ada masalah dengan toko aplikasi terkait pembaruan tidak langsung. Sepertinya semua orang "baik-baik saja" dengannya. Jadi saya pikir solusi Flutter juga bisa diizinkan.

Mengenai masalah kinerja, mungkin ide yang baik untuk membiarkan pengembang memilih untuk bekerja dalam mode "kinerja rendah" tetapi mengaktifkan pembaruan langsung.

Langkah yang bagus! Saya lebih suka upaya rekayasa dihabiskan untuk mengoptimalkan Flutter daripada menambahkan fitur kode-push yang dapat memperumit dan merusak ekosistem

Saat ini saya memiliki aplikasi pertama saya, yang dikembangkan di Flutter, dalam pengujian beta terbuka dan saya telah mendorong sekitar 10 bundel aplikasi dengan perbaikan. Tetapi seharusnya sebagian besar bebas kesalahan ketika saya merilisnya ke produksi.

Jadi saya tidak tahu apakah saya akan membutuhkan fitur ini, tetapi saya menemukan Pembaruan OTA paket pub ini yang tampaknya berjalan baik dengan skor 89, yang hanya diturunkan oleh popularitasnya. Apakah paket itu aman? Tampaknya mengunduh APK dari URL dan membongkarnya secara asli dan memicu maksud pemasangan APK di Android.

Mereka yang benar-benar membutuhkan fitur ini dapat mencoba paket tersebut.

Tapi saya bisa melihat mengapa tim Flutter tidak terlalu bersemangat tentang ini, karena, mari kita ambil paket di atas untuk berjaga-jaga. Tampaknya mengunduh dari URL. Dan situs web selalu lebih ramah peretas daripada aplikasi asli. Ada terlalu banyak masalah keamanan seperti yang sekarang. Itu hanya membuat aplikasi Flutter rentan seperti situs web yang sangat dilarang.

Saya memiliki mesin RAM 2 GB ketika saya memulai, mencoba mengembangkan Aplikasi Android seperti yang selalu saya inginkan, tetapi mesin saya tidak dapat melakukan tugas itu. Saya mencoba PhoneGap, Cordova, beberapa kerangka kerja Intel, React-Native, dan tidak satupun dari mereka yang mulai berjalan. Flutter adalah satu-satunya yang benar-benar saya mulai dan dengan UI dan alat pengembangan yang indah, Flutter jauh lebih maju dari rekan sezamannya bahkan tanpa fitur ini.

Perubahan apapun?

Alur kerja rilis aplikasi tidak akan pernah sama setelah cara asli-reaksi memanjakan kami dengan Code Push. Sayang sekali bahwa Flutter tidak akan mendukungnya. Flutter berkembang dengan baik dan bisa menjadi pesaing React Native jika mereka memilih untuk mendukung fitur ini. Sayang...

@Hixie OK, jadi perubahan teknik/teknik mendasar memiliki terlalu banyak kerugian untuk saat ini - itu masuk akal bagi saya.

Namun - bagaimana perasaan Anda tentang membantu pengembang berdebar yang menjadi perhatian bisnis dalam jangka pendek dan menengah dengan beberapa pendekatan alternatif yang mendapatkan beberapa dokumentasi/diskusi - bahkan mungkin video, sementara mungkin bukan solusi 'didukung' atau resmi, tetapi beberapa perhatian.

misalnya

• Konfigurasi real-time Firebase
• Server berbasis json->widget (mis. https://github.com/dengyin2000/dynamic_widget/blob/master/WIDGETS.md atau simlar, saya belum mendukung plugin yang tepat tetapi idenya)
• atau mungkin sesuatu yang lain, mungkin fungsi cloud untuk pengguna tingkat lanjut...
• jelas saya tidak menyarankan Anda melakukan banyak upaya rekayasa untuk kasus penggunaan 'besar', tetapi semacam alternatif-halo-kode-push-alternatif yang menangani sebagian besar kebutuhan tanpa 'mari perbaiki/ubah setiap hal ' tipe arsitektur.

premis saya adalah bahwa "kita" dapat memenuhi 70-90% perhatian untuk codepush tanpa perubahan arsitektur mendasar untuk flutter; apa yang orang pikirkan tentang ini?

Pendekatan code-as-ui Flutter bahkan mungkin membuat ini lebih mudah daripada untuk pengembang Android....

Saya telah melihat secara pribadi setidaknya dua perusahaan yang memilih orang lain daripada berdebar hanya karena alasan ini, dan banyak perusahaan lain telah berbicara dengan cara yang sama.

Mungkin percakapannya bisa berlanjut
"Pengguna: Apakah Anda melewatkan dukungan codepush"
"Tim Flutter: Ya-untuk saat ini, untuk alasan ini, (seperti yang Anda lakukan) tetapi selain itu, Anda dapat mencoba A atau B untuk beberapa kasus penggunaan"

Maaf panjang komen

@neiljaywarner Mungkin LUA layak untuk Anda lihat - Saya melakukan bukti konsep tahun lalu di mana skrip LUA dapat digunakan untuk membuat/menyesuaikan fungsionalitas aplikasi Flutter.

@neiljaywarner Saya semua mendukung pendekatan semacam itu, tapi itu masalah ortogonal daripada apa yang

Meskipun saya memahami alasan di balik penghentian fitur ini, itu masih mengecewakan. Play Store dan App Store adalah pertimbangan penting, tetapi tidak semua aplikasi didistribusikan dengan cara ini. Untuk kasus penggunaan kami, kami menyediakan perangkat dan aplikasi pra-instal kepada pelanggan. Memiliki mekanisme untuk mendorong pembaruan secara dinamis kepada pengguna adalah fitur yang sangat penting karena kami tidak ingin melalui toko. Fitur ini sangat berharga. Saya berharap untuk memeriksanya kembali seperti yang Anda sebutkan di masa depan.

Terima kasih telah mengomunikasikan rasionalitas tim secara transparan.

saya setuju

fungsionalitas kode-push berarti lebih banyak aplikasi, lebih banyak klien, lebih banyak pengembang, lebih banyak tes, lebih banyak perbaikan bug, lebih sedikit masalah

Untuk MVP startup atau aplikasi yang sedang berkembang, pembaruan atau perbaikan bug sangat penting, sementara kinerja seringkali kurang diperhatikan. Hal ini akan menimbulkan pro dan kontra terhadap ekosistem Flutter. Penurunan adopsi, startup, dan pengembang pribadi penting untuk pertumbuhan komunitas tahap awal. Keuntungannya mungkin aplikasi dan tim berkualitas yang akan beralih ke Flutter yang bertujuan untuk kinerja yang lebih tinggi?

@maplerichie , Setuju, alasan mengapa saya suka flutter adalah Pengalaman Pengembang, kinerja, dan lintas platform untuk semua perangkat. Saya tidak keberatan jika kode-push tidak akan diterapkan (mungkin), itu demi reputasi dan popularitas ekosistem. Sekarang saya tahu mengapa code-push tampak terlalu lambat saat menggunakan aplikasi windows. (startup lambat, keterlambatan input dan animasi lamban) di sini

kami sangat membutuhkan fungsi ini
Butuh pembaruan panas

Seperti yang disebutkan sebelumnya, perusahaan besar dan tim pengembang besar mungkin tidak memerlukan pembaruan terkini. Tapi pikirkan startup kecil, beberapa pengembang yang mengerjakan aplikasi seluler, menghadirkan fitur ke produksi dengan siklus rilis cepat. Tidak ada waktu untuk pengujian dan siklus QA. Buat fitur baru, lihat apakah itu berfungsi dan pengguna menyukainya, ganti atau perbaiki. Kami tidak dapat mencapai tempat kami sekarang tanpa pembaruan terkini. Ini adalah pengubah permainan nyata untuk pengembangan seluler.

@yaronlevi Saya adalah "startup kecil", bahkan kurang dari beberapa pengembang yang mengerjakan aplikasi seluler, hanya saya, dan saya mengirim ke produksi dengan siklus rilis cepat. Dengan Google Play Store yang menawarkan pembaruan yang hanya memakan waktu beberapa jam, dan Apple App Store meninjau pembaruan hampir selalu kurang dari 24 jam dalam pengalaman saya hari ini, saya pasti tidak memerlukan kode push. Jika Flutter memiliki kode push, saya akan secara aktif mengambil langkah-langkah untuk memastikan itu dinonaktifkan di aplikasi saya.

Saat ini saya satu-satunya pengembang aplikasi seluler (dan back-end yang cocok) untuk sebuah perusahaan kecil. Saya sangat menyukai Flutter, tetapi saya harus terus-menerus menjelaskan kepada klien yang tidak memahami perlunya pengujian unit atau pengujian otomatisasi mengapa perlu waktu lama untuk mengimplementasikan fungsionalitas yang dapat dijelaskan dalam 10 kata. Saya sedikit khawatir harus merilis sesuatu yang setengah matang dan tidak dapat mendorong perbaikan bug kritis dengan cepat. Saya akan melakukannya tanpa untuk saat ini, tetapi kode push pasti akan menyenangkan untuk dimiliki. Namun, saya memahami tantangan teknis dan masalah keamanan dan pada akhirnya saya mendukung pendekatan yang hati-hati.

baik, terima kasih.
Saya kira kita perlu mencari tahu sendiri.

sungguh mengecewakan :)

Flutter untuk SDK web akan segera digabungkan dengan SDK seluler. Solusinya adalah menggunakan WebView seluler untuk memuat kode flutter. 😁

@matthewlloyd hai man itu perlu untuk mendukung pembaruan panas, intinya bukan waktu untuk meninjau. Pengguna harus menautkan ke AppStore dan mengunduh aplikasi lagi.

Mungkin membantu
https://github.com/dengyin2000/dynamic_widget
https://github.com/neohelden/Flutter-AdaptiveCards

Saya tidak benar-benar melihat banyak masalah mendesak dengan tidak memiliki kode Push. Hampir semua pengguna memiliki pembaruan otomatis di toko aplikasi mereka. Memberikan solusi alternatif untuk mendistribusikan pembaruan tanpa App Store akan menyenangkan.

MXFlutter menggunakan JavaScript untuk mengimplementasikan kemampuan rendering Flutter, mendukung sintaks Flutter, dan mendukung code push dan hot update.
https://github.com/TGIF-iMatrix/MXFlutter

@TGIF-iMatrix apakah Anda tahu apakah solusi ini sesuai dengan kebijakan distribusi Store?

@truongsinh
Ini aman karena ini adalah pendekatan distribusi js-> parser asli-> buat widget.

kami akan mempertimbangkan untuk menggunakan flutter jika mendukung kode push

@TGIF-iMatrix Kemungkinan besar ini tidak akan disetujui oleh Apple, karena pengecualian untuk pembaruan Javascript Core telah dihapus dari Perjanjian App Store, dan banyak pengguna CodePush telah diperingatkan/ditolak karena fitur itu.

Mungkin kita harus mengulangi pertanyaannya, "rendering yang ditentukan-putuskan" vs "dorongan kode". "sever-dictated-rendering" hanya tentang UI/tata letak/tema yang berbeda, sementara kode-push juga menyiratkan perubahan dalam logika, izin, plugin, dll.

Mungkin, namun pada saat itu Anda hanya dapat menggunakan plug-in untuk melakukan itu, jadi ini agak mengalahkan tujuan dari masalah ini.

Apakah ada yang mencoba bermain-main-lib dengan flutter yang berasal dari repo github tencent dan sukses dengan itu jika ada yang tertarik saya dapat berkolaborasi dengan Anda, saya mencobanya dapat mendorong pembaruan tetapi modifikasi kecil diperlukan untuk memuat kode baru yang harus dilakukan dalam flutter. file artefak jar

Semoga ada solusi secepatnya

Mengenai implikasi kinerja dari penerapan kode push, apakah kompilasi kode Dart ke WebAssembly bisa membantu? Ini memungkinkan penerapan kompilasi JIT di iOS di dalam kotak pasir JavaScript.

kita membutuhkan iterasi yang cepat dan pengembangan yang gesit.
jika tidak ada pembaruan panas, berdebar selalu menjadi adik laki-laki untuk bereaksi asli.

Pembaruan panas sangat penting bagi kami, jika flutter mendukung pembaruan panas, kami akan menggunakan flutter untuk menggantikan reaksi asli.

Saya telah merencanakan cara terbaik untuk mendorong kode tetapi karena kendala waktu saya hanya dapat memulai proyek ini dari November minggu lalu atau dari Desember, saya tidak mengubah kode mesin atau kode kerangka kerja atau kode Java seperti tinker lib sehingga tidak melanggar istilah toko apa pun, aplikasi keluaran juga aot jadi tidak ada regresi kinerja, saya mencoba membuatnya sebagai implementasi yang mudah sehingga siapa pun dapat memasang plugin ke aplikasi mereka, berdasarkan penelitian saya tentang tim flutter basis kode sengaja dibuat tidak mungkin untuk membuat kode push i mencoba semua kemungkinan dengan implementasi saat ini dan menyimpulkan bahwa hanya cara yang mungkin baik Anda harus membuat modifikasi mesin atau menyiapkan solusi tanpa memodifikasi mesin, saya memilih opsi ke-2 dan merencanakan semua persyaratan yang diperlukan untuk proyek tersebut. Saya berharap proyek akan berhasil. Sementara itu jika tim flutter akan menilai kembali masalah ini, kami semua senang dengan implementasi inbuilt.

Pembaruan Panas akan selalu dibutuhkan！

ini adalah fungsi penting yang harus dimiliki

Saya telah merencanakan cara terbaik untuk mendorong kode tetapi karena kendala waktu saya hanya dapat memulai proyek ini dari November minggu lalu atau dari Desember, saya tidak mengubah kode mesin atau kode kerangka kerja atau kode Java seperti tinker lib sehingga tidak melanggar istilah toko apa pun, aplikasi keluaran juga aot jadi tidak ada regresi kinerja, saya mencoba membuatnya sebagai implementasi yang mudah sehingga siapa pun dapat memasang plugin ke aplikasi mereka, berdasarkan penelitian saya tentang tim flutter basis kode sengaja dibuat tidak mungkin untuk membuat kode push i mencoba semua kemungkinan dengan implementasi saat ini dan menyimpulkan bahwa hanya cara yang mungkin baik Anda harus membuat modifikasi mesin atau menyiapkan solusi tanpa memodifikasi mesin, saya memilih opsi ke-2 dan merencanakan semua persyaratan yang diperlukan untuk proyek tersebut. Saya berharap proyek akan berhasil. Sementara itu jika tim flutter akan menilai kembali masalah ini, kami semua senang dengan implementasi inbuilt.

Saya telah merencanakan cara terbaik untuk mendorong kode tetapi karena kendala waktu saya hanya dapat memulai proyek ini dari November minggu lalu atau dari Desember, saya tidak mengubah kode mesin atau kode kerangka kerja atau kode Java seperti tinker lib sehingga tidak melanggar istilah toko apa pun, aplikasi keluaran juga aot jadi tidak ada regresi kinerja, saya mencoba membuatnya sebagai implementasi yang mudah sehingga siapa pun dapat memasang plugin ke aplikasi mereka, berdasarkan penelitian saya tentang tim flutter basis kode sengaja dibuat tidak mungkin untuk membuat kode push i mencoba semua kemungkinan dengan implementasi saat ini dan menyimpulkan bahwa hanya cara yang mungkin baik Anda harus membuat modifikasi mesin atau menyiapkan solusi tanpa memodifikasi mesin, saya memilih opsi ke-2 dan merencanakan semua persyaratan yang diperlukan untuk proyek tersebut. Saya berharap proyek akan berhasil. Sementara itu jika tim flutter akan menilai kembali masalah ini, kami semua senang dengan implementasi inbuilt.

Hai @canewsin
Saya juga mencoba melakukan hal yang sama dengan tidak memodifikasi mesin flutter. Saya menemukan bahwa dalam mode AOT, mesin mencari file .so di jalur perpustakaan asli Android, memodifikasi/menambahkan file di sana setelah kompilasi aplikasi dibatasi oleh JVM. Karenanya memuat file .so yang diunduh melalui udara tidak dapat ditambahkan ke jalur lib asli.

Menunggu lebih banyak wawasan dari Anda. 😀

Saya pikir tidak perlu memperbarui kode dart dan kode asli.
Hanya kode panah yang baik-baik saja!

Hei, aku sedang membutuhkan ini sekarang. Goodle telah memperketat kebijakan peninjauan mereka. Aplikasi kami membutuhkan waktu 2 minggu untuk diperbarui sekarang... Metodologi lean kami kacau balau dengan ini.

@NEELANSHSETHI dapatkah Anda memposting rencananya di sini? Kita bisa mulai menerapkannya

@almeynman Harap

@HerrNiklasRaab Saya belum memulai dengan ini, karena saya tidak memiliki gambaran yang jelas tentang cara mengimplementasikannya. Jika ada yang punya ide, silakan bagikan pemikiran Anda

Itulah alasan utama kami belum bermigrasi dari react-native ke flutter. :(

😔

ReactNative jauh di depan Flutter karena fitur ini dan saya memiliki banyak proyek di mana pilihan lingkungan (RN atau Flutter) didekodekan dibandingkan dengan fitur kode push! Menunggu kabar :/

Hai semua sudah November seperti yang saya katakan saya mulai pekerjaan saya itu berjalan dengan baik. Ini akan menjadi proyek pribadi, jadi saya akan mengenakan biaya kunci lisensi untuk menggunakannya. Jadi tidak akan gratis, karena saya tidak punya sumber penghasilan saya harus melakukan cara ini, jika Anda tertarik saya akan membuat repositori tindak lanjut tentang pekerjaan, ikuti itu untuk pembaruan. Setelah saya membuat timeline repo saya akan memberitahu kalian.

@eseidelGoogle
Kasus bisnis:
Kami memiliki aplikasi pelacakan bus di tablet tetapi pelanggan memperbarui 1 kali dalam sebulan karena tablet menggunakan data internet bukan wifi
Dengan Code Push, kami akan dapat memperbarui tanpa menghabiskan terlalu banyak data pelanggan

Kami memiliki aplikasi cordova dengan dukungan kode push. Ketika datang untuk memodernisasi aplikasi secara keliru, kami pikir flutter akan menambahkan dukungan kode push "bagaimanapun" jadi kembangkan aplikasi kami menggunakan flutter. Tetapi hidup tanpa dorongan kode benar-benar mengerikan selama setahun terakhir bagi kami. Jadi kami akhirnya (dan dengan senang hati) dalam proses (kembali) menulis ulang aplikasi dalam reaksi asli untuk mendapatkan dukungan push kode kami kembali.

Code Push, itulah mengapa saya belajar React-Native sekarang.

Jika Anda tertarik dengan implementasi saya
ikuti laporan kemajuan di sini
https://github.com/canewsin/flutter-code-push-timeline
silakan baca semua komentar saya di atas sebelum melanjutkan.

Code Push, itu sebabnya saya akan tetap menggunakan React-Native.

Tolong jangan posting posting yang tidak konstruktif, +1, "Kami membutuhkan ini", "Kami menggunakan X sebagai gantinya", dll, karena tidak konstruktif dan tidak berkontribusi pada diskusi.

Anda akan memiliki dampak yang jauh lebih baik dengan mengklik tombol Jempol ( 👍 ) pada posting pertama, tanpa semua orang yang pernah memposting ke diskusi ini akan diberitahu tentang hal itu (Sejauh yang saya tahu, beberapa anggota tim flutter akan bisu utas besar, jadi posting di sini memiliki efek yang lebih kecil daripada acungan jempol).

Saya juga ingin mengingatkan semua orang yang berlangganan di sini bahwa github memiliki tombol unsubscribe di kanan atas utas.

Selain itu, tim Flutter memprioritaskan masalah berdasarkan jumlah jempol, sehingga mendapatkan tanggapan yang tinggi dapat menjadi masalah besar. Itu dan hanya mengklik "berlangganan" sudah cukup.

Proyek kode push yang saya ambil berjalan dengan baik tetapi saya ingin beberapa contoh persyaratan kode push, jadi jika kode push selesai, bagaimana Anda menggunakannya, posting persyaratan unik Anda sebagai masalah baru di repo ini https://github.com/ canewsin/flutter-code-push-timeline sehingga pengembangan berada di jalur yang benar.
keterbatasan yang saya temukan sejauh ini adalah:
kami tidak dapat mengakses platform asli tetapi ini dapat dilakukan melalui fungsionalitas ffi.
kode codepush berjalan di kotak pasir untuk beberapa masalah keamanan, jadi tidak ada kerusakan yang dapat dilakukan pada perangkat.

Hai semua sudah November seperti yang saya katakan saya mulai pekerjaan saya itu berjalan dengan baik. Ini akan menjadi proyek pribadi, jadi saya akan mengenakan biaya kunci lisensi untuk menggunakannya. Jadi tidak akan gratis, karena saya tidak punya sumber penghasilan saya harus melakukan cara ini, jika Anda tertarik saya akan membuat repositori tindak lanjut tentang pekerjaan, ikuti itu untuk pembaruan. Setelah saya membuat timeline repo saya akan memberitahu kalian.

Sangat menarik!
Halo, sudah ada contoh belum? Dan bagaimana Anda menangani bagian iOS? karena Apple sangat ketat dalam hal ini. Terima kasih

Hai semua sudah November seperti yang saya katakan saya mulai pekerjaan saya itu berjalan dengan baik. Ini akan menjadi proyek pribadi, jadi saya akan mengenakan biaya kunci lisensi untuk menggunakannya. Jadi tidak akan gratis, karena saya tidak punya sumber penghasilan saya harus melakukan cara ini, jika Anda tertarik saya akan membuat repositori tindak lanjut tentang pekerjaan, ikuti itu untuk pembaruan. Setelah saya membuat timeline repo saya akan memberitahu kalian.

Sangat menarik!
Halo, sudah ada contoh belum? Dan bagaimana Anda menangani bagian iOS? karena Apple sangat ketat dalam hal ini. Terima kasih

saat ini bekerja dengan sisi android, meskipun sisi ios bodoh, mirip dengan versi kotak pasir dari aplikasi js reactnative, kode akan berjalan di kotak pasir tanpa mengakses api platform sehingga mungkin tidak menjadi masalah ketika akan siap untuk sisi ios.

Hai @eseidelGoogle
Ada pembaruan? Linimasa?

Hai @eseidelGoogle
Ada Pembaruan? Ini Desember adalah fitur yang akan dirilis pada 2019?

Saya menanyakan topik AMA tentang masalah ini. Mungkin memiliki informasi yang bermanfaat.
https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w?utm_source=share&utm_medium=web2x

@Hixie Saya membaca artikel Anda di Reddit
https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w/?utm_source=share&utm_medium=web2

Saya ingin tahu apakah pembaruan aplikasi Flutter akan berukuran kecil jika saya menerbitkannya sebagai "Android App Bundle" di Google Play atau hanya untuk kode asli?

Ini adalah fitur penting untuk pembuatan Perusahaan (aplikasi yang didistribusikan di luar toko, misalnya melalui portal web)

Ini adalah fitur yang sangat dibutuhkan. Mengapa kita tidak bisa memilikinya secara resmi? Apa yang mencegahnya memberikan fitur ini?

apakah ini peta jalan 2020?

Tidak

2020 dan masih menunggu

Harap baca ini sebelum memposting di bawah ini.

Berikut adalah rekap singkat jika Anda tidak ingin menggulir ke atas untuk memahami:

Seperti yang ditunjukkan dalam komentar ini , tiga tantangan besar adalah:

• Apa yang didorong?
• Apakah aman bagi pengguna?
• Dari mana ia didorong

Yang pertama, _what_ didorong, adalah di mana letak masalah terbesarnya. Pedoman tinjauan Apple melarang segala jenis kode push apa pun . Ya, istilah yang digunakan _juga termasuk kode javascript push._ Apple tampaknya belum mengambil tindakan terhadapnya, dan mungkin ada banyak alasan untuk itu, tetapi alasan apa pun yang diposting di sini adalah spekulasi murni.

Pedoman play store Google

Flutter, setidaknya dalam mode rilis, dikompilasi , dan meskipun bukan, bukan javascript , oleh karena itu, tidak dapat ditafsirkan di iOS tanpa melanggar persyaratan "tidak ada JIT", atau menjadi sangat lambat.

Yang kedua, apakah _safe_ bagi pengguna, adalah alasan utama di balik logika toko untuk melarang unduhan kode dinamis dan tidak dicentang. Mengizinkan siapa pun mengunduh apa pun dari mana saja dan _hanya menjalankannya_ membahayakan pengguna. Bahkan di dalam kotak pasir, di mana hak istimewa JavascriptCore seputar kode push disorot, itu masih tidak aman.

Code push memungkinkan Anda untuk melewati proses verifikasi toko, yang berarti kode yang tidak dicentang h berjalan di perangkat pengguna, yang berarti mungkin saja salah menggambarkan aplikasi asli, atau bahkan menambahkan fitur berbahaya seperti menyedot data atau mengeksploitasi yang proses verifikasi akan tertangkap .

Anda dapat memiliki niat terbaik di dunia, akan selalu ada seseorang yang menusuk Anda dari belakang bersama mereka.

Untuk saat ini, di Android, jika Anda tidak menggunakan play store untuk mendistribusikan, Anda cukup membangun pengunduh yang akan mengambil apk dan meminta pengguna untuk menginstalnya. Di iOS, Anda secara efektif tidak dapat melakukan sideload tanpa banyak rasa sakit, dan perangkat JB tidak peduli dengan batasan toko aplikasi.

Sekarang, apakah mungkin untuk menerapkannya untuk platform lain selain iOS atau Android? Tentu! Tetapi Desktop belum dalam Beta (selain itu, Anda juga dapat membuat pembaruan otomatis sendiri di desktop), dan, Web, yah, cukup segarkan halaman.

Sekarang, jika Anda ingin tim melihatnya, buka posting pertama dan tambahkan 👍.

Jika komentar Anda termasuk dalam daftar di bawah ini, harap pertimbangkan kembali untuk mempostingnya.

• Menanyakan kapan/apakah itu ada di peta jalan
• "Itu tidak ada" (dan variasi, seperti komentar sebelumnya untuk yang ini)
• "Kami menggunakan framework X karena tidak ada kode push"
• "Framework X lebih baik karena kode push"
• "Kami membutuhkan dorongan kode"
• "Pembaruan?"
• Argumen untuk kode push yang
  
  
  
  • Aplikasi Perusahaan/Sideload
  
  
  • Penambalan darurat
  
  
  • Menambahkan fitur
  
  
• Argumen menentang kode push yang
  
  
  
  • Durasi ulasan play/app store sekarang lebih pendek
  
  
  • Play/app store melarangnya
  
  
  • Anda tidak membutuhkannya
  
  

Masalah ini sudah diisi dengan cukup komentar seperti, jadi tolong jangan menambahkan komentar yang menambah apa-apa untuk percakapan. Jika tim memiliki sesuatu untuk dikatakan, mereka akan mempostingnya di sini, karena postingan ini memiliki hampir 100 peserta saat ini, dan lebih dari 500 jempol, tidak mungkin untuk mengabaikannya.

Sejujurnya saya tidak berpikir ini harus menjadi perhatian Anda. Pengembang akan menggunakan fitur dengan risikonya sendiri. Jika Apple tiba-tiba memutuskan untuk melarang semua aplikasi menggunakan kode push, maka aplikasi Anda harus menggunakan pendekatan yang berbeda. Tapi ini tidak terjadi untuk JavaScript. Itu tidak terjadi selama bertahun-tahun, mengapa itu harus terjadi pada Flutter? Mereka bahkan tidak bisa memeriksanya. Orang-orang meminta fitur ini karena berguna. Anda dapat menulis modul kecil dan memperbaruinya secara dinamis. Ini adalah pengubah permainan. Anda dapat memperbaiki bug dalam modul dengan cepat. Selain itu, Apple tidak dapat benar-benar memeriksa apa yang dilakukan aplikasi, tidak memiliki sumber daya. Itu tidak mungkin, saya harap Anda menyadarinya. Selain itu, apa gunanya? Saya dapat menulis kode yang tidak jelas dan memasukkan pintu belakang ke dalam aplikasi, yang dipicu ketika saya memberikan JSON tertentu sebagai hasil dari panggilan REST. Bagaimana Apple dapat memverifikasinya? Tidak bisa. Tidak ada yang bisa dilakukan Apple atau Android untuk menghentikannya. Orang-orang membutuhkan fitur ini, dan Anda harus menerapkannya. Apa yang kami lakukan dengannya, itu urusan kami, bukan urusan Anda. Anda mengatakan sendiri, fitur ini memiliki lebih dari 500 jempol dan lebih dari 100 peserta. Mungkin sudah saatnya Anda menerapkannya sesuai permintaan komunitas.

@dedalozzo Argumen baru yang bagus!

Saya bukan bagian dari tim flutter, jadi tolong jangan targetkan saya untuk meminta implementasi.

Namun, memang benar bahwa Apple dan Google mungkin tidak memiliki sumber daya untuk mendeteksi bahwa (bermain tim protect aktif sepanjang waktu, mereka dapat mendeteksi perilaku berbahaya secara otomatis), namun mengimplementasikannya "di belakang punggung mereka" sekarang Apple memberikan alasan yang sebenarnya untuk menerapkan larangan menyeluruh pada Flutter, karena pada dasarnya _dilengkapi dengan_ alat yang secara eksplisit bertentangan dengan kebijakan mereka.

Anda juga dapat membingkainya sebagai bagian dari pertanyaan etis (Haruskah Anda menerapkan sesuatu yang menambahkan risiko tambahan ke aplikasi, dan bertentangan dengan kebijakan toko, atas nama kemajuan?) atau sebagai pertanyaan penjadwalan (Haruskah Anda mengerjakan sesuatu yang memiliki a besar-besaran " Jika Anda menggunakan ini, kemungkinan Anda dapat diblokir dari klausa

Tidak hanya itu, tetapi secara tidak sengaja melanggar kebijakan play store/terkait dengan seseorang yang melanggar kebijakan play store pada dasarnya berarti membuat akun Anda diblokir, sehingga akan bermain api, membuat pengguna _ semakin kecil kemungkinannya untuk menggunakan fitur tersebut_.

Plus, seperti yang dinyatakan di atas, distribusi di luar play store memungkinkan Anda mendorong APK yang diperbarui.

Maaf, saya pikir Anda adalah salah satu dari tim Flutter.

Apa yang Anda katakan di komentar terakhir Anda adalah benar. Faktanya, dorongan kode tampaknya ditoleransi oleh Apple dan Google, meskipun itu batas dan melanggar aturan.

Tetapi selama aplikasi Anda tidak membahayakan, saya rasa mereka tidak akan repot-repot memeriksa apakah Anda benar-benar mendorong kode. Mereka mungkin, jika seseorang melaporkan perilaku aneh. Tetapi pada saat itu mereka akan mengambil tindakan terhadap pengembang aplikasi itu, bukan seluruh aplikasi yang menggunakan kode push.

Sangat banyak pekerjaan yang sedang berlangsung, tetapi memungkinkan kode Push https://github.com/chgibb/hydro-sdk

@chgibb Tunggu... yang mengaktifkan kode push tetapi juga mengubah semuanya dari Dart ke TypeScript?

Apakah ada cara untuk memisahkan kedua hal tersebut? Untuk mendapatkan codepush saat menulis Dart seperti biasa?

@SpajicM yang hanya berfungsi _karena_ tidak menggunakan Dart, sebaliknya, mungkin menggunakan mesin JS, seperti JavascriptCore, yang dimiliki oleh Apple, dan mereka tampaknya melihat ke arah lain ketika digunakan dengan kode push.

Gores itu, ia menggunakan bytecode Lua, yang bertentangan dengan kebijakan toko dalam segala bentuk atau bentuk.

@miyoyo mengapa itu secara khusus bertentangan dengan kebijakan toko?
@SpajicM itu murni aditif. Potongan TypeScript dapat disematkan ke dalam aplikasi Dart yang lebih besar. Sekecil satu teks, atau seluruh layar.

Kebijakan toko dilarang untuk mendorong segala jenis kode terkompilasi, yang tampaknya merupakan file .hc , karena mereka dikompilasi lua bytecode (mungkin dengan ekstensi, belum diperiksa).

Kasus penggunaan khusus dari mendorong kode _compiled_ ke aplikasi secara eksplisit bertentangan dengan kebijakan play store , dan elemen "tidak ada kode sumber yang disediakan" yang Anda _bisa_ berikan javascript karena, di CodePush, tidak akan berlaku, melanggar pedoman Apple .

Saya tidak mengatakan konsep itu buruk, pada kenyataannya, itu pekerjaan yang bagus! Hanya saja mengunduh bytecode melalui internet secara eksplisit bertentangan dengan kebijakan toko dalam kedua kasus.

Bagaimana cara kerja semua game seluler ini dengan pembaruan dalam gamenya? Apakah mereka hanya mendorong/mengunduh aset?

@miyoyo dari strategi Google Play; https://play.google.com/about/privacy-security-deception/malicious-behavior/
...This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs...
File .hc Hydro-SDK adalah murni bytecode Lua 5.2 tanpa ekstensi atau fitur khusus. Mereka dijalankan dalam juru bahasa tanpa fungsi untuk mutasi sendiri atau pembuatan kode. Tidak ada apapun dari dart:io yang terekspos kepada mereka. Padahal, tidak ada yang menghentikan embedder untuk mengekspos dart:io 's File class, atau mengekspos PlatformChannel s misalnya.

Apel bagian 2.5.2 sedikit lebih ambigu sehubungan dengan arti kata "eksekusi", serta dalam mengubah fitur atau fungsi.

https://developer.apple.com/app-store/review/guidelines/#2.5.2

...
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, 
...

@chgibb Oke, saya akan mengatakan itu mungkin lolos di Android, meskipun saya masih mengharapkan penolakan di App Store. (Belum lagi penurunan kinerja puncak, tapi itu mungkin detail pada ponsel kelas atas)

@kuhnroyal Pembaruan game seluler menggunakan Pengiriman Aset Dinamis untuk hal - File Perluasan APK yang memungkinkan Anda melakukan peningkatan sebagian, tetapi masih tunduk pada siklus pembaruan toko reguler, dan pembaruan APK reguler .

Berbicara dengan pelanggan: tajuk bahwa ini bukan lagi prioritas bagi mereka.

Anda dapat menggunakan Localizely untuk pembaruan teks/terjemahan over-the-air: https://localizely.com/flutter-over-the-air

Demi flutter, buat fitur ini atau pandu kami tentang cara membuatnya. Terima kasih .

Teman-teman _please_, ini adalah ketiga kalinya ini diposting, tetapi _Jangan mengirim komentar kecuali Anda benar-benar memiliki sesuatu untuk ditambahkan_ .

Konsultasikan posting ini untuk lebih jelasnya dan untuk memberi acungan jempol pada posting pertama.

Pesan tidak memiliki pengaruh lagi, karena saya cukup yakin sebagian besar tim di sini telah menonaktifkan notifikasi untuk postingan ini, mari kita kurangi kebisingan _kecuali jika Anda memiliki sesuatu untuk ditambahkan_.

sementara itu ada alternatif untuk kode push?

sementara itu ada alternatif untuk kode push?

berdasarkan pengalaman saya, tidak ada alternatif

@samerdernaika @mfenej sementara belum cukup siap produksi, proyek ini dimulai dengan kode push sebagai tujuan eksplisit https://github.com/chgibb/hydro-sdk

@miyoyo

Yang pertama, _what_ didorong, adalah di mana letak masalah terbesarnya. Pedoman tinjauan Apple melarang segala jenis kode push apa pun . Ya, terminologi yang digunakan _juga termasuk kode javascript push. Apple tampaknya belum mengambil tindakan terhadapnya, dan mungkin ada banyak alasan untuk itu, tetapi alasan apa pun yang diposting di sini akan menjadi spekulasi murni.

Itu tidak benar. Harap periksa kembali dan jangan menyebarkan informasi yang salah!

Bagian 3.3.2 dari perjanjian lisensi pengembang Apple menyatakan:

3.3.2Kecuali sebagaimana diatur dalam paragraf berikutnya, Aplikasi tidak boleh mengunduh atau menginstal kode yang dapat dieksekusi. Kode yang ditafsirkan dapat diunduh ke Aplikasi tetapi hanya selama kode tersebut: (a) tidak mengubah tujuan utama Aplikasi dengan menyediakan fitur atau fungsi yang tidak sesuai dengan tujuan Aplikasi yang dimaksudkan dan diiklankan seperti yang dikirimkan ke Aplikasi Toko, (b) tidak membuat penyimpanan atau etalase untuk kode atau aplikasi lain, dan (c) tidak mengabaikan penandatanganan, kotak pasir, atau fitur keamanan OS lainnya.

Mereka secara khusus mengizinkan kode yang ditafsirkan seperti JS untuk diunduh selama Anda tidak mengubah tujuan utama aplikasi. Sudah seperti ini selama lebih dari 5 tahun sekarang IIRC dan saya belum pernah mendengar ada orang yang ditarik karena menggunakan codepush secara normal dan bertanggung jawab.

Lihat bagian AppCenter tentang codepush dan kepatuhan pedoman toko. Codepush AppCenter (didukung oleh Microsoft) digunakan oleh banyak aplikasi tanpa masalah kepatuhan toko. https://github.com/microsoft/react-native-code-push#store -guideline-compliance

Pemblokir besar untuk codepush yang saya lihat adalah bahwa itu mungkin tidak sebanding dengan pengorbanan kinerja karena dipaksa menggunakan kompilasi-ke-js atau menafsirkan Dart di iOS alih-alih dikompilasi sebelumnya. Karena Flutter menargetkan browser, namun saya menduga kinerja kompilasi-ke-js akan cukup baik, tetapi mungkin masih bukan pertukaran kinerja yang dapat diterima oleh tim Flutter.

Mungkin solusi pihak ketiga (seperti AppCenter for React Native) akan datang dan mengisi celah ini. CodePush sangat berguna!

Hmm, pencarian Google cepat mengungkapkan banyak contoh aplikasi penolakan Apple yang menyertakan kemampuan kode push, lihat misalnya

https://github.com/microsoft/react-native-code-push/issues/1297

Mengingat bahwa waktu peninjauan App Store sekarang hampir selalu diukur dalam hitungan jam dan bukan hari, saya tidak mengerti mengapa ada orang yang mau mengambil risiko. Jika dorongan kode diintegrasikan ke dalam mesin Flutter, Apple dapat memutuskan untuk melarang semua aplikasi Flutter.

@matthewlloyd Anda benar sekali bahwa waktu peninjauan telah turun. Saya sendiri mengirimkan aplikasi (eksklusif) ke App Store pagi ini dan telah disetujui pada akhir hari ini! Tapi itu _baru-baru ini_. Kami, sebagai penerbit aplikasi seluler masih terikat pada keinginan/kapasitas tim peninjau untuk meninjau kiriman kami.

Pembaruan yang sampai ke tangan pengguna Anda tidak berjalan secepat tinjauan aplikasi. Waktu antara "Rilis Pengembang", "Pemrosesan App Store", propagasi ke server di pasar pengguna Anda, dll dapat memakan waktu cukup lama juga. Saya telah melihat tahap-tahap selanjutnya ini memakan waktu lebih dari 24 jam dalam kasus-kasus ekstrem.

Berbicara secara pribadi, hasrat saya untuk dorongan kode adalah tentang mengambil alih kepemilikan atas rantai pasokan pengiriman pembaruan sebagaimana adanya. Belum lagi rintangan yang agak besar yang terlibat dalam upaya untuk mengotomatisasi proses saat ini ke dalam pengaturan CD yang koheren mengingat keadaan yang menyedihkan dari perkakas CLI xcode .

Kurang dari 24 jam di sebagian besar kasus sudah cukup untuk hampir semua orang, saya pikir. Jika Anda perlu mendapatkan pembaruan melalui proses peninjauan Apple lebih cepat dari itu, misalnya untuk perbaikan bug yang mendesak, Anda dapat meminta peninjauan yang dipercepat. Saya telah melakukannya pada satu kesempatan, dan tinjauan aplikasi selesai secara harfiah 10 menit setelah saya mengajukan permintaan.

Mengambil kepemilikan atas rantai pasokan pengiriman adalah sesuatu yang dilakukan dengan risiko sendiri...

Pedoman App Store Apple, bagian 2.5.2 (https://developer.apple.com/app-store/review/guidelines/#software-requirements):

"2.5.2 Aplikasi harus mandiri dalam bundelnya, dan tidak boleh membaca atau menulis data di luar area penampung yang ditentukan, juga tidak boleh mengunduh, memasang, atau menjalankan kode yang memperkenalkan atau mengubah fitur atau fungsi aplikasi , termasuk lainnya aplikasi. Aplikasi pendidikan yang dirancang untuk mengajar, mengembangkan, atau mengizinkan siswa menguji kode yang dapat dijalankan, dalam keadaan terbatas, dapat mengunduh kode asalkan kode tersebut tidak digunakan untuk tujuan lain. Aplikasi tersebut harus membuat kode sumber yang disediakan oleh Aplikasi dapat dilihat sepenuhnya dan dapat diedit oleh pengguna."

Persyaratan program pengembang Apple, bagian 3.3.2:

3.3.2 Kecuali sebagaimana diatur dalam paragraf berikutnya, Aplikasi tidak boleh mengunduh atau menginstal kode yang dapat dieksekusi.

@AndrewMorsillo Tidak peduli apa yang ada di setiap pedoman dan tidak peduli berapa banyak informasi yang diajukan, yang terbaik yang bisa kita dapatkan adalah "Mungkin diizinkan, kami tidak yakin itu bukan pelanggaran yang dapat dilarang, sebenarnya, mungkin kami tidak yakin" .

Apa pun masalahnya, Flutter tidak menjalankan dart yang ditafsirkan di iOS sekarang, menambahkannya akan menjadi hambatan kinerja, dan seperti yang Anda sendiri telah sampaikan, selain posting saya sebelumnya dan posting @matthewlloyd , ini adalah yang terbaik. diperbolehkan dalam beberapa kasus, secara umum itu adalah area yang sangat abu-abu, dan paling buruk itu hanya dilarang.

Sejauh yang saya tahu, menukar semua itu untuk melewati siklus ulasan 24 jam dan tes menulis tidak sepadan. (Saya bisa mengerti ketika itu seminggu, dan itu biasanya hanya di pihak iOS, yang secara efektif merupakan titik pertengkaran terbesar di sini)

Ini bahkan bukan hanya tentang proses peninjauan, ini juga tentang pengguna yang terjebak pada versi lama aplikasi karena mereka mungkin telah menonaktifkan pembaruan otomatis.

Tentu, Anda dapat menerapkan versi minimum, periksa sendiri tetapi kemudian mereka harus melalui Play Store dan sayangnya, orang-orang malas. Dengan kode push, itu bisa dengan cepat memperbarui aplikasi di setiap proses (saya harap) dan membiarkan pengguna masuk dengan lebih mulus.

@miyoyo Saya tidak tahu mengapa Anda merasa perlu menanggapi setiap komentar atau ide yang disajikan di sini. Orang-orang menginginkan ini. Kalian memberi tahu orang-orang untuk meningkatkan masalah, dan kami meningkatkannya sampai ke atas. Ini tidak akan pernah terpecahkan kecuali seseorang secara aktif memikirkannya dan mendorongnya.

Ada cara lain untuk menyelesaikan ini. Saya telah melihat banyak aplikasi melakukannya. Aplikasi jika keluar
tanggal, munculkan pesan, baik Anda menutupnya atau memperbarui aplikasi. itu semua.

Pada Jumat, 7 Agustus 2020 pukul 07:38, SpajicM [email protected] menulis:

Bahkan bukan hanya tentang proses peninjauan, ini juga tentang pengguna yang mendapatkan
terjebak di versi lama aplikasi karena mereka mungkin telah mematikan
pembaruan otomatis.

Tentu, Anda dapat menerapkan versi minimum, periksa sendiri, tetapi kemudian mereka
lagi harus melalui Play Store dan sayangnya orang-orang malas. Dengan
kode push, itu bisa dengan cepat memperbarui aplikasi setiap kali dijalankan (saya harap) dan
biarkan pengguna masuk dengan lebih mulus.

@miyoyo https://github.com/miyoyo Saya tidak tahu mengapa Anda merasakannya
perlu menanggapi setiap komentar atau ide yang disajikan di sini.
Orang-orang menginginkan ini. Kalian memberi tahu orang-orang untuk mendukung masalah ini, dan kami mendukungnya
itu semua jalan ke atas. Ini tidak akan pernah terpecahkan kecuali seseorang
secara aktif memikirkannya dan mendorongnya.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-670242698 ,
atau berhenti berlangganan
https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA
.

Ada cara lain untuk menyelesaikan ini. Saya telah melihat banyak aplikasi melakukannya. Aplikasi jika kedaluwarsa, munculkan pesan, apakah Anda menutupnya atau memperbarui aplikasi. itu semua.

Mungkin cara UX terburuk... :/

@SpajicM

Ini bahkan bukan hanya tentang proses peninjauan, ini juga tentang pengguna yang terjebak pada versi lama aplikasi karena mereka mungkin telah menonaktifkan pembaruan otomatis.

Tentu, Anda dapat menerapkan versi minimum, periksa sendiri tetapi kemudian mereka harus melalui Play Store dan sayangnya, orang-orang malas. Dengan kode push, itu bisa dengan cepat memperbarui aplikasi di setiap proses (saya harap) dan membiarkan pengguna masuk dengan lebih mulus.

Dari segi UX, bukankah ini cara _bad_ untuk menangani pembaruan? Jika seseorang menonaktifkan pembaruan otomatis secara manual, mengapa Flutter harus menimpanya? Masih bisa diperdebatkan jika ada aplikasi yang memiliki kekuatan itu, tetapi tentu saja tidak seluruh kerangka kerja.

Saya pikir memusatkan proses pembaruan melalui toko aplikasi lebih baik untuk UX karena mereka dapat mengelola semua pembaruan melalui toko. UX dengan mengorbankan waktu pengembang adalah inti dari pengembangan aplikasi. Dan jika Anda memerlukan perbaikan segera (misalnya, untuk kerentanan), Anda bisa mendapatkan pembaruan yang dipercepat, atau menolak untuk mengizinkan pengguna menggunakan aplikasi hingga diperbarui. Tentu saja yang terakhir bukanlah pilihan yang bagus, dan yang pertama menjengkelkan, tetapi itu karena Apple dan Google mengutamakan pengguna, dan tidak ada hubungannya dengan Flutter itu sendiri.

@chgibb

Berbicara secara pribadi, hasrat saya untuk dorongan kode adalah tentang mengambil alih kepemilikan atas rantai pasokan pengiriman pembaruan sebagaimana adanya.

Ini adalah jenis masalah dengan utas ini -- mencoba melakukan apa yang diperingatkan oleh Apple dan Google bukanlah ide yang baik jika Anda akan menggunakan toko aplikasi mereka. Seperti yang dikatakan @miyoyo , ini adalah area abu-abu, yang tidak sepenuhnya cocok untuk kerangka kerja yang digunakan oleh Google dan perusahaan/individu lain.

Akhirnya https://github.com/flutter/code-push

Ini sebenarnya https://github.com/microsoft/react-native-code-push

Nah Flutter masih tidak bisa memperbarui kode Anda, tetapi sebenarnya tautan itu berbicara tentang gambar dan itu mengingatkan saya bahwa Firebase Remote Config adalah suatu hal. Kelemahannya adalah Anda perlu mendahului bit kode mana yang mungkin perlu diubah dan mengharapkan perubahan itu di aplikasi Anda, tetapi setelah selesai, itu akan cukup cepat untuk meluncurkan perubahan baru tanpa app store (mirip dengan apa yang dilakukan React Native Code Push dengan gambarnya)

@ardyfeb Orang-orang seperti Anda memberi

Ada cara lain untuk menyelesaikannya
tanpa menggunakan web bergetar

Ada cara lain untuk menyelesaikan ini. Saya telah melihat banyak aplikasi melakukannya. Aplikasi jika kedaluwarsa, munculkan pesan, apakah Anda menutupnya atau memperbarui aplikasi. itu semua.
…
Pada Jum, 7 Agustus 2020 pukul 07:38, SpajicM @ . * > menulis: Ini bukan hanya tentang proses peninjauan, ini juga tentang pengguna yang terjebak pada versi lama aplikasi karena mereka mungkin telah mematikan pembaruan otomatis. Tentu, Anda dapat menerapkan versi minimum, periksa sendiri tetapi kemudian mereka harus melalui Play Store dan sayangnya, orang-orang malas. Dengan kode push, itu bisa dengan cepat memperbarui aplikasi di setiap proses (saya harap) dan membiarkan pengguna masuk dengan lebih mulus. @miyoyo https://github.com/miyoyo Saya tidak tahu mengapa Anda merasa perlu menanggapi setiap komentar atau ide yang disajikan di sini. Orang-orang menginginkan ini. Kalian memberi tahu orang-orang untuk meningkatkan masalah, dan kami meningkatkannya sampai ke atas. Ini tidak akan pernah terpecahkan kecuali seseorang secara aktif memikirkannya dan mendorongnya. — Anda menerima ini karena Anda berlangganan utas ini. Balas email ini secara langsung, lihat di GitHub < #14330 (komentar) >, atau berhenti berlangganan https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA .

Kedengarannya bagus... jika Anda membuat aplikasi perbankan.

Jika seseorang membutuhkan pembaruan Over-the-air hanya untuk terjemahan aplikasi, berikut adalah contoh aplikasi Flutter: https://github.com/localizely/flutter-ota-sample-app

Tampaknya pedoman apel berbeda dari sebelumnya?

Ini masih sama

2.5.2 Aplikasi harus mandiri dalam bundelnya, dan tidak boleh membaca atau menulis data di luar area penampung yang ditentukan, juga tidak boleh mengunduh, memasang, atau menjalankan kode yang memperkenalkan atau mengubah fitur atau fungsi aplikasi, termasuk aplikasi lain . Aplikasi pendidikan yang dirancang untuk mengajar, mengembangkan, atau mengizinkan siswa menguji kode yang dapat dijalankan, dalam keadaan terbatas, dapat mengunduh kode asalkan kode tersebut tidak digunakan untuk tujuan lain. Aplikasi tersebut harus membuat kode sumber yang disediakan oleh Aplikasi benar-benar dapat dilihat dan diedit oleh pengguna.

Namun, saya tidak dapat menemukan referensi lain untuk kode yang ditafsirkan atau dieksekusi.

Mungkinkah detail tentang ekosistem apel dari pos asli tidak lagi benar mengingat mereka sepertinya tidak lagi mengatakan apa pun secara khusus tentang bahasa yang ditafsirkan atau dikompilasi?