Flutter: Code Push / Hot Update / Out-of-Band-Updates

Erstellt am 29. Jan. 2018  ·  171Kommentare  ·  Quelle: flutter/flutter

Dies steht derzeit nicht auf Flutters Roadmap, aus Gründen, die in diesem Kommentar erörtert werden:
https://github.com/flutter/flutter/issues/14330#issuecomment -485565194

Dieser Kommentar gibt auch einen kurzen Überblick über die verschiedenen Arten von "Hot Update"-Funktionen, über die Sie möglicherweise nachdenken, und enthält eine Terminologie für deren Bezugnahme, die hilfreich sein kann, wenn Sie eindeutig über dieses Thema kommunizieren möchten:
https://github.com/flutter/flutter/issues/14330#issuecomment -442274897


Oft wird gefragt, ob Flutter "Code Push" oder "Hot Update" oder andere ähnliche Namen für das Pushen von Updates außerhalb des Stores an Apps unterstützt.

Derzeit bieten wir keine solche Lösung out of the box an, aber die primären Blocker sind nicht technisch. Flutter unterstützt die Just-in-Time (JIT) oder interpreterbasierte Ausführung sowohl auf Android- als auch auf iOS-Geräten. Derzeit entfernen wir diese Bibliotheken während der --release-Builds, könnten sie jedoch problemlos einschließen.

Die primären Blocker für diese Funktion lösen aktuelle Macken des iOS-Ökosystems, die möglicherweise erfordern, dass Apps JavaScript für diese Art von Over-the-Air-Update-Funktionalität verwenden. Glücklicherweise unterstützt Dart das Kompilieren in JavaScript und so kann man sich mehrere Möglichkeiten vorstellen, wie man Teile seiner Anwendung in JavaScript statt in Dart kompiliert und so die Ersetzung oder Erweiterung dieser Teile in bereitgestellten Binärdateien ermöglicht.

Dieser Fehler verfolgt das Hinzufügen einer unterstützten Lösung wie diese. Ich werde alle anderen Berichte hier täuschen.

P5 production crowd engine passed first triage new feature

Hilfreichster Kommentar

Wir haben hier einige grundlegende Prototypen gebaut, haben aber derzeit nicht wirklich etwas mitzuteilen. Um dies wirklich gut zu machen, ist einige Arbeit in der Compiler-Toolchain von Dart erforderlich. Ich würde erwarten, dass es viele Monate dauern wird, bis wir hier viel zu teilen haben. Das Team konzentriert sich derzeit auf die Stabilisierung für 1.0.

Alles in allem hören wir Sie. :) Dies ist eindeutig eine Funktion, die viele Leute schätzen und wir sind daran interessiert, solche Funktionen irgendwann bereitzustellen.

Alle 171 Kommentare

cc @floitschG

siehe auch
https://groups.google.com/forum/#!msg/flutter -dev/YwzItp1pxJo/7bFGDLvxBAAJ
Darüber würde ich mich riesig freuen.

Ich denke, dies wäre ziemlich wichtig, da dies möglicherweise eines der einzigen wirklich charakteristischen Merkmale von React Native ist, und leider könnten einige Unternehmen dies als Dealbreaker betrachten.

Anwendungsfälle

  • Kritische Fehler, insbesondere auf iOS, insbesondere für VIPs oder dringende, zeitkritische Situationen, geschäftskritische und/oder Benutzer, die die App aus irgendeinem Grund überhaupt nicht verwenden können.
  • Dynamischeres Testen von Features als gestaffelte Rollouts
  • Dies wäre eine nette Geste, um sich auf Fuschia und/oder Chromebooks vorzubereiten. Es könnte Szenarien geben, in denen Flattern mit Web-Apps "konkurriert", nicht nur mit pwas/Kotlin/Swift/React/Xamarin/other-junkier-hybrid solutions

In der epischen Schlacht zwischen Flutter und React Native ist Code-Push ein unglaubliches Werkzeug (:
Als RN-Entwickler kann ich die Bedeutung dieser Funktion nicht genug betonen. Viele werden an Flattern vorbeigehen, nur weil es keine heißen Stöße gibt. Wenn Sie sich einmal daran gewöhnt haben, Fehler schnell zu beheben und neue Funktionen zu veröffentlichen, können Sie nicht mehr zurück.

Das Kompilieren in einen Javascript-Pfad verringert die Dart-Vorteile, oder?
Ich habe eine native App gefunden, mit der Code mithilfe von Rollout.io neu geladen werden konnte, aber von Apple blockiert wurde: https://news.ycombinator.com/item?id=13817557
Wenn man sich dieses Muster anschaut, scheint es, als würde Flutter keine nahtlose Code-Push-Funktion haben, wie wir sie bei React Native sehen.
würde gerne mehr Einblick in diese Feature-Möglichkeiten von Core-Maintainern erhalten (:

Das Kompilieren in einen Javascript-Pfad verringert die Dart-Vorteile, oder?

Von welchen Vorteilen redest du?

Codepush wird dringend benötigt. Ich freue mich, die Möglichkeit der Over-the-Air-Upgrade-Veröffentlichung auf Flutter zu sehen.

Wir hatten gerade einen Live-Anwendungsfall mit einer Produktions-App, bei dem wir viele schlechte Kritiken für eine Funktion erhielten, die anscheinend ein Randfall war (in Bezug auf die Verweigerung der Standortberechtigung in einem Anwendungsfall, den nicht jeder Testaccount hatte), aber es war wirklich so. T.

eine Codepush-Funktion könnte kritische Fixes für Benutzer sofort bereitstellen, anstatt darauf zu warten, dass sie aktualisiert werden; Aus irgendeinem Grund scheinen Benutzer manchmal langsam zu aktualisieren :(

Keine Hot-Code-Push-Unterstützung ist ein NO GO :-(

Anscheinend wird JavascriptCore für interpretierten Code nicht mehr benötigt: https://www.theregister.co.uk/2017/06/07/apple_relaxes_developer_rules/?page=2

Wenn das IOS-Ökosystem ein Hindernis ist, warum nicht vorerst nur auf Android implementieren? Etwas besser als nichts und es ist ein Ausgangspunkt.

Sehr geschätzt für das Team, diese Funktion so schnell wie möglich zu implementieren.

Wir haben hier einige grundlegende Prototypen gebaut, haben aber derzeit nicht wirklich etwas mitzuteilen. Um dies wirklich gut zu machen, ist einige Arbeit in der Compiler-Toolchain von Dart erforderlich. Ich würde erwarten, dass es viele Monate dauern wird, bis wir hier viel zu teilen haben. Das Team konzentriert sich derzeit auf die Stabilisierung für 1.0.

Alles in allem hören wir Sie. :) Dies ist eindeutig eine Funktion, die viele Leute schätzen und wir sind daran interessiert, solche Funktionen irgendwann bereitzustellen.

Die Unterstützung von "Code Push" für Flutter könnte der letzte Sargnagel in Bezug auf React Native sein.

Bei all meiner Liebe zu RN und der RN-Community ist es kein Spiel für Flutter.
Flutter nagelt es einfach in jeder Hinsicht (Werkzeuge, Leistung, Sprache...).

Nach 1.0 Hits und die Community wächst ein bisschen mehr + Code Push Support = Kann keinen Grund sehen ein neues mobiles Projekt mit etwas anderem dem Flutter zu starten.

irgendwelche Fortschritte bei "Code Push" ??

Wie machbar wäre es, eine vollständige .so-Datei dynamisch zu ersetzen? Die gesamte Compiler-Toolchain, Code-Shake usw. sollten nicht auf einen wohl Randfall gelenkt werden, von dem die Leute profitieren oder nicht, da immer Tickets ganz oben auf der Prioritätenliste stehen.

Ich denke, es sollte Platz für das "Sideloaden" der vollständigen .so-Datei geben, damit der Build vom Dart- zum Maschinencode immer noch genau gleich sein kann. Einer kleinen, aber völlig eigenständigen Komponente könnten folgende "Minimum Viable Features" zugewiesen werden: .so herunterladen und die ursprünglich ausgelieferte Komponente damit ersetzen und App mit der Hauptstartabsicht neu starten.

Zusätzliche Verantwortlichkeiten: Assets herunterladen, Signaturen überprüfen und was nicht. Aktualisieren Sie Flatter-/Dart-/Skia-Motoren und was nicht.

Es klingt für mich, als würde es gegen die iOS-Richtlinien verstoßen, aber ich bin sowieso kein Fan von irgendetwas, das sowieso interpretiert wird, oder von iOS im Allgemeinen. Und ich hätte es lieber in Android, als es überhaupt nicht zu haben, nur weil es cool ist.

Zumindest der Download-Teil scheint jetzt machbar, da im Hintergrund einige Isolate erlaubt sind, aber es wäre interessant zu sehen, wie man die ursprüngliche .so-Datei mit der heruntergeladenen austauscht. Vielleicht könnte ein zusätzlicher .so- oder Java-Code diesen Teil erledigen, aber er wird im Code-Ordner sitzen, nicht sicher, ob die App selbst ihn ändern kann, also bräuchte es wahrscheinlich einige Optimierungen, damit die Flatter-Engine alle .so-Dateien der App von intern lädt Daten?

Ich fange an, meine Firmen-App mit Flatter zu überarbeiten. Unsere Hauptforderung ist jedoch, eine Hot-Update-Funktion zu haben, da wir uns noch in der Beta-Phase befinden und neue Benutzeroberflächen und Funktionen schnell testen. Würde leben, um diese Funktion zu haben.

Irgendwelche Updates?
(Ich wette, die Funktion ist bereits fertig und wird eine Überraschung sein, wenn 1.0 erreicht wird)
😁

abstimmen

Es gibt nur einen Grund, uns von der Verwendung von Flutter abzuhalten: Code Push

Wenn Sie Code Push nicht unterstützen können, gibt es eine Möglichkeit, einen Parser zu erstellen, der aus einigen Wörterbüchern (wie json, xml ...) zu Flutter Widget generiert? Ist das unmöglich oder eine gute Idee?

Das klingt etwas vielversprechend. Firebase-Remote-Konfiguration zum Widget, falls erforderlich.
Obwohl es auch hilft, Unternehmen eine Idee zu geben, was sie wollen :)

Am Fr, 12. Okt 2018, 03:45 Uhr Hưng Lương Đỗ Minh [email protected]
schrieb:

Wenn Sie Code Push nicht unterstützen können, gibt es eine Möglichkeit, einen Parser zu erstellen?
Generieren Sie aus einigen Wörterbüchern (wie json, xml ...) zu Flutter Widget? Ist
das unmöglich oder eine gute idee?


Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/flutter/flutter/issues/14330#issuecomment-429251785 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AC4TYe9qDMi4bt2U5qyyAnJisN3ys_Z5ks5ukFavgaJpZM4RxUZi
.

Ich denke, zumindest die in Dart geschriebene Benutzeroberfläche/Ansicht kann über das Netzwerk vom Server heruntergeladen werden.
Sehen Sie sich zur Inspiration an, wie das Qt Quick-Framework dies macht.

QtDD12 – Bereitstellung von QML-Anwendungen über das Netzwerk – Jeremy Laine:

erwarten, dass es in der kommenden 1.0-Version enthalten sein kann!

Viele unserer Kunden werden unsere Flutter-App auf einem Kioskgerät hinter strengen Firewalls verwenden, die die App-Update-Mechanismen des Google Stores verhindern würden. Diese Kunden werden den Play Store nicht auf die weiße Liste setzen. Wir werden letztendlich Hunderte von Hardwaregeräten mit der Flutter-App haben, und eine Möglichkeit zu haben, Updates auf die App zu übertragen, während die Firewall-Beschränkungen der Kunden eingehalten werden, wäre großartig!

@eseidelGoogle - es ist schon eine Weile her, seit ihr hier ein paar Updates bereitgestellt habt.

Arbeitet ihr noch daran? Wie laufen die Dinge?

Der Fortschritt geht weiter. Derzeit keine Aktualisierungen zum Teilen.

Wir haben uns drei klare Begriffe dafür ausgedacht, was die Leute heute in diesen Fehler gesteckt haben:

  • "Dynamisches Patchen": die Möglichkeit, den Dart-Code einer App im Feld zu aktualisieren, indem ein Patch (einer Art) heruntergeladen und der Dart-VM bereitgestellt wird. Dies würde ein Neuladen der App erfordern, um wirksam zu werden.
  • "Dynamisches Laden von Erweiterungen": die Möglichkeit, Dart-Code herunterzuladen, der bei der ersten Veröffentlichung der App nicht geschrieben wurde, wodurch der App eine neue Funktion hinzugefügt wird. Dies könnte im laufenden Betrieb erfolgen. Es kann erforderlich sein, dass die Kern-App größer ist, da wir nicht im Voraus wissen können, was von jeder zukünftigen Erweiterung benötigt wird.
  • "Modulare Anwendungsbereitstellung": die Möglichkeit, eine einzelne App beim Kompilieren in mehrere separate Archive zu packen und diese nach Bedarf unabhängig voneinander herunterzuladen.

Wir sollten dieses Problem wahrscheinlich in drei Fehler aufteilen, die wir separat verfolgen können.

Ist das für iOS wirklich machbar? Abgesehen von der Möglichkeit, dass Apple dies wie bei rollout.io verbietet , müsste das Javascript ohne jede Art von JIT laufen (kein Schreiben auf ausführbare Seiten auf iOS). Auch die unterschiedlichen GC-Eigenschaften des Javascript-Kerns, während Flutter Tonnen von kurzlebigen Objekten erzeugt, sind möglicherweise kein gutes Zeichen.

Was Apple derzeit (oder in Zukunft) erlaubt/nicht erlaubt, ist vollständig von den technischen Implementierungen getrennt. Flutter läuft an vielen anderen Orten als iOS. Natürlich möchten wir immer Technologien entwickeln, die auf iOS funktionieren (wie ich glaube, dass viele mögliche "Code-Push"-Lösungen dies könnten), aber iOS ist nicht die einzige Überlegung. Ich hoffe, das hilft?

Wirklich traurig, Code Push nicht in 1.0 veröffentlicht zu sehen. Wie andere ist dies der Hauptgrund, warum ich es nicht für Projekte verwenden kann, die die Möglichkeit zum Patchen benötigen, ohne auf die App Stores zu warten.
Ich weiß, dass es eine schwere Aufgabe ist, dorthin zu gelangen, viel Glück.

Es gibt nur einen Grund, uns von der Verwendung von Flutter abzuhalten: Code Push

Ich möchte mein Feedback hinterlassen, nur um mein Interesse an diesem Thema zu zeigen.
Mein Unternehmen entwickelt eine reine Android-App für mehrere Kunden, um Wartungsteams zu verwalten. Im Jahr 2018 haben wir ca. 100 Updates veröffentlicht, von denen keines eine neue Version über Google Play angefordert hat, da die meisten von ihnen kleine Optimierungen und Anpassungen sind, die jeder Kunde benötigt und die im Voraus nicht vorhersehbar sind.
Diese App in Flutter neu zu schreiben, wäre ein Traum, aber abgesehen von den Kosten für das Neuschreiben wäre es ein Albtraum, Geld zu verschwenden, um auf eine Fehlerbehebung oder Anpassungen zu warten, die über GPlay veröffentlicht werden.

Hoffe so schnell wie möglich zu erreichen

Ein weiterer Punkt: Wenn das Flutter-Team die Hotfix-Lösung offiziell zur Verfügung stellt, denke ich, dass Apple irgendwann alle von Flutter gebauten Apps ablehnen wird, da Hotfix die AppStore Review Guideline definitiv bricht, die Entwickler können die AppStore-Überprüfung umgehen und ihre app, ist es für Benutzer unsicher.

Aktuell lehnt Apple alle Apps mit JsPatch ab, was in China die beliebteste Hotfix-Lösung war. JsPatch baut auf JsCore und der OC-Laufzeit auf.

Ich möchte Flutter-Apps ohne Hotfix-Funktion bauen, anstatt Apps möglicherweise in Zukunft von Apple abzulehnen.

@MaxZeng Gut zu wissen über JsPatch. Aber im Moment scheint Hot Patching erlaubt zu sein. Es gibt viele React Native Apps im Apple Store und alle verwenden Hot Patching über CodePush.

Wenn nur iOS/Android unterstützt wird, wie in diesem Beispiel:
MyFlutterApplication bittet um Erlaubnis/will Ihre App aktualisieren
Changelogs: Kätzchen und Hunde hinzufügen (v1.0)
Erlauben | Nicht zulassen

nach Durchsicht der Richtlinien für beide Parteien.

@MaxZeng Gut zu wissen über JsPatch. Aber im Moment scheint Hot Patching erlaubt zu sein. Es gibt viele React Native Apps im Apple Store und alle verwenden Hot Patching über CodePush.

Ja, ReactNative ist vorerst eine Ausnahme von Code Push, aber das bedeutet nicht, dass Apple es offiziell unterstützt. Die App unseres Unternehmens wurde in letzter Zeit mehr als dreimal vom AppStore aufgrund eines RN-ähnlichen Frameworks abgelehnt, und wir müssen diese Funktionen von OC/H5 neu schreiben, es ist ein Albtraum für Entwickler.

React Native ist für Apple immer noch ein SICHERES Framework, da es schließlich auf UIKit gerendert wird, aber Flutter ist völlig anders:
1、Erstens bricht es die Entwickler-Ökosysteme von Apple, es umgeht das UIKit-Framework und liegt außerhalb der Kontrolle von Apple, zum Beispiel wird es immer mehr Apps im MD-Stil im AppStore geben, und dies könnte gegen die Human Interface Guideline von Apple verstoßen. Apple ist wegen seines großartigen Designs ein berühmtes Unternehmen.
2. Zweitens, wenn Hot-Reload offiziell von Flutter unterstützt wird, kann Apple diesen Grund nutzen, um Flutter Apps direkt abzulehnen.

Aus meiner Sicht sollte Flutter der AppStore Review Guideline folgen, anstatt sie zu brechen. Dies ist wichtig für ein plattformübergreifendes mobiles Framework, Sie sollten das Ökosystem von Apple nicht brechen, weil wir es können. Wenn Apple Flutter ablehnt, wird der entscheidende Vorteil von Flutter weg sein.

Der CodePush ist keine harte oder mysteriöse Technik, Apple kann ihn leicht implementieren (insbesondere basierend auf OC), der einzige Grund, warum Apples ihn nicht verbietet, ist, dass er für Endbenutzer unsicher ist, und dies schadet dem AppStore/Google Play vollständig. Es ist eine Katastrophe, wenn viele Apps ihre Funktionalität jederzeit und überall ändern können, und es ist schwierig, diese schädlichen Aktionen nach der Zulassung der App zu verfolgen und einzuschränken.

CodePush ist nicht nur eine Technik, sondern ein wichtiger Bestandteil der mobilen Ökosysteme. Ich denke, das Flutter-Team sollte eine solche Technik nicht offiziell zur Verfügung stellen, obwohl sie von einigen Entwicklern privat implementiert werden kann, dies ist in Ordnung, da sie nicht wild verwendet wird.

@MaxZeng Gut zu wissen über JsPatch. Aber im Moment scheint Hot Patching erlaubt zu sein. Es gibt viele React Native Apps im Apple Store und alle verwenden Hot Patching über CodePush.

Ja, ReactNative ist vorerst eine Ausnahme von Code Push, aber das bedeutet nicht, dass Apple es offiziell unterstützt. Die App unseres Unternehmens wurde in letzter Zeit mehr als dreimal vom AppStore aufgrund eines RN-ähnlichen Frameworks abgelehnt, und wir müssen diese Funktionen von OC/H5 neu schreiben, es ist ein Albtraum für Entwickler.

React Native ist für Apple immer noch ein _SAFE_ Framework, da es endlich auf UIKit gerendert wird, aber Flutter ist komplett anders:
1、Erstens bricht es die Entwickler-Ökosysteme von Apple, es umgeht das UIKit-Framework und liegt außerhalb der Kontrolle von Apple, zum Beispiel wird es immer mehr Apps im MD-Stil im AppStore geben, und dies könnte gegen die Human Interface Guideline von Apple verstoßen. Apple ist wegen seines großartigen Designs ein berühmtes Unternehmen.
2. Zweitens, wenn Hot-Reload offiziell von Flutter unterstützt wird, kann Apple diesen Grund nutzen, um Flutter Apps direkt abzulehnen.

Aus meiner Sicht sollte Flutter der AppStore Review Guideline folgen, anstatt sie zu brechen. Dies ist wichtig für ein plattformübergreifendes mobiles Framework, Sie sollten das Ökosystem von Apple nicht brechen, weil wir es können. Wenn Apple Flutter ablehnt, wird der entscheidende Vorteil von Flutter weg sein.

Der CodePush ist keine harte oder mysteriöse Technik, Apple kann ihn leicht implementieren (insbesondere basierend auf OC), der einzige Grund, warum Apples ihn nicht verbietet, ist, dass er für Endbenutzer unsicher ist, und dies schadet dem AppStore/Google Play vollständig. Es ist eine Katastrophe, wenn viele Apps ihre Funktionalität jederzeit und überall ändern können, und es ist schwierig, diese schädlichen Aktionen nach der Zulassung der App zu verfolgen und einzuschränken.

CodePush ist nicht nur eine Technik, sondern ein wichtiger Bestandteil der mobilen Ökosysteme. Ich denke, das Flutter-Team sollte eine solche Technik nicht offiziell zur Verfügung stellen, obwohl sie von einigen Entwicklern privat implementiert werden kann, dies ist in Ordnung, da sie nicht wild verwendet wird.

Sehr interessanter Punkt und klingt in gewisser Weise vernünftig, hat aber auch einige Fehler.

  1. Flutter unterstützt auch Apples Cupertino , MD ist nicht der einzige Auserwählte.
  2. Vielleicht kennen Sie die Unity im Gaming-Bereich, das Rendersystem von Flutter funktioniert in gewisser Weise ähnlich.
  3. Tatsächlich und vorerst kann die Verwendung des Webs (JS) CodePush implementieren und die Überprüfung des AppStores umgehen, um ihre App zu ändern. Warum also Flutter(dart) ablehnen und JS loslassen.

Warum also Flutter(dart) ablehnen und JS loslassen.

JS läuft in einer Sandbox und ist daher sicher. (wie jede geladene Webseite in Safari)

Dart kompiliert in Binärcode und ist nicht durch eine solche Sandbox eingeschränkt.

Ich bin seit vielen Jahren Android-Entwickler. Ich denke, Code-Push ist nicht so wichtig.
Wenn Sie ohne Code Push nicht entwickeln können? Wenn ja, ist das zu dumm.
Flutter ist ein Framework für Mobilgeräte, daher müssen Sie zunächst mehr Kenntnisse über das mobile Entwickeln lernen.
Ohne Code-Push können Sie Full-Update verwenden.
Wie es in der Anzeige heißt: Überqueren Sie die Brücke, wenn man dazu kommt.
Als Entwickler denke ich, dass es wichtiger ist, verschiedene Wege zu gehen, um dasselbe Problem zu lösen.


Flutter ist nicht React Native, Sie können die Erfahrung für React Native (oder ein anderes Framework) nicht verwenden, um Flutter zu betrachten. Das sind verschiedene Dinge.

@MaxZeng Vielleicht kann Flatter Hot Update exklusiv für Android aktivieren.

Ohne ein heißes Update wie RN werden wir nicht nach Flutter umziehen! Frameworks sollen einem Entwickler das Leben leichter machen!!

Die Blumen, auf die ich gewartet habe, sind alle weg.

@MaxZeng Vielleicht kann Flatter Hot Update exklusiv für Android aktivieren.

1、Eigentlich wird es auch die Ökosysteme des Google Play Store beschädigen, es wird es dem Android-Team erschweren, das Verhalten der App zu kontrollieren.
2、CodePush ist für die meisten Apps nicht erforderlich,Diese Technologie wird von einigen Entwicklern böswillig verwendet.
3、Es könnte einen großen „Man-in-the-Middle-Angriff“ verursachen, wenn Entwickler Patches nicht richtig verschlüsseln. Bösartige Hacker können Push-Code ändern, um Flutter-Apps zu kapern.

Ich möchte nur sagen, dass Hotfix für die meisten chinesischen Unternehmen eine Importfunktion ist. Mehr als 70 % chinesische Android-Geräte unterstützen Google Play nicht

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

In der Roadmap stand Hotfix auf Android. Hoffe, dass das iOS bald unterstützt wird.

@taibaiyinxing Flutter kann jedoch keine Funktionen bereitstellen, die von Apples App-Store nicht zugelassen sind.

@taibaiyinxing Flutter kann jedoch keine Funktionen bereitstellen, die von Apples App-Store nicht zugelassen sind.

@zoechi Wir verwenden eine Unternehmens-App und müssen nicht in den App-Store hochladen.

Dynamisches Patchen auf Android, sodass Code-Updates direkt von einem Server in Flutter-Anwendungen bereitgestellt werden können, die auf Android ausgeführt werden.
🎉

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

Es scheint, dass es in diesem Jahr keinen Plan gibt, CODE PUSH auf IOS zu unterstützen.

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

"Die Liste hier sollte weder als erschöpfend angesehen werden noch als Versprechen, dass wir all diese Arbeiten abschließen." :)

Die Code-Push-Arbeit befindet sich noch in relativ frühen Testtagen. Auf welchen Plattformen wir diese Funktion im Jahr 2019 einsetzen werden/werden, steht noch nicht fest. Es ist schließlich erst Februar. 10 Monate sind eine lange Zeit!

Derzeit konzentrieren sich die Ingenieure darauf, die Kerntechnologie aufzubauen , um die 3 Anwendungsfälle von https://github.com/flutter/flutter/issues/14330#issuecomment -442274897 . beschrieben sind
Ich gehe davon aus, dass wir in den kommenden Monaten mit einigen begrenzten Tests von mindestens einem dieser Anwendungsfälle beginnen werden.

Da unsere Flatter-Entwicklungstechnologie noch nicht sehr ausgereift ist, wird die APP häufig aktualisiert, und viele sind dringende Updates. Und unsere App plant nicht, einen App Store hochzuladen. Daher ist diese Funktion sehr wichtig. Dies kann die Iterationsgeschwindigkeit der APP verbessern. Andernfalls führt die Fragmentierung von APP zu einer Verzögerung unserer API.

Wie ich denke, sind wir uns alle einig, dass der Grund für dieses Problem darin besteht, dass die Bereitstellung einer mobilen App an Endbenutzer über die von Google und Apple (den Stores) verwalteten Walled Gardens eine große Unannehmlichkeit für App-Entwickler darstellt (ganz zu schweigen davon schlechter Service für Endbenutzer guter/innovativer Apps), wobei Apple am ungünstigsten ist (Tage für Apple im Gegensatz zu Stunden für Google).

Als Nebensache könnte eine mögliche Lösung darin bestehen, dass die Stores einen Weg für sofortige Updates für „vertrauenswürdige“ Entwickler bereitstellen (wie ein Fast-Track-Service). Google und Apple könnten dann ein Echtzeit-Audit (automatisiert,... wie bei KI??... mit Auto-Rollback post-facto, falls erforderlich) der App durchführen. Dies erscheint jedoch aus einer Reihe technischer und anderer Gründe unwahrscheinlich. Beide Stores haben natürlich einen Fast-Track zu Betatestern.

Während Sie also auf die Funktionen in dieser Ausgabe warten, besteht eine Möglichkeit, die Unannehmlichkeiten bei der Bereitstellung einer mobilen App an Endbenutzer zu verringern, darin, die Schritte zu automatisieren.

Ein Beispiel für ein Tool, das diese Art von Automatisierung für Flutter durchführt, finden Sie unter:
https://github.com/mmcc007/fledge
Für das Protokoll enthält es eine Dokumentation für viele der einmaligen Einrichtungsschritte, die nicht einfach automatisiert werden können:
https://mmcc007.github.io/fledge/

@charliezzo Mit diesem Tool oder ähnlichen Tools kann eine Flutter-App (und Updates usw.) innerhalb von Minuten an Android- und iOS-Betatester geliefert werden.

Es verfügt auch über einen Workflow, um die Lieferung an Endbenutzer über Stores zu automatisieren (Stunden+ für Google, Tage+ für Apple 😂👍).

@mmcc007
Oh danke. Aber ich sage, ich möchte meine App nicht in Google Play und den App Store verschieben.
Ich muss meine App anderweitig verkaufen.
und ich brauche Google Play und App Store nicht, um meine App zu aktualisieren.
Ich möchte meine App nur aktualisieren, wenn Benutzer sie installiert und gestartet haben.
und Flutter ist ein Framework mit 60 FPS oder höher, es kann ein Online-Spiel machen, wir möchten keinen kleinen Patch von Google Play und App Store haben.
Sie wissen, dass jeder Patch in kurzer Zeit von Google Play und App Store langsam und hart ist.
Tatsächlich wissen Sie, dass wir Google Play in China nicht verwenden können. und App Store ist sehr langsam.
Es gibt viele App-Stores wie Google Play in China. Wir haben keine Zeit, Updates in jeden App-Store zu übertragen.

Code Push sollte eine Hauptfunktion in Flutter sein. Legen Sie es oben.

Wir können es schaffen, indem wir alle Dateien in der app_flutters auf Android ersetzen

Hallo, können Sie mir Ihre E-Mail für weitere Diskussionen geben ? Unser Team hat diese Lösung auch gefunden? muss

Hallo, können Sie mir Ihre E-Mail zur weiteren Diskussion geben, unser Team hat diese Lösung auch gefunden, aber es kann nur funktionieren, wenn die Anwendung beendet und die App neu gestartet werden muss. tks @LNeway
@KinsomyJS
Ich habe auch eine Demo durchgeführt, um die Machbarkeit zu überprüfen

Bitte teilen Sie es mit einem kurzen Ausschnitt oder Blogbeitrag oder kommentieren Sie hier oder cc [email protected] in der E-Mail...

@LNeway @KinsomyJS Kann einer von euch bitte weitere Details nennen?
Vielen Dank

@taibaiyinxing Flutter kann jedoch keine Funktionen bereitstellen, die von Apples App-Store nicht zugelassen sind.

@zoechi Sagen Sie, dass Sie und/oder das Flutter-Team eine Analyse haben, die zu dem Schluss kommt, dass sich eine von Flutter durchführbare Codepush-Technik grundlegend von einer von React-native unterscheidet und verboten ist – und daher aufgrund von Apple möglicherweise nie auf das iPhone kommt?

Wenn diese Funktion hinzugefügt wird, wird sie dann Beta 1.0.0 unterstützen?

@dahabdev

Nach meiner Erfahrung mit Ionic glaube ich, dass "Code Push" überbewertet wird, und ich hoffe, dass das Flutter-Team nicht zu viel Zeit damit verbringt, daran zu arbeiten, während noch so viele andere, grundlegende, wesentliche Funktionen fehlen.

Als ich UAVForecast entwickelte, benutzte ich Ionic, angezogen von der "ionic Deployment"-Funktion, die anbot, den gesamten Inhalt der App aus der Ferne zu aktualisieren. Damals (das war 2014) lagen die Review-Zeiten im App Store von Apple in der Größenordnung von 2 Wochen. Ich wollte schnell iterieren, schnell vorankommen und Dinge kaputt machen, wie sie sagen.

Anfangs war "ionischer Einsatz" großartig, aber bald bemerkte ich einige größere Probleme. Es verursachte Verwirrung bei meinen Benutzern ("die App sagt, sie habe sich selbst aktualisiert, warum steht also ein weiteres Update im Play Store / App Store aus?"); es hat die App manchmal kaputt gemacht, zB wenn App-Metadaten (zB Berechtigungen) von einem Cordova-Plugin im Hintergrund geändert wurden, aber nicht durch einen Hot-Code-Push aktualisiert wurden; Versionsnummern zu verfolgen war schwierig, und sie wurden nicht mehr synchron mit dem, was ich in die Läden geschoben hatte; es machte mich beim Testen faul, da ich mich immer selbst aus Fehlern "ionisch einsetzen" konnte; und manchmal habe ich schlimmere Bugs gepusht, die vielleicht von den App-Review-Teams entdeckt worden wären, wenn ich ihnen die Chance gegeben hätte, nachzusehen.

Ungefähr ein Jahr nachdem ich die erste Version veröffentlicht hatte, hatten sich die Überprüfungszeiten im App Store erheblich verbessert. Heute sind es nur noch wenige Tage, und im Google Play Store können es natürlich nur wenige Stunden sein. Angesichts all der Probleme, die ich hatte, beschloss ich, die "ionische Bereitstellung"-Funktion aus meiner App zu entfernen, und mit mehreren Millionen Downloads jetzt hinter mir habe ich nicht zurückgeschaut.

Während ich Ionic mag und wirklich alles schätze, was sein Entwickler Drifty getan hat (danke!), würde ich argumentieren, dass Drifty den Fehler gemacht hat, zu viel Zeit in glänzende Funktionen wie Code-Push zu investieren, die Benutzer anziehen, und nicht genug Zeit, um sie zu bekommen die Schrauben und Muttern des Rahmens richtig, um Probleme zu vermeiden, die sie am Ende vertreiben. Jetzt in seiner vierten Version wurde Ionic so oft in abwärtskompatibler Weise neu geschrieben, dass ich aufgehört habe, Schritt zu halten - die neueste Version hat noch einige schwerwiegende Probleme, die ein Upgrade verhindern, und ich schreibe jetzt meine gesamte App neu in Flattern.

Die bisherigen Erfahrungen waren ausgezeichnet und es macht mir viel Spaß, aber es gibt immer noch einige große Lücken und Auslassungen in Flutter, insbesondere in den Plugins. Zum Beispiel: Es gibt keine Textfeldintegration mit Passwort-Autofill, das Google Maps-Plugin ist Barebones (und es gibt verwandte Framework-Rendering-Fehler), das native WebView unterstützt keine file://-URLs zum Laden von Assets, die Tab-Leiste nicht unterstützt Transparenz oder Verlaufshintergründe, Tabellenzellen unterstützen Colspan nicht, ThemeData ist nicht erweiterbar mit App-spezifischen Farben zur Verwendung mit Animationen, der einzigen vollständig zeitzonenbewussten DateTime-Bibliothek fehlen viele wichtige Funktionen von Moment und Moment-Timezone so viele Ansätze zur Staatsverwaltung, dass es für Neulinge verwirrend ist, man muss häufig "flattern", um seltsame Ausnahmen zu vermeiden, Hot-Swap funktioniert oft nicht so, wie es sollte, und ich könnte weitermachen ...

Ich würde _alle_ wichtiger als "Code Push" einstufen, insbesondere wenn es riskiert, dass Apple Flutter-Apps ablehnt, wenn es größere Änderungen am Compiler-Framework erfordert, die schließlich Optimierungen zur Verbesserung der App-Leistung erschweren könnten (ich würde a 5 % Leistungssteigerung gegenüber "Code-Push" an jedem Tag) oder es dauert einige Zeit, bis die Framework-Funktion vollständig ist.

Auf der anderen Seite kann ich sehen, dass einige Entwickler es in manchen Situationen wirklich brauchen, insbesondere wenn sie außerhalb der Geschäfte arbeiten, daher kann ich die Begeisterung hier verstehen.

@matthewlloyd viele tolle Punkte!

Wenn Sie Code Push nicht unterstützen können, gibt es eine Möglichkeit, einen Parser zu erstellen, der aus einigen Wörterbüchern (wie json, xml ...) zu Flutter Widget generiert? Ist das unmöglich oder eine gute Idee?

--Hat jemand eine Meinung dazu?
https://pub.dartlang.org/packages/dynamic_widget
es scheint vielversprechend zu sein, obwohl es die Angst vor einem „kritischen Fehler“ nicht anspricht.

Das Verrückte daran ist, dass Code-Push der Elefant im Raum ist, das ist zutiefst ein Geschäfts-/Prozessproblem und ein technisches, und eine Seite neigt dazu, die andere zu ignorieren ...

es gibt keine Textfeldintegration mit Passwort-Autofill, das Google Maps-Plugin ist Barebones (und es gibt verwandte Framework-Rendering-Fehler), das native WebView unterstützt keine file://-URLs zum Laden von Assets, die Tab-Leiste unterstützt keine Transparenz oder Verlaufshintergründe, Tabellenzellen unterstützen Colspan nicht, ThemeData ist nicht mit App-spezifischen Farben zur Verwendung mit Animation erweiterbar, der einzigen vollständig zeitzonenbewussten DateTime-Bibliothek fehlen viele wichtige Funktionen von Moment und Moment-Timezone, es gibt so viele Ansätze Für die Staatsführung ist es für Neulinge verwirrend, man muss häufig "reinflattern", um seltsame Ausnahmen zu vermeiden, Hot-Swap funktioniert oft nicht so, wie es sollte, und ich könnte weitermachen...

Hoffentlich haben all diese bereits ein Github-Problem :D

Dies stand zuvor auf unserer Roadmap für 2019. Nachdem wir dies genauer untersucht haben, haben wir uns entschieden, diese Arbeit vorerst nicht fortzusetzen.

Mehrere Faktoren haben uns zu dieser Entscheidung geführt:

  • Um unserem Verständnis von Store-Richtlinien für Android und iOS zu entsprechen, wäre jede Lösung auf JIT-Code auf Android und interpretierten Code auf iOS beschränkt. Wir sind nicht zuversichtlich, dass die Leistungsmerkmale einer solchen Lösung auf iOS die Qualität erreichen, die wir von unserem Produkt erwarten. (Mit anderen Worten, "es wäre zu langsam".)

  • Es gibt einige ernsthafte Sicherheitsbedenken. Da diese Patches im Wesentlichen die Ausführung willkürlichen Codes ermöglichen würden, wären sie äußerst attraktive Malware-Vektoren. Wir könnten dies abmildern, indem wir verlangen, dass Patches mit demselben Schlüssel wie das Originalpaket signiert werden, aber dies ist fehleranfällig und jeder Fehler hätte schwerwiegende Folgen. Dies ist im Grunde das gleiche Problem, von dem Plattformen geplagt wurden, die die Ausführung von Code aus Quellen von Drittanbietern ermöglichen. Dieses Problem könnte durch die Integration mit einem Plattformaktualisierungsmechanismus gemildert werden, aber dies verfehlt den Zweck eines Out-of-Band-Patching-Mechanismus.

  • Derzeit gibt es keine Out-of-the-Box-Open-Source-Hosting-Lösung zum Patchen von Anwendungen, daher müssten wir uns entweder darauf verlassen, dass die Leute ihre Webserver entsprechend konfigurieren, oder wir müssten Integrationen für proprietäre Drittanbieterdienste erstellen, oder wir müssten wir unsere eigene maßgeschneiderte Lösung erstellen. Das Hosten von Patches ist ein Bereich, den wir nicht betreten möchten. Wenn Benutzer ihren eigenen Server konfigurieren, können sie Fehler machen, die möglicherweise schwerwiegende Folgen haben, wie im vorherigen Punkt zur Sicherheit erläutert. Die Abhängigkeit von Drittanbieterdiensten bringt Flutter in die schwierige Position, Gewinner auswählen zu müssen, und setzt uns dem Risiko aus, dass diese Projekte selbst Richtlinienänderungen vornehmen, die sich auf diese Funktion auswirken würden.

Wir verwenden unsere Engineering-Leistungen vorerst lieber für andere Themen. Wir gehen davon aus, dass wir in diesem Bereich weiter experimentieren werden und werden dies wahrscheinlich in Zukunft wieder ernst nehmen (zB werden wir wahrscheinlich eine Update-Lösung für Desktop-Anwendungen brauchen), aber wahrscheinlich nicht in diesem Jahr.

Obwohl ich den Grund für die Einstellung dieser Funktion verstehe, ist sie immer noch enttäuschend. Der Play Store und der App Store sind wichtige Überlegungen, aber nicht jede App wird auf diese Weise verbreitet. Für unseren Anwendungsfall liefern wir dem Kunden sowohl das Gerät als auch die App vorinstalliert. Ein Mechanismus zum dynamischen Pushen von Updates an den Benutzer ist ein sehr wichtiges Feature, da wir nicht durch die Stores gehen möchten. Diese Funktion wäre von unschätzbarem Wert gewesen. Ich hoffe, es wird in Zukunft, wie von Ihnen erwähnt, wiederholt.

Vielen Dank für die transparente Kommunikation der Gründe des Teams.

@eseidelGoogle Wird der von Dart kompilierte JavaScript-Code

Das ist ziemlich enttäuschend.

Alle von Ihnen erwähnten Sicherheits- und Speicher-Compliance-Probleme mögen gültig und legitim sein, aber am Ende des Tages gibt es ein Beispiel für "Hot-Updates"-Technologie, die bereits funktioniert: Code-Push.

React Native + der Code-Push-Dienst funktioniert und hat sich in der Praxis bewährt. Es ist kampferprobt. Bei den App Stores scheint es keine Probleme mit den indirekten Updates zu geben. Es scheint, dass alle damit "ok" sind. Daher denke ich, dass auch Flutters Lösung zulässig sein könnte.

In Bezug auf die Leistungsprobleme kann es eine gute Idee sein, dem Entwickler die Wahl zu lassen, im Modus "Low Performance" zu arbeiten, aber Live-Updates zu aktivieren.

Ein guter Schachzug! Mir ist es lieber, den technischen Aufwand in die Optimierung von Flutter zu investieren, als eine Code-Push-Funktion hinzuzufügen, die das Ökosystem übermäßig verkomplizieren und schädigen kann

Ich habe derzeit meine allererste App, die in Flutter entwickelt wurde, im offenen Beta-Test und ich habe etwa 10 App-Bundles mit Fixes herumgeschubst. Aber es sollte weitestgehend fehlerfrei sein, wenn ich es für die Produktion freigebe.

Ich weiß also nicht, ob ich diese Funktion jemals brauchen werde, aber ich habe dieses Pub-Paket- OTA-Update gefunden , das mit der Punktzahl von 89 gut

Wer diese Funktion unbedingt benötigt, kann dieses Paket ausprobieren.

Aber ich kann verstehen, warum das Flutter-Team davon nicht allzu begeistert ist, denn nehmen wir das obige Paket für den Fall. Es scheint von einer URL herunterzuladen. Und eine Website ist immer hackerfreundlicher als native Apps. Derzeit gibt es zu viele Sicherheitsbedenken. Es macht eine Flutter-App nur so anfällig wie eine Website, was ein striktes No-Go ist.

Als ich anfing, hatte ich eine Maschine mit 2 GB RAM und versuchte, eine Android-App zu entwickeln, wie ich es immer wollte, aber meine Maschine war der Aufgabe nicht gewachsen. Ich habe PhoneGap, Cordova, einige Intel-Frameworks, React-Native ausprobiert, und keiner von ihnen hat angefangen zu laufen. Flutter war der einzige, mit dem ich tatsächlich angefangen habe, und mit seiner schönen Benutzeroberfläche und seinen Entwicklungstools ist es seinen Zeitgenossen auch ohne dieses Feature meilenweit voraus.

Irgendein Update?

Der App-Release-Workflow wird nie mehr derselbe sein, nachdem uns React-Native mit Code Push verwöhnt hat. Schade, dass Flutter das nicht unterstützt. Flutter entwickelt sich gut und es hätte ein Konkurrent von React Native sein können, wenn sie sich dafür entschieden hätten, diese Funktion zu unterstützen. Ach...

@Hixie OK, eine grundlegende technische/technische Änderung hat im

Wie auch immer - wie halten Sie es, kurz- und mittelfristig mit einigen alternativen Ansätzen, die eine Dokumentation/Diskussion erhalten, flatternden Entwicklern zu helfen, die ein geschäftliches Anliegen haben - vielleicht sogar Videos, obwohl vielleicht keine "befürwortete" oder offizielle Lösung, aber etwas Aufmerksamkeit.

z.B

  • Firebase-Echtzeitkonfiguration
  • Server baased json->widgets (zB https://github.com/dengyin2000/dynamic_widget/blob/master/WIDGETS.md oder ähnlich, ich befürworte noch nicht das genaue Plugin, aber die Idee)
  • oder vielleicht etwas anderes, vielleicht Cloud-Funktionen für fortgeschrittene Benutzer...
  • Natürlich schlage ich nicht vor, dass Sie für einen "großen" Anwendungsfall einen Haufen Engineering-Aufwand aufwenden, sondern eine Art Hallo-Welt-Code-Push-Alternative, die den größten Teil der Anforderungen erfüllt, ohne dass wir jedes einzelne Ding reparieren / ändern müssen ' Typ Architektur.

meine Prämisse ist, dass "wir" 70-90% der Bedenken bezüglich Codepush erfüllen können, ohne dass eine grundlegende Architekturänderung für Flattern erforderlich ist; was hält jemand davon?

Der Code-as-ui-Ansatz von Flutter könnte dies sogar einfacher machen als für Android-Entwickler....

Ich habe persönlich mindestens zwei Unternehmen gesehen, die sich aus diesem Grund für die anderen Jungs entschieden haben, und viele andere haben sich ähnlich geäußert.

Vielleicht könnte das Gespräch gehen
"Benutzer: Überspringst du die Codepush-Unterstützung"
„Flatter-Team: Ja – vorerst aus diesen Gründen (wie Sie), aber zusätzlich könnten Sie A oder B für einige Anwendungsfälle ausprobieren.“

Entschuldigung für den langen Kommentar

@neiljaywarner Vielleicht ist LUA für dich einen Blick wert - ich habe letztes Jahr einen Proof of Concept gemacht, bei dem LUA-Skripte zum Erstellen / Anpassen der Funktionalität einer Flutter-App verwendet werden könnten.

@neiljaywarner Ich bin alle für diese Art von Ansatz, aber das ist ein orthogonales Anliegen als das, was dieser Fehler abdeckt.

Obwohl ich die Gründe für das Aufgeben dieser Funktion verstehe, ist es immer noch enttäuschend. Der Play Store und der App Store sind wichtige Überlegungen, aber nicht jede App wird auf diese Weise verbreitet. Für unsere Anwendungsfälle stellen wir Kunden vorinstallierte Geräte und Anwendungen zur Verfügung. Ein Mechanismus zum dynamischen Pushen von Updates an Benutzer ist eine sehr wichtige Funktion, da wir nicht durch den Store gehen möchten. Diese Funktion ist sehr wertvoll. Ich hoffe, es in Zukunft, wie von Ihnen erwähnt, erneut überprüfen zu können.

Vielen Dank, dass Sie die Rationalität des Teams transparent kommunizieren.

Ich stimme zu

Code-Push-Funktionalität bedeutet mehr Apps, mehr Clients, mehr Entwickler, mehr Tests, mehr Fehlerbehebungen, weniger Probleme

Für den MVP eines Startups oder wachsende Anwendungen sind die Updates oder Fehlerbehebungen entscheidend, während die Leistung die meiste Zeit weniger besorgniserregend ist. Dies wird Vor- und Nachteile für das Flutter-Ökosystem haben. Der Rückgang der Akzeptanz, von Startups und persönlichen Entwicklern ist wichtig für das Wachstum der Community im Frühstadium. Die Vorteile könnten die qualitativ hochwertigen Apps und Teams sein, die zu Flutter wechseln würden, die eine höhere Leistung anstreben?

@maplerichie , hier

Wir brauchen diese Funktion sehr
Brauche ein heißes Update

Wie andere bereits erwähnt haben, benötigen große Unternehmen und große Entwicklerteams möglicherweise keine heißen Updates. Aber stellen Sie sich ein kleines Startup vor, ein paar Entwickler, die an einer mobilen App arbeiten und Funktionen mit schnellen Release-Zyklen für die Produktion bereitstellen. Für Tests und QS-Zyklen bleibt keine Zeit. Erstellen Sie eine neue Funktion, prüfen Sie, ob sie funktioniert und den Benutzern gefällt, ersetzen oder reparieren Sie sie. Ohne heiße Updates könnten wir nicht dorthin gelangen, wo wir sind. Es ist ein echter Game Changer für die mobile Entwicklung.

@yaronlevi Ich bin ein "kleines Startup", sogar weniger als ein paar Entwickler, die an einer mobilen App arbeiten, es bin nur ich, und ich liefere mit schnellen Release-Zyklen an die Produktion. Da der Google Play Store Updates anbietet, die nur wenige Stunden dauern, und der Apple App Store, der Updates nach meiner Erfahrung heutzutage fast immer in weniger als 24 Stunden überprüft, brauche ich definitiv keinen Code-Push. Wenn Flutter Code-Push hätte, würde ich aktiv Schritte unternehmen, um sicherzustellen, dass er in meiner App deaktiviert ist.

Ich bin derzeit alleiniger Entwickler einer mobilen App (und des passenden Backends) für ein kleines Unternehmen. Ich liebe Flutter wirklich, aber ich muss einem Kunden, der die Notwendigkeit von Unit-Tests oder Automatisierungstests nicht versteht, ständig erklären, warum es so lange dauert, Funktionalitäten zu implementieren, die in 10 Worten beschrieben werden können. Ich mache mir ein wenig Sorgen, etwas Halbfertiges veröffentlichen zu müssen und nicht in der Lage zu sein, kritische Fehlerkorrekturen schnell voranzutreiben. Ich werde vorerst darauf verzichten, aber Code-Push wäre definitiv schön zu haben. Ich verstehe jedoch die technischen Herausforderungen und Sicherheitsbedenken und unterstütze letztendlich einen umsichtigen Ansatz.

naja danke trotzdem.
Ich denke, wir müssen es selbst herausfinden.

echt enttäuschend :)

Flutter für das Web-SDK wird in Kürze mit dem Mobile-SDK zusammengeführt. Eine Problemumgehung besteht darin, einen mobilen WebView zum Laden von Flattercode zu verwenden. 😁

@matthewlloyd Hallo Mann, es ist notwendig, Hot-Updates zu unterstützen, der Punkt ist nicht die Zeit für die Überprüfung. Der Benutzer muss mit dem AppStore verbunden sein und die App erneut herunterladen.

Ich sehe kein dringendes Problem darin, keinen Code-Push zu haben. Fast alle Benutzer haben die automatische Aktualisierung in ihrem App Store aktiviert. Es wäre jedoch schön, eine alternative Lösung für die Verteilung von Updates ohne App Store bereitzustellen.

MXFlutter verwendet JavaScript, um die Rendering-Funktionen von Flutter zu implementieren, unterstützt die Flutter-Syntax und unterstützt Code-Push und Hot-Update.
https://github.com/TGIF-iMatrix/MXFlutter

@TGIF-iMatrix wissen Sie, ob diese Lösung den Vertriebsrichtlinien des Stores entspricht?

@truongsinh
Es ist sicher, da es sich um eine js-Distribution -> nativer Parser -> Widgets erstellen-Ansatz handelt.

Wir ziehen die Verwendung von Flatter in Betracht, wenn es Code-Push unterstützt

@TGIF-iMatrix Es ist sehr wahrscheinlich, dass dies von Apple nicht genehmigt wird, da die Ausnahme für Javascript Core-Updates aus den App Store-Vereinbarungen gestrichen wurde und viele CodePush-Benutzer aufgrund dieser Funktion gewarnt / abgelehnt wurden.

Vielleicht sollten wir die Frage umformulieren, "sever-dictated-rendering" vs "code push". Bei "sever-dictated-rendering" geht es nur um unterschiedliche Benutzeroberflächen/Layouts/Themen, während Code-Push auch Änderungen in Logik, Berechtigungen, Plugins usw. impliziert.

Vielleicht können Sie zu diesem Zeitpunkt jedoch einfach ein Plug-in verwenden, um dies zu tun, sodass der Zweck dieses Problems irgendwie zunichte gemacht wird.

Hat jemand Tinker-Lib mit Flatter ausprobiert, die aus Tencent Github Repo stammt, und Erfolg damit, wenn jemand daran interessiert ist, kann ich mit Ihnen zusammenarbeiten. jar-Artefaktdatei

Hoffe so schnell wie möglich eine Lösung zu haben

Wäre das Kompilieren von Dart-Code in WebAssembly in Bezug auf die Leistungsauswirkungen der Implementierung von Code-Push hilfreich? Dies kann die Implementierung der JIT-Kompilierung in iOS innerhalb der JavaScript-Sandbox ermöglichen.

wir brauchen schnelle Iteration und agile Entwicklung.
Wenn kein heißes Update, Flutter ist immer ein jüngerer Bruder für Reagieren native.

Hot Update ist für uns sehr wichtig. Wenn Flatter Hot Update unterstützt, verwenden wir Flatter, um React native zu ersetzen.

Ich hatte einen bestmöglichen Weg für Code-Push geplant, aber aus Zeitgründen kann ich dieses Projekt erst ab November letzter Woche oder ab Dezember starten, ich ändere keinen Engine- oder Framework-Code oder Java-Code wie Tinker lib, damit es nicht verletzt wird Alle Store-Begriffe, Ausgabe-App ist auch aot, also keine Leistungsregression, ich versuche, die Implementierung so einfach zu gestalten, dass jeder in seine App ein Plugin erstellen kann habe alle möglichkeiten mit der aktuellen implementierung ausprobiert und bin zu dem schluss gekommen, dass nur mögliche wege entweder motormodifikationen vornehmen oder eine lösung ohne motormodifikation vorbereiten müssen, ich gehe für die 2. option und plane alle notwendigen anforderungen für das projekt. Ich hoffe, das Projekt wird erfolgreich sein. Wenn das Flutter-Team das Problem in der Zwischenzeit neu bewertet, sind wir alle mit der integrierten Implementierung zufrieden.

Hot Update wird immer benötigt!

Dies ist ein Muss, eine entscheidende Funktion

Ich hatte einen bestmöglichen Weg für Code-Push geplant, aber aus Zeitgründen kann ich dieses Projekt erst ab November letzter Woche oder ab Dezember starten, ich ändere keinen Engine- oder Framework-Code oder Java-Code wie Tinker lib, damit es nicht verletzt wird Alle Store-Begriffe, Ausgabe-App ist auch aot, also keine Leistungsregression, ich versuche, die Implementierung so einfach zu gestalten, dass jeder in seine App ein Plugin erstellen kann habe alle möglichkeiten mit der aktuellen implementierung ausprobiert und bin zu dem schluss gekommen, dass nur mögliche wege entweder motormodifikationen vornehmen oder eine lösung ohne motormodifikation vorbereiten müssen, ich gehe für die 2. option und plane alle notwendigen anforderungen für das projekt. Ich hoffe, das Projekt wird erfolgreich sein. Wenn das Flutter-Team das Problem in der Zwischenzeit neu bewertet, sind wir alle mit der integrierten Implementierung zufrieden.

Ich hatte einen bestmöglichen Weg für Code-Push geplant, aber aus Zeitgründen kann ich dieses Projekt erst ab November letzter Woche oder ab Dezember starten, ich ändere keinen Engine- oder Framework-Code oder Java-Code wie Tinker lib, damit es nicht verletzt wird Alle Store-Begriffe, Ausgabe-App ist auch aot, also keine Leistungsregression, ich versuche, die Implementierung so einfach zu gestalten, dass jeder in seine App ein Plugin erstellen kann habe alle möglichkeiten mit der aktuellen implementierung ausprobiert und bin zu dem schluss gekommen, dass nur mögliche wege entweder motormodifikationen vornehmen oder eine lösung ohne motormodifikation vorbereiten müssen, ich gehe für die 2. option und plane alle notwendigen anforderungen für das projekt. Ich hoffe, das Projekt wird erfolgreich sein. Wenn das Flutter-Team das Problem in der Zwischenzeit neu bewertet, sind wir alle mit der integrierten Implementierung zufrieden.

Hallo @canewsin
Ich habe auch versucht, das Gleiche zu tun, indem ich den Flattermotor nicht modifiziert habe. Ich habe herausgefunden, dass die Engine im AOT-Modus nach den .so-Dateien im nativen Bibliothekspfad von Android sucht und dort eine Datei ändert/hinzufügt, nachdem die Kompilierung der Anwendung durch JVM eingeschränkt ist. Daher konnte das Laden von .so-Dateien, die drahtlos heruntergeladen wurden, nicht zum nativen Bibliothekspfad hinzugefügt werden.

Warte auf weitere Erkenntnisse von dir. 😀

Ich denke, es ist nicht erforderlich, sowohl den Dart-Code als auch den nativen Code zu aktualisieren.
Nur Dartcode ist in Ordnung!

Hey, das brauche ich jetzt. Goodle hat seine Bewertungsrichtlinien verschärft. Unsere App braucht jetzt 2 Wochen, um zu aktualisieren ... Unsere schlanke Methodik geht damit scheiße.

@NEELANSHSETHI kannst du den Plan hier posten? Wir können mit der Umsetzung beginnen

@almeynman Bitte halte uns über deine Fortschritte auf dem Laufenden :)

@HerrNiklasRaab Ich habe damit noch nicht begonnen, da ich kein klares Bild zur Umsetzung habe. Wenn jemand eine Idee hat, bitte teilen Sie Ihre Gedanken mit

Das ist der Hauptgrund, warum wir nicht vom Reaktiven zum Flattern übergegangen sind. :(

😔

ReactNative ist aufgrund dieser Funktion Flutter weit voraus und ich hatte viele Projekte, bei denen die Wahl der Umgebung (RN oder Flutter) im Vergleich zur Push-Code-Funktion dekodiert wurde! Warte auf eine Nachricht :/

Hallo zusammen, es ist schon November, wie gesagt, ich habe meine Arbeit begonnen, es läuft gut. Es wird ein privates Projekt sein, also werde ich einen Lizenzschlüssel berechnen, um es zu verwenden. Es wird also nicht kostenlos sein, da ich keine Einkommensquelle habe, muss ich auf diese Weise tun. Wenn Sie interessiert sind, werde ich ein Follow-up-Repository über die Arbeit erstellen, folgen Sie diesem für Updates. Sobald ich das Timeline-Repo erstellt habe, werde ich euch informieren.

@eseidelGoogle
Geschäftsfall:
Wir haben eine Busverfolgungs-App auf Tablets, aber der Kunde aktualisiert 1 Mal im Monat, da das Tablet Internetdaten und kein WLAN verwendet
Mit Code Push werden wir in der Lage sein zu aktualisieren, ohne die Kundendaten zu sehr zu verbrauchen

Wir hatten die Cordova-App mit Code-Push-Unterstützung. Als es darum ging, die App zu modernisieren, dachten wir fälschlicherweise, dass flatter Code-Push-Unterstützung "sowieso" hinzufügen würde, also haben wir unsere App mit Flatter entwickelt. Aber das Leben ohne Code-Push war für uns im letzten Jahr total schrecklich. Wir sind also endlich (und glücklich) dabei, die App (neu) in Reactive-Native neu zu schreiben, damit unser Code wieder unterstützt wird.

Code Push, deshalb lerne ich jetzt React-Native.

Bei Interesse an meiner Umsetzung
Fortschrittsbericht hier verfolgen
https://github.com/canewsin/flatter-code-push-timeline
Bitte lesen Sie alle meine Kommentare oben, bevor Sie fortfahren.

Code Push, deshalb bleibe ich weiterhin bei React-Native.

Bitte posten Sie keine nicht konstruktiven Beiträge, +1, "Wir brauchen das", "Wir verwenden stattdessen X" usw., da dies nicht konstruktiv ist und nicht zur Diskussion beiträgt.

Sie werden einen viel besseren Einfluss haben, wenn Sie beim ersten Beitrag auf die Schaltfläche "Daumen hoch" ( 👍 ) klicken, ohne dass alle, die jemals in dieser Diskussion gepostet haben, darüber informiert werden (soweit ich weiß, werden einige Mitglieder des Flatter-Teams stumm schalten große Threads, daher hat das Posten hier weniger Wirkung als ein Daumen hoch).

Ich möchte auch alle hier abonnierten daran erinnern, dass github oben rechts im Thread einen unsubscribe Button hat.

Außerdem priorisiert das Flutter-Team Probleme basierend auf der Anzahl der Daumen hoch, so dass es eine große Sache sein kann, diesen Zähler hoch zu bekommen. Das und nur ein Klick auf "Abonnieren" genügt.

Code Push - Projekt i nahm geht gut , aber ich möchte einige Beispiele für Anforderungen von Code Push, also wenn Code Push abgeschlossen Wie verwenden Sie es in diesem Ihre einzigartige Anforderung als neuen Eintrag Repo https://github.com/ canewsin/flatter-code-push-timeline, damit die Entwicklung auf dem richtigen Weg ist.
Einschränkungen die ich bisher gefunden habe sind:
Wir können nicht auf die native Plattform zugreifen, dies kann jedoch über die FFI-Funktionalität erfolgen.
Codepush-Code wird aus Sicherheitsgründen in einer Sandbox ausgeführt, sodass dem Gerät kein Schaden zugefügt werden kann.

Hallo zusammen, es ist schon November, wie gesagt, ich habe meine Arbeit begonnen, es läuft gut. Es wird ein privates Projekt sein, also werde ich einen Lizenzschlüssel berechnen, um es zu verwenden. Es wird also nicht kostenlos sein, da ich keine Einkommensquelle habe, muss ich auf diese Weise tun. Wenn Sie interessiert sind, werde ich ein Follow-up-Repository über die Arbeit erstellen, folgen Sie diesem für Updates. Sobald ich das Timeline-Repo erstellt habe, werde ich euch informieren.

Sehr interessant!
Hallo, hast du schon Beispiele? Und wie gehen Sie mit dem iOS-Bereich um? da Apple in diesem Bereich sehr streng. Vielen Dank

Hallo zusammen, es ist schon November, wie gesagt, ich habe meine Arbeit begonnen, es läuft gut. Es wird ein privates Projekt sein, also werde ich einen Lizenzschlüssel berechnen, um es zu verwenden. Es wird also nicht kostenlos sein, da ich keine Einkommensquelle habe, muss ich auf diese Weise tun. Wenn Sie interessiert sind, werde ich ein Follow-up-Repository über die Arbeit erstellen, folgen Sie diesem für Updates. Sobald ich das Timeline-Repo erstellt habe, werde ich euch informieren.

Sehr interessant!
Hallo, hast du schon Beispiele? Und wie gehen Sie mit dem iOS-Bereich um? da Apple in diesem Bereich sehr streng. Vielen Dank

arbeitet derzeit mit der Android-Seite, obwohl die iOS-Seite dumm ist, ähnlich der Sandbox-Version von reaktiven js-Apps, wird der Code in der Sandbox ausgeführt, ohne auf die Plattform-APIs zuzugreifen, sodass dies möglicherweise nicht das Problem ist, wenn er für die iOS-Seite bereit ist.

Hallo @eseidelGoogle
Irgendwelche Updates? Zeitleiste?

Hallo @eseidelGoogle
Irgendwelche Updates? Es ist Dezember, ist ein Feature, das 2019 veröffentlicht wird?

@Hixie Ich habe deinen Artikel auf Reddit gelesen
https://www.reddit.com/r/FlutterDev/comments/d51o4w/were_the_flutter_team_at_google_ask_us_anything/f0ium5w/?utm_source=share&utm_medium=web2

Ich frage mich, ob Flutter-App-Updates klein sind, wenn ich sie als abb "Android App Bundle" in Google Play veröffentliche oder nur für nativen Code?

Dies ist eine wichtige Funktion für Enterprise-Builds (Apps, die außerhalb von Stores vertrieben werden, beispielsweise über Webportale).

Es ist eine sehr erforderliche Funktion. Warum können wir es nicht offiziell haben? Was hindert es daran, diese Funktion bereitzustellen?

Ist das der Fahrplan für 2020?

Nein

2020 und warte immer noch

Bitte lesen Sie dies, bevor Sie unten posten.

Hier ist eine kurze Zusammenfassung, wenn Sie nicht nach oben scrollen möchten, um es zu verstehen:

Wie in diesem Kommentar hervorgehoben wurde , sind die drei großen Herausforderungen:

  • Was wird geschoben
  • Ist es sicher für Benutzer?
  • Von wo es geschoben wird

Bei der ersten Frage, _was_ gepusht wird, liegt das größte Problem. Die Überprüfungsrichtlinien von Apple verbieten jegliche Art von Code-Push . Ja, die verwendete Terminologie _schließt auch JavaScript-Code-Push ein._ Apple hat anscheinend nichts dagegen unternommen, und dafür kann es viele Gründe geben, aber alle hier veröffentlichten Gründe wären reine Spekulation.

Googles eigene Play Store-Richtlinien verbieten auch das Herunterladen von kompiliertem Code , obwohl es heißt, dass Sie keinen _ausführbaren Code_ herunterladen können, heißt es ausdrücklich "Dex-Dateien oder nativer Code", sodass Javascript möglicherweise sicher ist, und auch reine Dart-Quellen.

Flutter ist, zumindest im Release-Modus, kompiliert , und selbst wenn dies nicht der Fall war, ist es kein Javascript , daher kann es unter iOS nicht interpretiert werden, ohne die Anforderung "no JIT" zu verletzen oder sehr langsam zu sein.

Die zweite, für Benutzer _sicher_, ist so ziemlich der gesamte Grund für die Logik der Stores, dynamische, ungeprüfte Code-Downloads zu verbieten. Jedem zu erlauben, etwas von überall herunterzuladen und es _nur auszuführen_, gefährdet die Benutzer. Selbst innerhalb einer Sandbox, in der die besonderen Privilegien von JavascriptCore für Code-Push hervorgehoben werden, ist es immer noch nicht sicher.

Code Push ermöglicht es Ihnen, den Überprüfungsprozess der Stores zu umgehen, was bedeutet, dass ungeprüfter Code h auf den Geräten der Benutzer ausgeführt wird, was bedeutet, dass es möglich ist , entweder die Original-App falsch darzustellen oder sogar schädliche Funktionen wie Datenableitung oder Exploits hinzuzufügen , die der Verifizierungsprozess hätte erwischt .

Sie können die besten Absichten der Welt haben, es wird immer jemanden geben, der Sie hinterhält.

Wenn Sie auf Android derzeit nicht den Play Store zum Verteilen verwenden, können Sie einfach einen Downloader einbauen, der eine APK abruft und den Benutzer auffordert, sie zu installieren. Auf iOS können Sie effektiv nicht ohne viel Aufwand seitlich laden, und JB'd-Geräte kümmern sich nicht um die Einschränkungen des App Stores.

Ist es jetzt möglich, es für andere Plattformen als iOS oder Android zu implementieren? Sicher! Aber Desktop ist noch nicht in der Beta-Phase (außerdem können Sie Ihren eigenen Autoupdater auf dem Desktop auch selbst erstellen) und, Web, nun, aktualisieren Sie einfach die Seite.

Nun, wenn Sie das Team werfen Sie einen Blick wollen, gehen Sie

Wenn Ihr Kommentar in die unten stehende Liste fällt, überdenken Sie ihn bitte noch einmal .

  • Fragen, wann/ob es in der Roadmap steht
  • "Es ist nicht da" (und Variationen, wie der vorherige Kommentar zu diesem)
  • "Wir verwenden Framework X, weil kein Code-Push"
  • "Framework X ist besser, weil Code-Push"
  • „Wir brauchen Code-Push“
  • "Aktualisierung?"
  • Argumente für Code-Push, die . sind

    • Enterprise-/Sideloaded-Apps

    • Notfall-Patching

    • Hinzufügen von Funktionen

  • Argumente gegen Code-Push, die

    • Die Dauer der Play-/App-Store-Rezensionen ist jetzt kürzer

    • Der Play/App Store verrät es

    • Du brauchst es nicht

Für dieses Problem sind bereits genügend Kommentare vorhanden. Fügen Sie daher keine Kommentare hinzu, die der Konversation nichts hinzufügen. Wenn das Team etwas zu sagen hat, wird es es hier posten, da dieser Beitrag derzeit fast 100 Teilnehmer und über 500 Daumen hat, ist es nicht möglich, ihn zu ignorieren.

Ehrlich gesagt denke ich nicht, dass dies Ihre Sorge sein sollte. Ein Entwickler nutzt die Funktion auf eigene Gefahr. Wenn Apple plötzlich beschließt, alle Apps per Code-Push zu verbieten, muss Ihre App einen anderen Ansatz verfolgen. Aber das passiert nicht für JavaScript. Es passierte jahrelang nicht, warum sollte es für Flutter passieren? Sie können es nicht einmal überprüfen. Die Leute fragen nach dieser Funktion, weil sie nützlich ist. Sie können kleine Module schreiben und dynamisch aktualisieren. Es ist ein Gamechanger. Sie können einen Fehler in einem Modul im laufenden Betrieb beheben. Außerdem kann Apple nicht wirklich überprüfen, was eine App macht, es fehlen die Ressourcen. Es wäre unmöglich, ich hoffe, Sie erkennen es. Außerdem, worum geht es? Ich kann undurchsichtigen Code schreiben und eine Hintertür in eine Anwendung einfügen, die ausgelöst wird, wenn ich als Ergebnis eines REST-Aufrufs einen bestimmten JSON-Code bereitstelle. Wie kann Apple es überprüfen? Es kann nicht. Dagegen können weder Apple noch Android etwas tun. Die Leute brauchen diese Funktion, und Sie sollten sie implementieren. Was wir damit machen, ist unser Geschäft, nicht Ihres. Du hast selbst gesagt, diese Funktion hat über 500 Daumen hoch und über 100 Teilnehmer. Vielleicht ist es an der Zeit, dass Sie es gemäß der Community-Anfrage implementieren.

@dedalozzo Tolle frische Argumente!

Ich gehöre nicht zum Flatter-Team, also zielen Sie bitte nicht auf mich, um Implementierungen anzufordern.

Dennoch ist es wahr ist , dass Apple und Google nicht die Ressourcen haben könnten , dass (das Spiel protect Team ist die ganze Zeit aktiv, können sie gefährliches Verhalten automatisch erkennen) zu erkennen, aber es „hinter dem Rücken“ jetzt gibt Apple - einen tatsächlichen Grund die Umsetzung ein pauschales Verbot von Flutter zu verhängen, da es im Grunde _mit Werkzeugen ausgestattet ist, die ausdrücklich gegen ihre Richtlinien verstoßen.

Sie könnten es auch als Teil einer ethischen Frage formulieren (Sollten Sie im Namen des Fortschritts etwas implementieren, das zusätzliche Risiken für eine App hinzufügt und gegen die Store-Richtlinien verstößt?) oder als Planungsfrage (Sollten Sie an etwas arbeiten, das eine massive " Wenn Sie dies verwenden, werden Sie wahrscheinlich aus dem App/Play Store verbannt "-Klausel, die Benutzer wahrscheinlich vermeiden und Ressourcen mit einer sicheren und garantierten Wirkung von anderen Aufgaben ablenken möchten?).

Nicht nur das, ein versehentlicher Verstoß gegen die Play Store-Richtlinien / eine Beziehung zu jemandem, der gegen die Play Store-Richtlinien verstößt, bedeutet im Grunde genommen, dass Ihr Konto gesperrt wird.

Außerdem können Sie, wie oben erwähnt, durch die Verteilung außerhalb des Play Stores aktualisierte APKs pushen.

Es tut mir leid, ich dachte, Sie gehören zum Flutter-Team.

Was Sie in Ihrem letzten Kommentar sagen, ist wahr. Tatsächlich scheint Code-Push von Apple und Google toleriert zu werden, auch wenn es grenzwertig und regelwidrig ist.

Aber solange Ihre Anwendung keinen Schaden anrichtet, werden sie sich meiner Meinung nach nicht einmal die Mühe machen, zu überprüfen, ob Sie tatsächlich Code übertragen. Sie könnten, wenn jemand ein seltsames Verhalten meldet. Aber zu diesem Zeitpunkt werden sie gegen den Entwickler dieser App vorgehen, nicht gegen die gesamten Apps, die Push-Code verwenden.

Sehr in Arbeit, ermöglicht aber Code-Push https://github.com/chgibb/hydro-sdk

@chgibb Warte mal ... das ermöglicht Code-Push, ändert aber auch das Ganze von Dart in Typescript?

Gibt es eine Möglichkeit diese beiden Dinge zu trennen? Um beim Schreiben von Dart wie gewohnt Codepush zu erhalten?

@SpajicM , das nur funktioniert, _weil_ es kein Dart verwendet, sondern wahrscheinlich eine JS-Engine wie JavascriptCore verwendet, die Apple gehört, und sie scheinen in die andere Richtung zu schauen, wenn sie mit Code-Push verwendet wird.

Kratzen Sie das, es verwendet Lua-Bytecode, der in jeder Form gegen die Geschäftsrichtlinien verstößt .

@miyoyo warum
@SpajicM es ist rein additiv. Maschinenschriftstücke können in eine größere Dart-App eingebettet werden. So klein wie einzelne Textstücke oder ganze Bildschirme.

Es ist durch die Store-Richtlinie verboten, jede Art von kompiliertem Code zu pushen, von dem es sich anscheinend um .hc Dateien handelt, da sie kompilierter Lua-Bytecode sind (vielleicht mit Erweiterungen, nicht überprüft).

Der spezifische Anwendungsfall des Pushens von _kompiliertem_ Code an Apps verstößt ausdrücklich gegen die Play Store- Richtlinie und das Element "kein Quellcode bereitgestellt", das Sie _könnten_, wie in CodePush, nicht zutreffen würde, was gegen die Richtlinien von Apple verstößt.

Ich sage nicht, dass das Konzept schlecht ist, tatsächlich ist das großartige Arbeit! Es ist nur so, dass das Herunterladen von Bytecode über das Internet in beiden Fällen ausdrücklich gegen die Geschäftsrichtlinien verstößt.

Wie funktionieren all diese Handyspiele mit ihren In-Game-Updates? Werden nur Assets gepusht/heruntergeladen?

@miyoyo aus der 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...
Die .hc Dateien von Hydro-SDK sind reiner Lua 5.2-Bytecode ohne Erweiterungen oder spezielle Funktionen. Sie werden in einem Interpreter ohne Funktionalität zur Selbstmutation oder Codegenerierung ausgeführt. Nichts von dart:io wird ihnen ausgesetzt. Obwohl, es gibt nichts , ein Einbettungs von Belichtungs stoppen dart:io ‚s File Klasse oder aussetzt PlatformChannel s zum Beispiel.

Apples Abschnitt 2.5.2 ist etwas mehrdeutig in Bezug auf die Bedeutung des Wortes "Ausführen" sowie in Bezug auf die Änderung von Funktionen oder Funktionen.

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 Okay, ich würde sagen, das könnte auf Android weitergehen, obwohl ich immer noch eine Ablehnung im App Store erwarten würde. (Um nicht zu sagen die Reduzierung der Spitzenleistung, aber das ist wahrscheinlich ein Detail bei High-End-Telefonen)

@kuhnroyal Mobile- Dynamic Asset Delivery für nicht ausführbare Dinge , diese werden normalerweise schnell verfolgt, da sie weniger Überprüfung erfordern, APK-Erweiterungsdateien, mit denen Sie Teil-Upgrades durchführen können, die jedoch immer noch regelmäßigen Store-Update-Zyklen unterliegen, und regelmäßige APK-Updates .

Mit Kunden gesprochen: Schlagzeile, dass dies für sie keine Priorität mehr hat.

Sie können Localizely für Over-the-Air-Updates von Texten/Übersetzungen verwenden: https://localizely.com/flutter-over-the-air

Bauen Sie aus Gründen des Flatterns dieses Feature oder führen Sie uns durch, wie man es baut. Danke schön .

Leute _bitte_, es ist das dritte Mal, dass dies gepostet wird, aber _Sendet keine Kommentare, es sei denn, ihr habt wirklich etwas hinzuzufügen_ .

Lesen Sie diesen Beitrag für weitere Details und um einen Daumen nach oben auf den ersten Beitrag zu setzen.

Nachrichten haben keine Auswirkungen mehr, da ich mir ziemlich sicher bin, dass der Großteil des Teams hier Benachrichtigungen für diesen Beitrag deaktiviert hat.

zwischenzeitlich eine alternative für code push ?

zwischenzeitlich eine alternative für code push ?

nach meiner Erfahrung gibt es keine Alternative

@samerdernaika @mfenej Obwohl noch nicht ganz produktionsreif, wurde dieses Projekt mit Code-Push als explizites Ziel gestartet https://github.com/chgibb/hydro-sdk

@miyoyo

Bei der ersten Frage, _was_ gepusht wird, liegt das größte Problem. Die Überprüfungsrichtlinien von Apple verbieten jegliche Art von Code-Push . Ja, die verwendete Terminologie _auch Javascript-Code-Push. Apple hat anscheinend keine Maßnahmen dagegen ergriffen, und dafür kann es viele Gründe geben, aber alle hier veröffentlichten Gründe wären reine Spekulation.

Das stimmt nicht. Bitte überprüfen Sie es und verbreiten Sie keine Fehlinformationen!

In Abschnitt 3.3.2 des Apple-Entwicklerlizenzvertrags heißt es:

3.3.2 Außer wie im nächsten Absatz beschrieben, darf eine Anwendung keinen ausführbaren Code herunterladen oder installieren. Interpretierter Code kann in eine Anwendung heruntergeladen werden, jedoch nur, solange dieser Code: (a) den Hauptzweck der Anwendung nicht durch die Bereitstellung von Merkmalen oder Funktionen ändert, die mit dem beabsichtigten und beworbenen Zweck der Anwendung, wie sie an die App übermittelt wird, nicht vereinbar sind Store, (b) keinen Store oder eine Storefront für anderen Code oder andere Anwendungen erstellt und (c) Signing, Sandbox oder andere Sicherheitsfunktionen des Betriebssystems nicht umgeht.

Sie erlauben ganz speziell das Herunterladen von interpretiertem Code wie JS, solange Sie den Hauptzweck der Anwendung nicht ändern. Das ist jetzt schon seit über 5 Jahren so. IIRC und ich habe noch nie gehört, dass jemand für die normale und verantwortungsvolle Nutzung von Codepush gezerrt wurde.

Werfen Sie einen Blick in den AppCenter-Abschnitt über Codepush- und Store-Richtlinien-Compliance. AppCenter Codepush (von Microsoft unterstützt) wird von vielen Apps ohne Probleme mit der Store-Compliance verwendet. https://github.com/microsoft/react-native-code-push#store -guideline-compliance

Der große Blocker von Codepush, den ich sehe, ist, dass es sich möglicherweise nicht lohnt, den Performance-Kompromiss zu verwenden, um dazu gezwungen zu werden, auf iOS zu kompilieren oder Dart zu interpretieren, anstatt vorkompiliert zu sein. Da Flutter auf den Browser abzielt, vermute ich jedoch, dass eine Kompilierung in js-Perf gut genug wäre, aber vielleicht immer noch kein akzeptabler Leistungskompromiß für das Flutter-Team.

Vielleicht kommt eine Drittanbieterlösung (wie AppCenter für React Native) und füllt diese Lücke. CodePush ist super nützlich!

Hmm, eine schnelle Google-Suche zeigt viele Beispiele dafür, wie Apple Apps ablehnt, die Code-Push-Funktionen enthalten, siehe zB

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

Angesichts der Tatsache, dass die Überprüfungszeiten im App Store jetzt fast immer in Stunden und nicht in Tagen gemessen werden, verstehe ich nicht, warum jemand das Risiko eingehen sollte. Wenn Code-Push in die Flutter-Engine integriert wird, könnte Apple beschließen, alle Flutter-Apps zu verbieten.

@matthewlloyd Sie haben völlig Recht, dass die Überprüfungszeiten gesunken sind. Ich selbst habe heute Morgen eine (proprietäre) App in den App Store eingereicht und diese bis zum Ende des Tages heute freigeben lassen! Aber das ist _kürzlich_. Wir, als Herausgeber mobiler Anwendungen, sind immer noch den Launen/Kapazitäten der Review-Teams verpflichtet, unsere Einreichungen zu prüfen.

Ein Update, das in die Hände Ihres Benutzers gelangt, bewegt sich nicht mit der Geschwindigkeit der App-Überprüfung. Die Zeit zwischen "Entwickler-Release", "App Store-Verarbeitung", Weitergabe an Server in Ihrem Benutzermarkt usw. kann ebenfalls einige Zeit dauern. Ich habe gesehen, dass diese späteren Phasen in extremen Fällen mehr als 24 Stunden dauern.

Persönlich besteht meine Leidenschaft für Code-Push darin, die Verantwortung für die Lieferkette der Update-Bereitstellung zu übernehmen. Ganz zu schweigen von den ziemlich großen Hürden, die mit dem Versuch verbunden sind, den aktuellen Prozess in ein kohärentes CD-Setup zu automatisieren, angesichts des bedauerlichen Zustands von xcode CLI-Tools.

Weniger als 24 Stunden reichen in den allermeisten Fällen für fast alle aus, denke ich. Wenn Sie schneller ein Update durch den Überprüfungsprozess von Apple benötigen, z. B. für eine dringende Fehlerbehebung, können Sie eine beschleunigte Überprüfung anfordern. Ich habe das einmal getan, und die App-Überprüfung war buchstäblich 10 Minuten nach meiner Anfrage abgeschlossen.

Die Übernahme der Verantwortung für die Lieferkette der Lieferung erfolgt auf eigene Gefahr ...

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

„2.5.2 Apps sollten in ihren Bundles in sich geschlossen sein und dürfen keine Daten außerhalb des vorgesehenen Containerbereichs lesen oder schreiben, noch dürfen sie Code herunterladen, installieren oder ausführen, der Funktionen oder Funktionen der App einführt oder ändert , einschließlich anderer Apps. Bildungs-Apps, die zum Unterrichten, Entwickeln oder Testen von ausführbarem Code durch Schüler bestimmt sind, können unter bestimmten Umständen Code herunterladen, sofern dieser Code nicht für andere Zwecke verwendet wird. Solche Apps müssen den von der Anwendung bereitgestellten Quellcode vollständig sichtbar machen und vom Benutzer editierbar."

Anforderungen an das Entwicklerprogramm von Apple, Abschnitt 3.3.2:

3.3.2 Außer wie im nächsten Absatz beschrieben, darf eine Interpretierter Code darf nur in einer Anwendung verwendet werden, wenn alle Skripte, Codes und Interpreter in der Anwendung verpackt und nicht heruntergeladen wurden. Die einzigen Ausnahmen vom Vorstehenden sind Skripte und Code, die von Apples integriertem WebKit-Framework oder JavascriptCore heruntergeladen und ausgeführt werden, vorausgesetzt, dass solche Skripte und Code den Hauptzweck der Anwendung nicht ändern, indem sie Funktionen oder Funktionen bereitstellen, die nicht mit den beabsichtigten und beworbenen Zweck der Anwendung, wie sie im App Store eingereicht wurde.

@AndrewMorsillo Egal, was in jeder Richtlinie steht und egal wie viele Informationen vorgebracht werden, das Beste, was wir erreichen können, ist: "Es ist vielleicht erlaubt, wir sind uns nicht sicher, ob es sich um eine verbotene Straftat handelt, vielleicht sind wir uns nicht sicher." .

Was auch immer der Fall sein mag, Flutter führt derzeit keinen interpretierten Dart auf iOS aus, was hinzufügt, dass dies eine Leistungseinbuße wäre, und wie Sie selbst erwähnt haben, ist es zusätzlich zu meinen vorherigen Beiträgen und dem Beitrag von @matthewlloyd bestenfalls kaum in einigen Fällen erlaubt, im Allgemeinen ist es eine sehr, sehr graue Zone, und im schlimmsten Fall ist es einfach verboten.

Soweit ich das beurteilen kann, lohnt es sich nicht, all das gegen die Umgehung eines 24-Stunden-Review-Zyklus und das Schreiben von Tests einzutauschen. (Ich konnte verstehen, wann es eine Woche war, und das ist normalerweise nur auf iOS-Seite, was hier effektiv der größte Streitpunkt ist)

Es geht nicht nur um den Überprüfungsprozess, sondern auch um Benutzer, die bei alten Versionen der App hängen bleiben, weil sie das automatische Update möglicherweise deaktiviert haben.

Klar, man kann die Mindestversionsprüfung selbst implementieren, aber dann müssen sie wieder durch den Play Store und die Leute sind leider faul. Mit Code-Push könnte es die App bei jedem Lauf schnell aktualisieren (hoffe ich) und den Benutzer nahtloser einsteigen lassen.

@miyoyo Ich weiß nicht, warum du das Bedürfnis

Es gibt einen anderen Weg, dies zu lösen. Ich hatte viele Apps gesehen, die dies tun. App wenn aus
des Datums, eine Meldung anzeigen, entweder schließen Sie sie oder aktualisieren Sie die App. das alles.

Am Freitag, den 7. August 2020 um 07:38 Uhr schrieb SpajicM [email protected] :

Es geht nicht nur um den Überprüfungsprozess, sondern auch um Benutzer, die
bei alten Versionen der App hängen geblieben, weil sie möglicherweise die Funktion deaktiviert haben
automatisches Update.

Klar, du kannst die Mindestversionsprüfung selbst implementieren, aber dann sie
Ich muss wieder durch den Play Store gehen und die Leute sind leider faul. Mit
Code-Push, es könnte die App einfach bei jedem Lauf schnell aktualisieren (hoffe ich) und
lassen Sie den Benutzer nahtloser einsteigen.

@miyoyo https://github.com/miyoyo Ich weiß nicht warum du das fühlst
Notwendigkeit, auf jeden Kommentar oder jede Idee zu reagieren, die hier präsentiert wird.
Die Leute wollen das. Ihr habt den Leuten gesagt, dass sie das Thema positiv bewerten sollen, und wir haben positiv gestimmt
es bis ganz nach oben. Das wird nie gelöst, es sei denn jemand
denkt aktiv darüber nach und treibt es voran.


Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/flutter/flutter/issues/14330#issuecomment-670242698 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA
.

Es gibt einen anderen Weg, dies zu lösen. Ich hatte viele Apps gesehen, die dies tun. Wenn die App veraltet ist, wird eine Meldung angezeigt, entweder schließen Sie sie oder aktualisieren Sie die App. das alles.

Wahrscheinlich der schlechteste UX-Weg... :/

@SpajicM

Es geht nicht nur um den Überprüfungsprozess, sondern auch um Benutzer, die bei alten Versionen der App hängen bleiben, weil sie das automatische Update möglicherweise deaktiviert haben.

Klar, man kann die Mindestversionsprüfung selbst implementieren, aber dann müssen sie wieder durch den Play Store und die Leute sind leider faul. Mit Code-Push könnte es die App bei jedem Lauf schnell aktualisieren (hoffe ich) und den Benutzer nahtloser einsteigen lassen.

Ist dies in Bezug auf die UX nicht eine _schlechte_ Art, mit Updates umzugehen? Wenn jemand automatische Updates manuell deaktiviert, warum sollte Flutter dies überschreiben? Es ist fraglich, ob eine App diese Leistung überhaupt haben sollte, aber sicherlich nicht das gesamte Framework.

Ich denke, dass die Zentralisierung des Update-Prozesses über die App Stores für UX besser ist, da sie alle Updates über den Store verwalten können. UX auf Kosten der Entwicklerzeit ist sozusagen der Kern der App-Entwicklung. Und wenn Sie eine sofortige Behebung benötigen (z. B. für eine Sicherheitslücke), können Sie ein beschleunigtes Update erhalten oder dem Benutzer die Nutzung der App verweigern, bis sie aktualisiert ist. Letzteres ist natürlich keine gute Option, und ersteres nervt, aber das liegt daran, dass Apple und Google die Benutzer an die erste Stelle setzen und mit Flutter selbst wenig zu tun haben.

@chgibb

Persönlich besteht meine Leidenschaft für Code-Push darin, die Verantwortung für die Lieferkette der Update-Bereitstellung zu übernehmen.

Dies ist eine Art Problem in diesem Thread – zu versuchen, das zu tun, wovor Apple und Google dringend warnen, ist keine gute Idee, wenn Sie ihre App-Stores verwenden. Wie @miyoyo sagte, ist es bestenfalls eine Grauzone, die nicht gerade für ein Framework geeignet ist, das von Google und anderen Unternehmen / Einzelpersonen verwendet wird.

Nun, Flutter kann Ihren Code immer noch nicht im laufenden Betrieb aktualisieren, aber tatsächlich sprach dieser Link über Bilder und erinnerte mich daran, dass Firebase Remote Config eine Sache ist. Der Nachteil ist, dass Sie vorhersagen müssen, welche Code-Bits möglicherweise geändert werden müssen, und diese Änderungen in Ihrer App erwarten. Sobald dies jedoch erledigt ist, sollten neue Änderungen ziemlich schnell ohne den App Store eingeführt werden (ähnlich wie bei React Native Code Push). seine Bilder)

@ardyfeb Leute wie du geben der

Es gibt einen anderen Weg, das zu lösen
ohne flattern web

Es gibt einen anderen Weg, dies zu lösen. Ich hatte viele Apps gesehen, die dies tun. Wenn die App veraltet ist, wird eine Meldung angezeigt, entweder schließen Sie sie oder aktualisieren Sie die App. das alles.

Am Fr, 7 Aug. 2020 um 07:38, SpajicM @ . * > schrieb: Es geht nicht nur um den Überprüfungsprozess, sondern auch um Benutzer, die bei alten Versionen der App hängen bleiben, weil sie möglicherweise das automatische Update deaktiviert haben. Klar, man kann die Mindestversionsprüfung selbst implementieren, aber dann müssen sie wieder durch den Play Store und die Leute sind leider faul. Mit Code-Push könnte es die App bei jedem Lauf schnell aktualisieren (hoffe ich) und den Benutzer nahtloser einsteigen lassen. @miyoyo https://github.com/miyoyo Ich weiß nicht, warum Sie das Bedürfnis verspüren , auf jeden Kommentar oder jede Idee zu reagieren, die hier präsentiert wird. Die Leute wollen das. Ihr habt den Leuten gesagt, dass sie das Thema positiv bewerten sollen, und wir haben es bis ganz nach oben gestimmt. Dies wird niemals gelöst werden, wenn nicht jemand aktiv darüber nachdenkt und es vorantreibt. — Sie erhalten dies, weil Sie diesen Thread abonniert haben. Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub < #14330 (Kommentar) > an oder https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA .

Das klingt großartig... wenn Sie Banking-Apps erstellen.

Wenn jemand Over-the-Air-Updates nur für App-Übersetzungen benötigt, hier ist eine Flutter-Beispiel-App: https://github.com/localizely/flutter-ota-sample-app

Es scheint, dass die Richtlinien von Apple anders sind als früher?

Das ist immer noch das selbe

2.5.2 Apps sollten in ihren Bundles in sich geschlossen sein und dürfen keine Daten außerhalb des vorgesehenen Containerbereichs lesen oder schreiben, noch dürfen sie Code herunterladen, installieren oder ausführen, der Features oder Funktionen der App einführt oder ändert, einschließlich anderer Apps . Bildungs-Apps, die darauf ausgelegt sind, ausführbaren Code zu unterrichten, zu entwickeln oder den Schülern das Testen von ausführbarem Code zu ermöglichen, können unter bestimmten Umständen Code herunterladen, sofern dieser Code nicht für andere Zwecke verwendet wird. Solche Apps müssen den von der Anwendung bereitgestellten Quellcode für den Benutzer vollständig sichtbar und bearbeitbar machen.

Ich kann jedoch keine anderen Verweise auf interpretierten oder ausführbaren Code finden.

Ist es möglich, dass die Details über das Apple-Ökosystem aus dem ursprünglichen Beitrag nicht mehr wahr sind, da sie anscheinend nichts mehr speziell über interpretierte oder kompilierte Sprachen sagen?

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen