Flutter: Code Push / Hot Update / Mises à jour hors bande

cc @floitschG

regarde aussi
https://groups.google.com/forum/#!msg/flutter -dev/YwzItp1pxJo/7bFGDLvxBAAJ
Je serais extrêmement excité à ce sujet.

Je pense que ce serait assez important car cela pourrait être l'une des seules caractéristiques vraiment distinctives de React Native, et malheureusement, certaines entreprises pourraient considérer cela comme un dealbreaker.

Cas d'utilisation

• bogues critiques, en particulier sur iOS, en particulier pour les VIP ou les situations urgentes, urgentes, critiques pour l'entreprise et/ou les utilisateurs qui ne peuvent pas du tout utiliser l'application pour une raison quelconque.
• Des tests de fonctionnalités plus dynamiques que des déploiements par étapes
• ce serait une bonne idée de préparer Fuschia et/ou Chromebooks. il pourrait y avoir des scénarios où le flutter est "en concurrence" avec des applications Web et pas seulement des solutions pwas/Kotlin/Swift/React/Xamarin/other-junkier-hybrid

Dans la bataille épique qui est Flutter vs React Native, le push de code est un sacré outil (:
En tant que développeur RN, je ne saurais trop insister sur l'importance de cette fonctionnalité. Beaucoup passeront Flutter simplement à cause de l'absence de poussées chaudes. Une fois que vous vous êtes habitué à corriger rapidement les bogues et à proposer de nouvelles fonctionnalités, vous ne pouvez plus revenir en arrière.

la compilation vers un chemin javascript diminuera les avantages de la fléchette, n'est-ce pas ?
J'ai trouvé qu'une application native pouvait recharger le code à l'aide de Rollout.io mais elle a été bloquée par Apple : https://news.ycombinator.com/item?id=13817557
en regardant ce modèle, il semble que flutter n'aura pas de fonction de poussée de code transparente comme ce que nous voyons sur React Native.
aimerait avoir plus d'informations sur les possibilités de cette fonctionnalité de la part des principaux responsables (:

la compilation vers un chemin javascript diminuera les avantages de la fléchette, n'est-ce pas ?

De quels avantages parlez-vous ?

Codepush est vraiment nécessaire. J'adore voir la possibilité de mise à niveau en direct sur Flutter.

nous venons d'avoir un cas d'utilisation en direct avec une application de production où nous recevions beaucoup de mauvaises critiques pour une fonctionnalité qui semblait être un cas légèrement marginal (lié au refus d'autorisation de localisation dans un cas d'utilisation que tous les comptes de test n'avaient pas) mais qui ne l'était pas vraiment t.

une fonction de push de code pourrait envoyer immédiatement des correctifs critiques aux utilisateurs plutôt que d'attendre qu'ils soient mis à niveau ; pour une raison quelconque, il semble que les utilisateurs soient parfois lents à mettre à niveau :(

Aucun support de push de code n'est un NO GO :-(

Il semble que JavascriptCore ne soit plus requis pour le code interprété : https://www.theregister.co.uk/2017/06/07/apple_relaxes_developer_rules/?page=2

Si l'écosystème IOS est un frein, pourquoi ne pas l'implémenter sur Android uniquement pour l'instant ? Quelque chose de mieux que rien et c'est un point de départ.

Très apprécié pour que l'équipe implémente cette fonctionnalité dès que possible.

Nous avons construit quelques prototypes de base ici, mais nous n'avons rien à partager pour le moment. Pour faire cela vraiment bien, il faudra un peu de travail dans la chaîne d'outils du compilateur de Dart. Je m'attendrais à ce qu'il faille plusieurs mois avant que nous ayons beaucoup à partager ici. L'équipe se concentre actuellement sur la stabilisation pour 1.0.

Cela dit, nous vous entendons. :) C'est clairement une fonctionnalité que beaucoup de gens apprécient et nous sommes intéressés à fournir une fonctionnalité comme celle-ci à terme.

La prise en charge de "Code Push" pour Flutter pourrait être le dernier clou dans le cercueil concernant React Native.

Avec tout mon amour pour RN et la communauté RN, étant ce qui change la donne, ce n'est pas un match pour Flutter.
Flutter le cloue dans n'importe quel aspect (outillage, performance, langage...).

Après 1.0 hits et la communauté grandit un peu plus + Support Code Push = Je ne vois aucune raison de démarrer un nouveau projet mobile avec autre chose que Flutter.

des progrès sur "Code Push" ??

Dans quelle mesure serait-il possible de remplacer dynamiquement un fichier .so complet ? L'ensemble de la chaîne d'outils du compilateur, le code shake, etc. ne devraient pas être orientés vers un cas sans doute marginal dont les gens peuvent ou non bénéficier, étant donné qu'il y aura toujours des tickets en haut de la liste des priorités.

Je pense qu'il devrait y avoir de la place pour "charger" le fichier .so complet, de sorte que la construction du code dart au code machine peut toujours être exactement la même. Un composant petit mais complètement indépendant pourrait se voir attribuer les "fonctionnalités viables minimales" suivantes : téléchargez .so et remplacez celui d'origine par celui-ci, et redémarrez l'application avec l'intention de lancement principale.

Responsabilités supplémentaires : télécharger les actifs, vérifier les signatures et ainsi de suite. Mettez à jour les moteurs flutter/dart/skia et ainsi de suite.

Il me semble que cela viole les directives d'iOS, mais je ne suis vraiment pas un fan de tout ce qui est interprété de toute façon, ou d'iOS en général. Et je préfère l'avoir sur Android que de ne pas l'avoir du tout, juste parce que c'est cool.

Au moins, la partie téléchargement semble faisable maintenant que nous avons un travail isolé autorisé en arrière-plan, mais il serait intéressant de voir comment échanger le fichier .so d'origine avec celui téléchargé. Peut-être qu'un code .so ou java supplémentaire pourrait faire cette partie, mais il se trouvera dans le dossier de code, je ne suis pas sûr que l'application elle-même puisse le modifier, il faudrait donc probablement quelques ajustements pour que le moteur de flutter charge toutes les applications. Les données?

Commencer à réorganiser l'application de mon entreprise en utilisant Flutter. Cependant, notre principale demande est d'avoir une fonctionnalité de mise à jour à chaud, car nous sommes toujours en version bêta et continuons à tester rapidement de nouvelles interfaces utilisateur et fonctionnalités. Vivre pour avoir cette fonctionnalité.

Les mises à jour?
(Je parie que la fonctionnalité est déjà terminée et viendra comme une surprise lorsque 1.0 sera atteint)
??

vote positif

Il n'y a qu'une seule raison pour nous empêcher d'utiliser Flutter : le push de code

Si vous ne pouvez pas prendre en charge le code Push, existe-t-il un moyen de créer un analyseur pour générer à partir de certains dictionnaires (comme json, xml...) vers Flutter Widget ? Est-ce impossible ou une bonne idée ?

Cela semble un peu prometteur. Configuration à distance de Firebase vers le widget si nécessaire.
Bien qu'amener les entreprises à avoir une idée de ce qu'elles veulent aide également :)

Le vendredi 12 octobre 2018, 03h45 Hưng Lương Đỗ Minh [email protected]
a écrit:

Si vous ne pouvez pas prendre en charge Code Push, existe-t-il un moyen de créer un analyseur pour
générer à partir de certains dictionnaires (comme json, xml...) vers Flutter Widget ? Est
c'est impossible ou une bonne idée ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-429251785 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AC4TYe9qDMi4bt2U5qyyAnJisN3ys_Z5ks5ukFavgaJpZM4RxUZi
.

Je pense qu'au moins l'interface utilisateur/vue écrite dans Dart peut être téléchargée via le réseau à partir du serveur.
Pour vous inspirer, voyez comment le framework Qt Quick le fait.

QtDD12 - Servir les applications QML sur le réseau - Jeremy Laine :

• Vidéo
• Diapositives

attendez-vous à ce qu'il puisse être inclus dans la prochaine version 1.0 !

Beaucoup de nos clients utiliseront notre application Flutter sur un appareil kiosque derrière des pare-feu stricts qui empêcheraient les mécanismes de mise à jour des applications du Google Store. Ces clients ne seront pas ajoutés à la liste blanche du Play Store. Nous aurons finalement des centaines de périphériques matériels avec l'application Flutter, et avoir un moyen de pousser les mises à jour vers l'application tout en respectant les restrictions de pare-feu client serait incroyable !

@eseidelGoogle - cela fait un moment que vous n'avez pas fourni de mises à jour ici.

Travaillez-vous toujours là-dessus ? Comment vont les choses ?

Le progrès continue. Aucune mise à jour à partager pour le moment.

Nous avons proposé trois termes clairs pour ce que les gens ont mis dans ce bogue plus tôt dans la journée :

• « Correction dynamique » : la possibilité de mettre à jour le code Dart d'une application sur le terrain en téléchargeant un correctif (en quelque sorte) et en le fournissant à la VM Dart. Cela nécessiterait un rechargement de l'application pour prendre effet.
• « Chargement dynamique de l'extension » : la possibilité de télécharger du code Dart qui n'a pas été écrit lors de la première publication de l'application, ce qui ajoute une nouvelle fonctionnalité à l'application. Cela pourrait être fait à la volée. Cela peut nécessiter que l'application principale soit plus grande, car nous ne pouvons pas savoir à l'avance ce qui est nécessaire pour chaque future extension.
• « Distribution d'applications modulaires » : la possibilité de regrouper une seule application dans plusieurs archives distinctes lors de sa compilation et de les télécharger indépendamment selon les besoins.

Nous devrions probablement diviser ce problème en trois bogues que nous pouvons suivre séparément.

Est-ce vraiment faisable pour iOS ? Mis à part la possibilité qu'Apple interdise cela comme ils l'ont fait avec rollout.io , le javascript devrait s'exécuter sans aucun type de JIT (pas d'écriture sur des pages exécutables sur iOS). De plus, les différentes caractéristiques GC du noyau Javascript alors que Flutter créant des tonnes d'objets de courte durée pourraient ne pas être de bon augure.

Ce qu'Apple autorise/ne permet pas actuellement (ou à l'avenir) est totalement distinct des implémentations techniques. Flutter fonctionne dans de nombreux endroits autres qu'iOS. Évidemment, nous aimerions toujours concevoir des technologies qui peuvent fonctionner sur iOS (comme je pense que de nombreuses solutions possibles de « poussage de code » pourraient le faire), mais iOS n'est pas la seule considération. J'espère que cela pourra aider?

Vraiment triste de ne pas voir Code Push publié en 1.0. Comme d'autres, c'est la principale raison pour laquelle je ne peux pas l'utiliser sur des projets qui nécessitent la possibilité de patcher sans attendre les magasins d'applications.
Je comprends que c'est un gros effort pour y arriver, bonne chance.

Il n'y a qu'une seule raison pour nous empêcher d'utiliser Flutter : le push de code

J'aimerais laisser mes commentaires juste pour montrer mon intérêt pour ce sujet.
Mon entreprise développe une application multi-clients uniquement Android pour gérer les équipes de maintenance. En 2018, nous avons publié environ 100 mises à jour, dont aucune n'a demandé de nouvelle version via Google Play, car la plupart d'entre elles sont de petits ajustements et personnalisations dont chaque client a besoin, qui sont imprévisibles au préalable.
Réécrire cette application dans Flutter serait un rêve, mais à part les coûts de réécriture, gaspiller de l'argent à attendre qu'un correctif ou des personnalisations soient publiés via GPlay serait un cauchemar.

J'espère réussir le plus vite possible

Autre point : si l'équipe Flutter fournit officiellement la solution de correctif, je pense qu'Apple peut rejeter toutes les applications créées par Flutter à un moment donné, car le correctif enfreint définitivement la directive de révision de l'AppStore, les développeurs peuvent contourner la révision de l'AppStore et modifier leur app, il est dangereux pour les utilisateurs.

Actuellement, Apple rejette toutes les applications avec JsPatch, qui était la solution de correctif la plus populaire en Chine. JsPatch est construit sur le runtime JsCore et OC.

J'aimerais créer des applications Flutter sans fonction de correctif logiciel, plutôt que des applications pouvant être rejetées par Apple à l'avenir.

@MaxZeng Ravi de connaître JsPatch. Mais pour l'instant, il semble que le patch à chaud soit autorisé. Il existe de nombreuses applications React Native dans la boutique Apple et elles utilisent toutes des correctifs à chaud via CodePush.

Si seul le support iOS/android comme cet exemple :
MyFlutterApplication demande la permission/veut mettre à jour votre application
Changelogs : ajouter des chatons et des chiens (v1.0)
Autoriser | Ne permets pas

après avoir examiné les lignes directrices pour les deux parties.

@MaxZeng Ravi de connaître JsPatch. Mais pour l'instant, il semble que le patch à chaud soit autorisé. Il existe de nombreuses applications React Native dans la boutique Apple et elles utilisent toutes des correctifs à chaud via CodePush.

Oui, ReactNative est une exception au push de code pour le moment, mais cela ne signifie pas qu'Apple le prend en charge officiellement. L'application de notre société a été rejetée par l'AppStore plus de 3 fois récemment en raison d'un framework de type RN, et nous devons réécrire ces fonctions par OC/H5, c'est un cauchemar pour les développeurs.

React Native est toujours un framework SAFE pour Apple, car il est finalement rendu par-dessus UIKit, mais Flutter est complètement différent :
1、Tout d'abord, cela brise les écosystèmes des développeurs d'Apple, cela contourne le framework UIKit, et c'est HORS du contrôle d'Apple, par exemple, il y aura de plus en plus d'applications de style MD dans l'AppStore, et cela peut aller à l'encontre de la directive sur l'interface humaine d'Apple. Apple est une entreprise célèbre en raison de son excellent design.
2、Deuxièmement, si le rechargement à chaud est officiellement pris en charge par Flutter, Apple peut utiliser cette raison pour rejeter directement les applications Flutter.

De mon point de vue, Flutter devrait suivre la directive d'examen de l'AppStore au lieu de la casser, c'est important pour un framework mobile multiplateforme, vous ne devriez pas casser l'écosystème d'Apple car nous pouvons le faire. Si Apple rejette Flutter, le principal avantage de Flutter disparaîtra.

Le CodePush n'est pas une technique difficile ou mystérieuse, Apple peut l'implémenter facilement (surtout en se basant sur l'OC), la seule raison pour laquelle Apple l'interdit est qu'il est dangereux pour les utilisateurs finaux, et cela endommage complètement l'AppStore/Google Play. C'est un désastre si de nombreuses applications peuvent modifier leurs fonctionnalités à tout moment et n'importe où, et il est difficile de retracer et de limiter ces actions nuisibles une fois que l'application est autorisée à publier.

CodePush n'est pas seulement une technique, c'est une partie importante des écosystèmes mobiles. Je pense que l'équipe Flutter ne devrait pas fournir officiellement une telle technique, bien qu'elle puisse être implémentée par certains développeurs en privé, c'est OK car elle ne sera pas utilisée de manière sauvage.

@MaxZeng Ravi de connaître JsPatch. Mais pour l'instant, il semble que le patch à chaud soit autorisé. Il existe de nombreuses applications React Native dans la boutique Apple et elles utilisent toutes des correctifs à chaud via CodePush.

Oui, ReactNative est une exception au push de code pour le moment, mais cela ne signifie pas qu'Apple le prend en charge officiellement. L'application de notre société a été rejetée par l'AppStore plus de 3 fois récemment en raison d'un framework de type RN, et nous devons réécrire ces fonctions par OC/H5, c'est un cauchemar pour les développeurs.

React Native est toujours un framework _SAFE_ pour Apple, car il est finalement rendu par-dessus UIKit, mais Flutter est complètement différent :
1、Tout d'abord, cela brise les écosystèmes des développeurs d'Apple, cela contourne le framework UIKit, et c'est HORS du contrôle d'Apple, par exemple, il y aura de plus en plus d'applications de style MD dans l'AppStore, et cela peut aller à l'encontre de la directive sur l'interface humaine d'Apple. Apple est une entreprise célèbre en raison de son excellent design.
2、Deuxièmement, si le rechargement à chaud est officiellement pris en charge par Flutter, Apple peut utiliser cette raison pour rejeter directement les applications Flutter.

De mon point de vue, Flutter devrait suivre la directive d'examen de l'AppStore au lieu de la casser, c'est important pour un framework mobile multiplateforme, vous ne devriez pas casser l'écosystème d'Apple car nous pouvons le faire. Si Apple rejette Flutter, le principal avantage de Flutter disparaîtra.

Le CodePush n'est pas une technique difficile ou mystérieuse, Apple peut l'implémenter facilement (surtout en se basant sur l'OC), la seule raison pour laquelle Apple l'interdit est qu'il est dangereux pour les utilisateurs finaux, et cela endommage complètement l'AppStore/Google Play. C'est un désastre si de nombreuses applications peuvent modifier leurs fonctionnalités à tout moment et n'importe où, et il est difficile de retracer et de limiter ces actions nuisibles une fois que l'application est autorisée à publier.

CodePush n'est pas seulement une technique, c'est une partie importante des écosystèmes mobiles. Je pense que l'équipe Flutter ne devrait pas fournir officiellement une telle technique, bien qu'elle puisse être implémentée par certains développeurs en privé, c'est OK car elle ne sera pas utilisée de manière sauvage.

Point très intéressant et semble raisonnable à certains égards, mais comporte également quelques erreurs.

1. Flutter prend également en charge le Cupertino d'Apple , MD n'est pas le seul choisi.
2. Vous connaissez peut-être Unity dans la zone Gaming, le système de rendu de Flutter fonctionne de la même manière à certains égards.
3. En fait et pour l'instant, l'utilisation du Web (JS) peut implémenter le CodePush et contourner l'examen de l'AppStore pour modifier leur application. Alors pourquoi rejeter Flutter(dart) et laisser tomber JS.

Alors pourquoi rejeter Flutter(dart) et laisser tomber JS.

JS s'exécute dans un bac à sable et est donc sécurisé. (comme toutes les pages Web chargées dans Safari)

Dart compile en code binaire et n'est pas contraint par un tel bac à sable.

Je suis développeur Android depuis de nombreuses années. Je pense que le code push n'est pas si important.
Si sans Code Push, vous ne pouvez pas développer ? Si c'est le cas, c'est trop stupide.
Flutter est un framework pour mobile, vous devez donc tout d'abord en apprendre davantage sur le développement des connaissances mobiles.
Sans push de code, vous pouvez utiliser la mise à jour complète.
Comme le dit l'annonce : traverser le pont quand on y arrive.
En tant que développeur, je pense qu'il est plus important d'utiliser différentes méthodes pour résoudre le même problème.

Flutter n'est pas React Native, vous ne pouvez pas utiliser l'expérience de React Native (ou d'un autre framework) pour regarder Flutter. Ce sont des choses différentes.

@MaxZeng Peut-être que le flutter peut activer la mise à jour à chaud exclusivement pour Android.

Sans mise à jour chaude comme RN, nous ne passerons pas à Flutter ! Les frameworks devraient faciliter la vie d'un développeur !!

Les fleurs que j'attendais sont toutes parties.

@MaxZeng Peut-être que le flutter peut activer la mise à jour à chaud exclusivement pour Android.

1、En fait, cela endommagera également les écosystèmes de Google Play Store, cela rendra l'équipe Android difficile à contrôler les comportements de l'application.
2、CodePush n'est pas nécessaire pour la plupart des applications，cette technologie sera malicieusement utilisée par certains développeurs.
3、Cela pourrait provoquer une grande « attaque de l'homme au milieu » si les développeurs ne chiffrent pas correctement les correctifs. Des pirates informatiques malveillants peuvent modifier le code poussé pour pirater les applications Flutter.

Je veux juste dire que le correctif est une fonctionnalité d'importation pour la plupart des entreprises chinoises. plus de 70% des appareils Android chinois ne prennent pas en charge Google Play

@act64 vérifier https://github.com/flutter/flutter/wiki/Roadmap

@act64 vérifier https://github.com/flutter/flutter/wiki/Roadmap

La feuille de route dit correctif sur Android. J'espère que l'iOS sera bientôt pris en charge.

@taibaiyinxing Flutter ne peut cependant pas fournir de fonctionnalités interdites par l'App Store d'Apple.

@taibaiyinxing Flutter ne peut cependant pas fournir de fonctionnalités interdites par l'App Store d'Apple.

@zoechi Nous utilisons une application d'entreprise et nous n'avons pas besoin de télécharger sur l'App Store.

Correctif dynamique sur Android, permettant le déploiement de mises à jour de code sur les applications Flutter s'exécutant sur Android directement à partir d'un serveur.
??

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

Il semble qu'il n'y ait pas de plan pour prendre en charge CODE PUSH sur IOS cette année.

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

"La liste ici ne doit pas être considérée comme exhaustive, ni comme une promesse que nous terminerons tout ce travail." :)

Le travail de poussée de code n'en est qu'à ses débuts de test. Les plates-formes sur lesquelles nous déploierons/ne déploierons pas ce travail en 2019 ne sont pas encore déterminées. On n'est qu'en février après tout. 10 mois c'est long !

Actuellement, les ingénieurs se concentrent sur le développement de la technologie de base pour prendre en charge les 3 cas d'utilisation @Hixie décrits dans : https://github.com/flutter/flutter/issues/14330#issuecomment -442274897
Je m'attends à ce que nous commencions à faire des tests limités sur au moins un de ces cas d'utilisation dans les mois à venir.

Parce que notre technologie de développement flutter n'est pas très mature, l'APP est fréquemment mis à jour, et beaucoup sont des mises à jour urgentes. Et notre application ne prévoit pas de télécharger une boutique d'applications. Cette fonctionnalité est donc très importante. Cela peut améliorer la vitesse d'itération de l'APP. Sinon, la fragmentation de l'APP retarde notre API.

Comme je pense que nous pouvons tous être d'accord, le moteur de ce problème est que la fourniture de n'importe quelle application mobile aux utilisateurs finaux via les jardins clos gérés à la fois par Google et Apple (les magasins) est un inconvénient majeur pour les développeurs d'applications (sans parler service médiocre aux utilisateurs finaux d'applications bonnes/innovantes), Apple étant le plus gênant (jours pour Apple contre heures pour Google).

En parallèle, une solution possible pourrait être que les magasins fournissent un chemin pour des mises à jour instantanées pour les développeurs « de confiance » (comme un service accéléré). Google et Apple pourraient alors faire un audit en temps réel (automatisé,... comme avec l'IA ??... avec auto-rollback post-facto si nécessaire) de l'application. Mais cela semble peu probable pour un tas de raisons techniques et autres. Les deux magasins ont bien sûr une voie rapide pour les bêta-testeurs.

Alors... en attendant les fonctionnalités de ce numéro, une façon d'atténuer les désagréments liés à la livraison d'une application mobile aux utilisateurs finaux consiste à automatiser les étapes.

Pour un exemple d'outil qui effectue ce type d'automatisation pour Flutter, voir :
https://github.com/mmcc007/fledge
Pour mémoire, il comprend de la documentation pour de nombreuses étapes de configuration uniques impliquées qui ne peuvent pas être facilement automatisées :
https://mmcc007.github.io/fledge/

@charliezzo À l'aide de cet outil ou d'outils similaires, une application Flutter (et des mises à jour, etc.) peut être fournie aux bêta-testeurs Android et iOS en quelques minutes.

Il dispose également d'un workflow pour automatiser la livraison aux utilisateurs finaux via les magasins (heures+ pour Google, jours+ pour Apple 😂👍).

@mmcc007
Oh merci. mais je dis que je ne veux pas pousser mon application vers Google Play et App Store.
Je dois vendre mon application d'une autre manière.
et je n'ai pas besoin de Google Play et de l'App Store pour mettre à jour mon application.
Je veux seulement mettre à jour mon application par elle-même lorsque les utilisateurs l'ont installée et la démarrent.
et, Flutter est un cadre 60FPS ou supérieur, il peut créer un jeu en ligne, nous ne voulons pas avoir un petit patch par Google Play et App Store.
vous savez que chaque patch en peu de temps par Google Play et App Store est lent et difficile.
en fait, vous savez que nous ne pouvons pas utiliser Google Play en Chine. et l'App Store est très lent.
il y a beaucoup de magasins d'applications comme Google Play en Chine. Nous n'avons pas le temps de pousser la mise à jour sur chaque magasin d'applications.

Code Push devrait être une fonctionnalité principale de Flutter. Mettez-le sur le dessus.

Nous pouvons le faire en remplaçant tous les fichiers dans l'app_flutters sur Android

salut pouvez-vous me donner votre e-mail pour une discussion plus approfondie (notre équipe a également trouvé cette solution) mais cela ne peut fonctionner que lorsque l'application doit être tuée et redémarrer l'application tks @LNeway

salut pouvez-vous me donner votre e-mail pour une discussion plus approfondie, notre équipe a également trouvé cette solution, mais elle ne peut fonctionner que lorsque l'application doit être tuée et redémarrer l'application. tks @LNeway
@KinsomyJS
J'ai aussi fait une démo pour vérifier la faisabilité. Hahaha~

S'il vous plaît partager avec un bref extrait ou un article de blog ou un commentaire ici ou cc [email protected] dans l'e-mail...

@LNeway @KinsomyJS L'un de vous peut-il donner plus de détails s'il vous plaît ?
Merci

@taibaiyinxing Flutter ne peut cependant pas fournir de fonctionnalités interdites par l'App Store d'Apple.

@zoechi Êtes-vous en train de dire que vous et/ou l'équipe Flutter avez une analyse qui conclut qu'une technique de push de code réalisable par Flutter est fondamentalement différente de celle de React-native et est interdite - et donc, à cause d'Apple, pourrait ne jamais arriver sur iPhone ?

Si cette fonctionnalité est ajoutée, sera-t-elle compatible avec la version bêta 1.0.0 ?

@dahabdev

Pour ce que ça vaut, d'après mon expérience avec Ionic, je pense que le "code push" est surestimé, et j'espère que l'équipe Flutter ne passera pas trop de temps à travailler dessus alors qu'il manque encore tant d'autres fonctionnalités basiques et essentielles.

À l'époque où j'ai développé UAVForecast, j'ai utilisé Ionic, attiré par la fonctionnalité "ionic deploy" qui proposait de mettre à jour l'intégralité du contenu de l'application à distance. À l'époque (c'était en 2014), les délais d'examen de l'App Store d'Apple étaient de l'ordre de 2 semaines. Je voulais itérer rapidement, aller vite et casser les choses, comme on dit.

Au début, le "déploiement ionique" était génial, mais bientôt, j'ai remarqué des problèmes majeurs. Cela a semé la confusion chez mes utilisateurs ("l'application dit qu'elle s'est mise à jour, alors pourquoi y a-t-il une autre mise à jour en attente dans le Play Store / App Store ?"); il cassait parfois l'application, par exemple lorsque les métadonnées de l'application (par exemple, les autorisations) étaient modifiées en silence par un plugin Cordova mais n'étaient pas mises à jour par une poussée de code à chaud ; le suivi des numéros de version était délicat et ils se désynchronisaient avec ce que j'avais poussé vers les magasins ; cela m'a rendu paresseux pour les tests, car je pouvais toujours me "déployer ioniquement" à partir de bogues ; et parfois, je finissais par pousser des bogues pires, ceux qui auraient pu être détectés par les équipes de révision d'applications si je leur avais donné la chance de regarder.

Environ un an après la sortie de la première version, les délais d'examen de l'App Store s'étaient considérablement améliorés. Aujourd'hui, cela ne prend que quelques jours, et bien sûr, sur le Play Store de Google, cela peut prendre aussi peu que quelques heures. Compte tenu de tous les problèmes que j'avais rencontrés, j'ai décidé de supprimer la fonctionnalité de "déploiement ionique" de mon application, et avec plusieurs millions de téléchargements maintenant derrière moi, je n'ai pas regardé en arrière.

Bien que j'aime Ionic et que j'apprécie vraiment tout ce que son développeur, Drifty, a fait (merci !), je dirais que Drifty a fait l'erreur d'investir trop de temps dans des fonctionnalités brillantes comme la poussée de code qui attirent les utilisateurs, et pas assez de temps pour obtenir les écrous et boulons du cadre pour éviter les problèmes qui finissent par les chasser. Maintenant dans sa quatrième version, Ionic a été réécrit tellement de fois de manières incompatibles avec l'arrière que j'ai cessé d'essayer de suivre - la dernière version a encore plusieurs problèmes sérieux en suspens qui m'empêchent de mettre à niveau, et je réécris maintenant toute mon application dans Battement.

L'expérience jusqu'à présent a été excellente et je m'amuse beaucoup, mais il y a encore des lacunes et des omissions majeures dans Flutter, en particulier dans les plugins. Par exemple : il n'y a pas d'intégration de champ de texte avec le remplissage automatique de mot de passe, le plug-in Google Maps est rudimentaire (et il existe des bogues de rendu de framework associés), le WebView natif ne prend pas en charge les URL file:// pour le chargement des actifs, la barre d'onglets ne le fait pas prend en charge la transparence ou les arrière-plans dégradés, les cellules du tableau ne prennent pas en charge colspan, ThemeData n'est pas extensible avec des couleurs spécifiques à l'application à utiliser avec l'animation, la seule bibliothèque DateTime entièrement compatible avec le fuseau horaire manque de nombreuses fonctionnalités importantes de moment et de fuseau horaire, il y a tant d'approches de la gestion de l'état sont déroutantes pour les nouveaux arrivants, vous devez fréquemment "nettoyer" pour éviter des exceptions étranges, l'échange à chaud ne fonctionne souvent pas comme il se doit, et je pourrais continuer ...

Je classerais _tous_ ceux-ci comme plus importants que "le push de code", surtout si cela risque d'Apple de rejeter les applications Flutter, si cela nécessite des modifications majeures du cadre du compilateur qui pourraient éventuellement rendre plus difficiles les optimisations qui améliorent les performances des applications (je prendrais un 5 % d'amélioration des performances par rapport au « poussage de code » n'importe quel jour), ou prend du temps pour terminer la fonctionnalité du cadre.

D'un autre côté, je peux voir que certains développeurs peuvent réellement en avoir besoin dans certaines situations, surtout s'ils opèrent en dehors des magasins, donc je peux comprendre l'enthousiasme ici.

@matthewlloyd plein de bons points !

Si vous ne pouvez pas prendre en charge le code Push, existe-t-il un moyen de créer un analyseur pour générer à partir de certains dictionnaires (comme json, xml...) vers Flutter Widget ? Est-ce impossible ou une bonne idée ?

--Est-ce que quelqu'un a une opinion sur celui-ci?
https://pub.dartlang.org/packages/dynamic_widget
il semble prometteur, même s'il ne résout pas la peur du "bug critique".

C'est la partie folle, c'est que la poussée de code est l'éléphant dans la pièce, c'est profondément un problème commercial/de processus et technique, et un côté a tendance à ignorer l'autre...

il n'y a pas d'intégration de champ de texte avec le remplissage automatique de mot de passe, le plugin Google Maps est rudimentaire (et il existe des bogues de rendu de framework associés), le WebView natif ne prend pas en charge les URL file:// pour le chargement des actifs, la barre d'onglets ne prend pas en charge la transparence ou arrière-plans dégradés, les cellules de tableau ne prennent pas en charge colspan, ThemeData n'est pas extensible avec des couleurs spécifiques à l'application à utiliser avec l'animation, la seule bibliothèque DateTime entièrement compatible avec le fuseau horaire manque de nombreuses fonctionnalités importantes de moment et moment-fuseau horaire, il y a tellement d'approches pour la gestion de l'état, c'est déroutant pour les nouveaux arrivants, vous devez "nettoyer" fréquemment pour éviter des exceptions étranges, l'échange à chaud ne fonctionne souvent pas comme il se doit, et je pourrais continuer...

Espérons que tous ceux-ci ont déjà un problème Github :D

Cela figurait auparavant sur notre feuille de route pour 2019. Après avoir étudié cela plus en détail, nous avons décidé de ne pas poursuivre ce travail pour le moment.

Plusieurs facteurs nous ont amenés à prendre cette décision :

• Pour se conformer à notre compréhension des politiques de magasin sur Android et iOS, toute solution serait limitée au code JIT sur Android et au code interprété sur iOS. Nous ne sommes pas convaincus que les caractéristiques de performance d'une telle solution sur iOS atteindraient la qualité que nous exigeons de notre produit. (En d'autres termes, "ce serait trop lent".)

• Il y a de sérieux problèmes de sécurité. Étant donné que ces correctifs permettraient essentiellement l'exécution de code arbitraire, ils seraient des vecteurs de logiciels malveillants extrêmement attrayants. Nous pourrions atténuer cela en exigeant que les correctifs soient signés à l'aide de la même clé que le package d'origine, mais cela est sujet aux erreurs et toute erreur aurait de graves conséquences. C'est, fondamentalement, le même problème qui a tourmenté les plates-formes qui permettent l'exécution de code à partir de sources tierces. Ce problème pourrait être atténué en s'intégrant à un mécanisme de mise à jour de plate-forme, mais cela va à l'encontre de l'objectif d'un mécanisme de correction hors bande.

• Il n'existe actuellement aucune solution d'hébergement open source prête à l'emploi pour appliquer des correctifs. aurait à créer notre propre solution sur mesure. L'hébergement de correctifs est un espace dans lequel nous ne sommes pas impatients d'entrer. Le fait que les gens configurent leur propre serveur les expose à des erreurs avec des implications potentiellement graves, comme expliqué dans le point précédent sur la sécurité. Le fait de dépendre de services tiers place Flutter dans une position délicate, car il doit choisir des gagnants et nous expose au risque que ces projets eux-mêmes modifient les politiques qui affecteraient cette fonctionnalité.

Nous préférons consacrer nos efforts d'ingénierie à d'autres problèmes pour le moment. Nous prévoyons de continuer à expérimenter dans cet espace et deviendrons probablement à nouveau sérieux à ce sujet à l'avenir (par exemple, nous aurons probablement besoin d'une solution de mise à jour pour les applications de bureau), mais probablement pas cette année.

Bien que je comprenne la raison de l'abandon de cette fonctionnalité, elle est toujours décevante. Le Play Store et l'App Store sont des considérations importantes, mais toutes les applications ne sont pas distribuées de cette façon. Pour notre cas d'utilisation, nous fournissons au client à la fois l'appareil et l'application préinstallés. Avoir un mécanisme pour envoyer dynamiquement les mises à jour à l'utilisateur est une fonctionnalité très importante car nous ne voulons pas passer par les magasins. Cette fonctionnalité aurait été inestimable. J'espère qu'il sera réexaminé à l'avenir comme vous l'avez mentionné.

Merci d'avoir communiqué de manière transparente le rationnel de l'équipe.

@eseidelGoogle Le code JavaScript compilé à partir de Dart pourra-t-il utiliser Skia pour afficher les pages ?

C'est assez décevant.

En ce qui concerne tous les problèmes de sécurité et de conformité des magasins que vous avez mentionnés, ils peuvent être valides et légitimes, mais en fin de compte, il existe un exemple de technologie de « mises à jour à chaud » qui fonctionne déjà : le push de code.

React Native + le service de push de code fonctionne et a fait ses preuves dans le monde réel. C'est testé au combat. Il ne semble y avoir aucun problème avec les magasins d'applications concernant les mises à jour indirectes. Il semble que tout le monde est "d'accord" avec ça. Je pense donc que la solution de Flutter pourrait également être autorisée.

En ce qui concerne les problèmes de performances, il peut être judicieux de laisser le développeur choisir de travailler en mode "faible performance" mais d'activer les mises à jour en direct.

Un bon coup ! Je préfère que l'effort d'ingénierie soit consacré à l'optimisation de Flutter plutôt qu'à l'ajout d'une fonctionnalité de poussée de code qui peut trop compliquer et nuire à l'écosystème

J'ai actuellement ma toute première application, développée dans Flutter, dans le cadre des tests bêta ouverts et j'ai poussé environ 10 bundles d'applications avec des correctifs. Mais il devrait être principalement exempt d'erreurs lorsque je le publie en production.

Je ne sais donc pas si j'aurai un jour besoin de cette fonctionnalité, mais j'ai trouvé ce package de pub OTA Update qui semble bien se porter sur le score de 89, qui n'est amoindri que par sa popularité. Ce colis est-il sécurisé ? Il semble télécharger l'APK à partir d'une URL, le décompresser de manière native et déclencher l'intention d'installation de l'APK sur Android.

Ceux qui ont absolument besoin de cette fonctionnalité peuvent essayer ce package.

Mais je peux voir pourquoi l'équipe Flutter n'est pas trop enthousiaste à ce sujet, car prenons le package ci-dessus au cas où. Il semble télécharger à partir d'une URL. Et un site Web est toujours plus convivial pour les pirates que les applications natives. Il y a trop de problèmes de sécurité pour le moment. Cela rend simplement une application Flutter aussi vulnérable qu'un site Web, ce qui est strictement interdit.

J'avais une machine de 2 Go de RAM à mes débuts, essayant de développer une application Android comme je l'ai toujours voulu, mais ma machine n'était pas à la hauteur. J'ai essayé PhoneGap, Cordova, un framework Intel, React-Native, et aucun d'entre eux n'a même commencé à fonctionner. Flutter était le seul avec qui j'ai réellement commencé et avec sa belle interface utilisateur et ses outils de développement, il a des kilomètres d'avance sur ses contemporains, même sans cette fonctionnalité.

Toute mise à jour?

Le flux de travail de publication d'applications ne sera plus jamais le même après que la manière dont react-native nous a gâtés avec Code Push. Vraiment dommage que Flutter ne le soutienne pas. Flutter se présente bien et cela aurait pu être un concurrent de React Native s'il avait choisi de prendre en charge cette fonctionnalité. Hélas...

@Hixie OK, donc un changement d'ingénierie/technique fondamental a trop d'inconvénients pour le moment - cela a du sens pour moi.

Cependant, que pensez-vous d'aider les développeurs à faire flotter cette préoccupation commerciale à court et à moyen terme avec des approches alternatives qui obtiennent de la documentation/des discussions - peut-être même des vidéos, bien qu'il ne s'agisse peut-être pas d'une solution "approuvée" ou officielle, mais d'une certaine attention.

par exemple

• Configuration en temps réel de Firebase
• Basé sur le serveur json->widgets (par exemple https://github.com/dengyin2000/dynamic_widget/blob/master/WIDGETS.md ou simlar, je n'approuve pas encore le plugin exact mais l'idée)
• ou peut-être autre chose, peut-être des fonctions cloud pour les utilisateurs avancés...
• évidemment, je ne suggère pas que vous fassiez beaucoup d'efforts d'ingénierie pour un "gros" cas d'utilisation, mais une sorte d'alternative hello-world-code-push-alternative qui répond à la plupart des besoins sans "réparons/changeons chaque chose ' type architecture.

ma prémisse est que "nous" pouvons répondre à 70-90% du problème de codepush sans un changement d'architecture fondamental pour le flutter ; qu'est ce que quelqu'un en pense ?

L'approche code-as-ui de Flutter pourrait même rendre cela plus facile que pour les développeurs Android...

J'ai vu personnellement au moins deux entreprises qui ont choisi les autres gars plutôt que de flotter juste pour cette raison, et beaucoup d'autres ont parlé de la même manière.

Peut-être que la conversation pourrait aller
« Utilisateur : ignorez-vous la prise en charge de codepush »
"Équipe Flutter : Oui-pour l'instant, pour ces raisons, (comme vous l'avez fait) mais en plus, vous pouvez essayer A ou B pour certains cas d'utilisation"

Désolé pour le long commentaire

@neiljaywarner Peut-être que LUA vaut le détour pour vous - j'ai fait une preuve de concept l'année dernière dans laquelle les scripts LUA pourraient être utilisés pour créer/ajuster les fonctionnalités d'une application Flutter.

@neiljaywarner Je suis tout à fait favorable à ce genre d'approche, mais c'est une préoccupation orthogonale par rapport à ce que ce bogue couvre.

Bien que je comprenne les raisons de l'abandon de cette fonctionnalité, elle reste décevante. Le Play Store et l'App Store sont des considérations importantes, mais toutes les applications ne sont pas distribuées de cette façon. Pour nos cas d'utilisation, nous fournissons aux clients des appareils et des applications préinstallés. Disposer d'un mécanisme permettant de transmettre dynamiquement les mises à jour aux utilisateurs est une fonctionnalité très importante car nous ne voulons pas passer par le magasin. Cette fonctionnalité est très précieuse. J'espère le réexaminer comme vous l'avez mentionné à l'avenir.

Merci de communiquer la rationalité de l'équipe en toute transparence.

je suis d'accord

la fonctionnalité de poussée de code signifie plus d'applications, plus de clients, plus de développeurs, plus de tests, plus de corrections de bogues, moins de problèmes

Pour le MVP d'une startup ou les applications en croissance, les mises à jour ou la correction de bogues sont cruciales, tandis que les performances sont moins préoccupantes la plupart du temps. Cela entraînera des avantages et des inconvénients pour l'écosystème Flutter. Le déclin de l'adoption, des startups et des développeurs personnels est important pour la croissance de la communauté à un stade précoce. Les avantages pourraient être les applications et les équipes de qualité qui passeraient à Flutter qui visent des performances plus élevées ?

@maplerichie , d'accord, la raison pour laquelle j'aime flutter est l'expérience développeur, les performances et la multiplateforme pour tous les appareils. Cela ne me dérange pas si le code-push ne sera pas implémenté (peut-être), c'est pour la réputation et la popularité de l'écosystème. Maintenant, je sais pourquoi la poussée de code semble trop lente lors de l'utilisation d'applications Windows (démarrage lent, retard d'entrée et animation lente) ici

nous avons vraiment besoin de cette fonction
Besoin d'une mise à jour à chaud

Comme d'autres l'ont déjà mentionné, les grandes entreprises et les grandes équipes de développement peuvent ne pas avoir besoin de mises à jour à chaud. Mais pensez à une petite startup, à quelques développeurs travaillant sur une application mobile, fournissant des fonctionnalités à la production avec des cycles de publication rapides. Il n'y a pas de temps pour les tests et les cycles d'AQ. Créez une nouvelle fonctionnalité, voyez si elle fonctionne et si les utilisateurs l'apprécient, remplacez-la ou réparez-la. Nous ne pourrions pas arriver là où nous en sommes sans mises à jour à chaud. C'est un véritable changeur de jeu pour le développement mobile.

@yaronlevi Je suis une "petite startup", encore moins que quelques développeurs travaillant sur une application mobile, c'est juste moi, et je livre en production avec des cycles de publication rapides. Avec le Google Play Store proposant des mises à jour qui ne prennent que quelques heures, et l'App Store d'Apple examinant les mises à jour presque toujours moins de 24 heures selon mon expérience ces jours-ci, pour ma part, je n'ai certainement pas besoin de pousser le code. Si Flutter avait un push de code, je prendrais activement des mesures pour m'assurer qu'il était désactivé dans mon application.

Je suis actuellement le seul développeur d'une application mobile (et le back-end correspondant) pour une petite entreprise. J'aime vraiment Flutter, mais je dois constamment expliquer à un client qui ne comprend pas le besoin de tests unitaires ou de tests d'automatisation pourquoi il faut si longtemps pour mettre en œuvre des fonctionnalités qui peuvent être décrites en 10 mots. Je suis un peu inquiet de devoir publier quelque chose à moitié cuit et de ne pas être en mesure de pousser rapidement les corrections de bogues critiques. Je vais m'en passer pour l'instant, mais le push de code serait définitivement sympa à avoir. Cependant, je comprends les défis techniques et les problèmes de sécurité et au final, je soutiens une approche prudente.

bien, merci quand même.
Je suppose que nous devons le découvrir par nous-mêmes.

vraiment décevant :)

Flutter for web SDK va bientôt fusionner avec le SDK mobile. Une solution de contournement consiste à utiliser une WebView mobile pour charger le code de flutter. ??

@matthewlloyd salut mec, il est nécessaire de prendre en charge la mise à jour à chaud, le point n'est pas pour le moment de revoir. L'utilisateur doit être lié à l'AppStore et télécharger à nouveau l'application.

Peut-être aider
https://github.com/dengyin2000/dynamic_widget
https://github.com/neohelden/Flutter-AdaptiveCards

Je ne vois pas vraiment de problème urgent à ne pas avoir de push de code. Presque tous les utilisateurs ont la mise à jour automatique sur leur app store. Fournir une solution alternative pour distribuer les mises à jour sans App Store serait bien cependant.

MXFlutter utilise JavaScript pour implémenter les capacités de rendu de Flutter, prend en charge la syntaxe Flutter et prend en charge la diffusion de code et la mise à jour à chaud.
https://github.com/TGIF-iMatrix/MXFlutter

@TGIF-iMatrix savez-vous si cette solution est conforme à la politique de distribution de Store ?

@truongsinh
C'est sûr car il s'agit d'une approche de distribution js -> analyseur natif -> composition de widgets.

nous envisagerons d'utiliser flutter s'il prend en charge le push de code

@TGIF-iMatrix Il est fort probable que cela ne soit pas approuvé par Apple, car l'exemption pour les mises à jour Javascript Core a été supprimée des accords App Store, et de nombreux utilisateurs de CodePush ont été avertis/refusés à cause de cette fonctionnalité.

Peut-être devrions-nous reformuler la question, « rendu séparé-dicté » contre « poussage de code ». "sever-dictated-rendering" concerne uniquement une interface utilisateur/une mise en page/un thème différents, tandis que la poussée de code implique également un changement de logique, d'autorisation, de plugins, etc.

Peut-être, mais à ce stade, vous pouvez simplement utiliser un plug-in pour le faire, donc cela va à l'encontre du but de ce problème.

Quelqu'un a-t-il essayé tinker-lib avec flutter qui provient de tencent github repo et si quelqu'un est intéressé, je peux collaborer avec vous, j'ai essayé de pousser la mise à jour, mais de petites modifications sont nécessaires pour charger un nouveau code qui devrait être fait en flutter. fichier d'artefact jar

J'espère avoir une solution au plus vite

En ce qui concerne les implications en termes de performances de la mise en œuvre du push de code, la compilation du code Dart sur WebAssembly serait-elle utile ? Cela peut permettre d'implémenter la compilation JIT dans iOS à l'intérieur du bac à sable JavaScript.

nous avons besoin d'une itération rapide et d'un développement agile.
s'il n'y a pas de mise à jour à chaud, le flutter est toujours un frère cadet pour réagir natif.

La mise à jour à chaud est très importante pour nous, si Flutter prend en charge la mise à jour à chaud, nous utiliserons Flutter pour remplacer la réaction native.

J'avais prévu le meilleur moyen possible pour le push de code, mais en raison de contraintes de temps, je ne peux démarrer ce projet qu'à partir de novembre de la semaine dernière ou à partir de décembre, je ne modifie aucun code moteur ou code cadre ni aucun code Java comme Tinker lib, il ne viole donc pas tous les termes de magasin, l'application de sortie est également aot donc pas de régression des performances, j'essaie de rendre la mise en œuvre aussi facile afin que tout le monde puisse se connecter à son application, sur la base de mes recherches sur l'équipe de flutter de base de code est intentionnellement rendu impossible de faire pousser le code i J'ai essayé toutes les possibilités avec la mise en œuvre actuelle et j'ai conclu que seules les manières possibles de modifier le moteur ou de préparer une solution sans modifier le moteur, j'ai opté pour la 2ème option et j'ai planifié toutes les exigences nécessaires pour le projet. J'espère que le projet aboutira. En attendant, si l'équipe Flutter réévalue le problème, nous sommes tous satisfaits de la mise en œuvre intégrée.

La mise à jour à chaud sera toujours nécessaire！

c'est un must-have, une fonctionnalité cruciale

J'avais prévu le meilleur moyen possible pour le push de code, mais en raison de contraintes de temps, je ne peux démarrer ce projet qu'à partir de novembre de la semaine dernière ou à partir de décembre, je ne modifie aucun code moteur ou code cadre ni aucun code Java comme Tinker lib, il ne viole donc pas tous les termes de magasin, l'application de sortie est également aot donc pas de régression des performances, j'essaie de rendre la mise en œuvre aussi facile afin que tout le monde puisse se connecter à son application, sur la base de mes recherches sur l'équipe de flutter de base de code est intentionnellement rendu impossible de faire pousser le code i J'ai essayé toutes les possibilités avec la mise en œuvre actuelle et j'ai conclu que seules les manières possibles de modifier le moteur ou de préparer une solution sans modifier le moteur, j'ai opté pour la 2ème option et j'ai planifié toutes les exigences nécessaires pour le projet. J'espère que le projet aboutira. En attendant, si l'équipe Flutter réévalue le problème, nous sommes tous satisfaits de la mise en œuvre intégrée.

J'avais prévu le meilleur moyen possible pour le push de code, mais en raison de contraintes de temps, je ne peux démarrer ce projet qu'à partir de novembre de la semaine dernière ou à partir de décembre, je ne modifie aucun code moteur ou code cadre ni aucun code Java comme Tinker lib, il ne viole donc pas tous les termes de magasin, l'application de sortie est également aot donc pas de régression des performances, j'essaie de rendre la mise en œuvre aussi facile afin que tout le monde puisse se connecter à son application, sur la base de mes recherches sur l'équipe de flutter de base de code est intentionnellement rendu impossible de faire pousser le code i J'ai essayé toutes les possibilités avec la mise en œuvre actuelle et j'ai conclu que seules les manières possibles de modifier le moteur ou de préparer une solution sans modifier le moteur, j'ai opté pour la 2ème option et j'ai planifié toutes les exigences nécessaires pour le projet. J'espère que le projet aboutira. En attendant, si l'équipe Flutter réévalue le problème, nous sommes tous satisfaits de la mise en œuvre intégrée.

Salut @canewsin
J'ai également essayé de faire la même chose en ne modifiant pas le moteur de flutter. J'ai découvert qu'en mode AOT, le moteur recherche les fichiers .so dans le chemin d'accès de la bibliothèque native d'Android, en modifiant/ajoutant un fichier après la compilation de l'application est restreint par JVM. Par conséquent, le chargement des fichiers .so téléchargés par liaison radio n'a pas pu être ajouté au chemin natif de la bibliothèque.

En attente de plus d'informations de votre part. ??

Je pense qu'il n'est pas nécessaire de mettre à jour à la fois le code Dart et le code natif.
Seul le code fléchette est bon !

Hé, j'en ai besoin maintenant. Goodle a renforcé sa politique d'examen. La mise à jour de notre application prend maintenant 2 semaines... Notre méthodologie Lean va à la merde avec ça.

@NEELANSHSETHI pouvez-vous publier le plan ici ? Nous pouvons commencer à le mettre en œuvre

@almeynman Veuillez nous tenir au courant de vos progrès :)

@HerrNiklasRaab Je n'ai pas encore commencé avec cela, car je n'ai pas d'image claire sur la façon de le mettre en œuvre. Si quelqu'un a des idées, merci de partager vos impressions

C'est la principale raison pour laquelle nous n'avons pas migré de la réaction native au flutter. :(

??

ReactNative est très en avance sur Flutter grâce à cette fonctionnalité et j'ai eu plein de projets où le choix de l'environnement (RN ou Flutter) était décodé par rapport à la fonctionnalité push code ! En attente d'une news :/

Salut à tous c'est déjà novembre comme je l'ai dit j'ai commencé mon travail ça se passe bien. Ce sera un projet privé, je vais donc facturer une clé de licence pour l'utiliser. Donc, ce ne sera pas gratuit, puisque je n'ai aucune source de revenu, je dois faire de cette façon, si vous êtes intéressé, je créerai un référentiel de suivi sur le travail, suivez-le pour les mises à jour. Une fois que j'aurai créé le référentiel de la chronologie, je vous informerai les gars.

@eseidelGoogle
Business case:
Nous avons une application de suivi des bus sur les tablettes mais la mise à jour du client 1 fois par mois car la tablette utilise les données Internet et non le wifi
Avec Code Push, nous pourrons mettre à jour sans trop consommer les données clients

Nous avions l'application cordova avec prise en charge du push de code. Lorsqu'il s'est agi de moderniser l'application, nous avons pensé à tort que Flutter ajouterait "de toute façon" la prise en charge du push de code. Nous avons donc développé notre application à l'aide de Flutter. Mais la vie sans code push a été totalement terrible pour nous l'année dernière. Nous sommes donc enfin (et heureusement) en train de (ré)écrire l'application en react-native pour que notre code repousse la prise en charge.

Code Push, c'est pourquoi j'apprends React-Native maintenant.

Si vous êtes intéressé par ma mise en œuvre
suivre le rapport d'avancement ici
https://github.com/canewsin/flutter-code-push-timeline
veuillez lire tous mes commentaires ci-dessus avant de continuer.

Code Push, c'est pourquoi je resterai toujours avec React-Native.

Veuillez ne pas publier de messages non constructifs, +1, "Nous avons besoin de ceci", "Nous utilisons X à la place", etc, car ce n'est pas constructif et ne contribue pas à la discussion.

Vous aurez un bien meilleur impact en cliquant sur le bouton Thumbs Up ( 👍 ) sur le premier message, sans que tous ceux qui ont déjà posté sur cette discussion en soient avertis (pour autant que je sache, certains membres de l'équipe flutter couperont le son gros fils, donc poster ici a moins d'effet qu'un pouce levé).

Je tiens également à rappeler à tous ceux qui sont abonnés ici que github a un bouton unsubscribe en haut à droite du fil.

De plus, l'équipe Flutter hiérarchise les problèmes en fonction du nombre de pouces levés, donc obtenir ce compteur haut peut faire un gros problème. Cela et un simple clic sur "s'abonner" suffisent.

Le projet de poussée de code que j'ai entrepris se passe bien, mais je veux quelques exemples d'exigences de poussée de code, donc si la poussée de code est terminée, comment l'utilisez-vous, publiez votre exigence unique en tant que nouveau problème dans ce référentiel https://github.com/ canewsin/flutter-code-push-timeline afin que le développement soit sur la bonne voie.
les limitations que j'ai trouvées jusqu'à présent sont:
nous ne pouvons pas accéder à la plate-forme native, mais cela peut être fait via la fonctionnalité ffi.
Le code codepush s'exécute dans un bac à sable pour certains problèmes de sécurité, de sorte qu'aucun dommage ne peut être causé à l'appareil.

Salut à tous c'est déjà novembre comme je l'ai dit j'ai commencé mon travail ça se passe bien. Ce sera un projet privé, je vais donc facturer une clé de licence pour l'utiliser. Donc, ce ne sera pas gratuit, puisque je n'ai aucune source de revenu, je dois faire de cette façon, si vous êtes intéressé, je créerai un référentiel de suivi sur le travail, suivez-le pour les mises à jour. Une fois que j'aurai créé le référentiel de la chronologie, je vous informerai les gars.

Très intéressant!
Bonjour, avez-vous des exemples ? Et comment gérez-vous la section iOS ? depuis Apple très strict dans ce domaine. Merci

Salut à tous c'est déjà novembre comme je l'ai dit j'ai commencé mon travail ça se passe bien. Ce sera un projet privé, je vais donc facturer une clé de licence pour l'utiliser. Donc, ce ne sera pas gratuit, puisque je n'ai aucune source de revenu, je dois faire de cette façon, si vous êtes intéressé, je créerai un référentiel de suivi sur le travail, suivez-le pour les mises à jour. Une fois que j'aurai créé le référentiel de la chronologie, je vous informerai les gars.

Très intéressant!
Bonjour, avez-vous des exemples ? Et comment gérez-vous la section iOS ? depuis Apple très strict dans ce domaine. Merci

travaille actuellement avec le côté Android, même si le côté ios est stupide, similaire à la version en bac à sable des applications js réactives, le code s'exécutera dans le bac à sable sans accéder aux apis de la plate-forme, donc ce ne sera peut-être pas le problème quand il sera prêt pour le côté ios.

Salut @eseidelGoogle
Les mises à jour? Chronologie?

Salut @eseidelGoogle
Les mises à jour? C'est décembre est une fonctionnalité qui sortira en 2019 ?

J'ai posé une question à un sujet de l'AMA à ce sujet. Peut avoir des informations utiles.
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 j'ai lu ton article sur 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

Je me demande si les mises à jour de l'application Flutter seront de petite taille si je les publie en tant qu'abb "Android App Bundle" dans Google Play ou si elles sont uniquement destinées au code natif ?

Il s'agit d'une fonctionnalité importante pour les versions d'entreprise (applications distribuées en dehors des magasins, par exemple via des portails Web)

C'est une fonctionnalité très demandée. Pourquoi ne pouvons-nous pas l'avoir officiellement ? Qu'est-ce qui l'empêche de donner cette fonctionnalité ?

est-ce dans la feuille de route 2020 ?

Non

2020 et toujours en attente

Veuillez lire ceci avant de poster ci-dessous.

Voici un petit récapitulatif si vous ne voulez pas faire défiler vers le haut pour comprendre :

Comme cela a été souligné dans ce commentaire , les trois grands défis sont :

• Qu'est-ce qui est poussé
• Est-il sûr pour les utilisateurs
• D'où il est poussé

Le premier, _what_ est poussé, est l'endroit où se trouve le plus gros problème. Les directives d'examen d'Apple interdisent tout type de push de code, quel qu'il soit . Oui, la terminologie utilisée _inclut également le code javascript push._ Apple n'a apparemment pris aucune mesure contre cela, et il peut y avoir de nombreuses raisons à cela, mais toutes les raisons publiées ici seraient de la pure spéculation.

Les propres directives du Play Store de Google

Flutter, du moins en mode release, est compilé , et même s'il ne l'était pas, n'est pas javascript , il ne peut donc pas être interprété sur iOS sans enfreindre l'exigence "pas de JIT", ou être très lent.

Le second, est-il _sûr_ pour les utilisateurs, est à peu près toute la logique derrière la logique des magasins pour interdire le téléchargement de code dynamique et non contrôlé. Autoriser n'importe qui à télécharger n'importe quoi de n'importe où et _juste l'exécuter_ met les utilisateurs en danger. Même dans un bac à sable, où les privilèges spéciaux de JavascriptCore autour du push de code sont mis en évidence, ce n'est toujours pas sûr.

Le push de code vous permet de contourner le processus de vérification des magasins, ce qui signifie que le code h non vérifié s'exécute sur les appareils des utilisateurs, ce qui signifie qu'il est possible de déformer l'application d'origine, ou même d'ajouter des fonctionnalités nuisibles telles que le siphon de données ou les exploits qui le processus de vérification aurait attrapé .

Vous pouvez avoir les meilleures intentions du monde, il y aura toujours quelqu'un pour vous poignarder avec eux.

Pour l'instant, sur Android, si vous n'utilisez pas le Play Store pour distribuer, vous pouvez simplement créer un téléchargeur qui récupérera un apk et invitera l'utilisateur à l'installer. Sur iOS, eh bien, vous ne pouvez effectivement pas charger de côté sans une tonne de douleur, et les appareils JB ne se soucient pas des restrictions de l'App Store.

Maintenant, est-il possible de l'implémenter pour d' autres plateformes qu'iOS ou Android ? Sûr! Mais Desktop n'est pas encore en version bêta (d'ailleurs, vous pouvez également créer vous-même votre propre mise à jour automatique sur le bureau) et, Web, eh bien, actualisez simplement la page.

Maintenant, si vous voulez que l'équipe jette un œil, allez au premier post et ajoutez un 👍.

Si votre commentaire fait partie de la liste ci-dessous, veuillez reconsidérer sa publication.

• Demander quand/si c'est dans la feuille de route
• "Ce n'est pas là" (et des variantes, comme le commentaire précédent à celui-ci)
• "Nous utilisons le framework X car pas de push de code"
• "Framework X est meilleur parce que le code push"
• « Nous avons besoin de pousser le code »
• "Mises à jour?"
• Les arguments pour le push de code qui sont
  
  
  
  • Applications d'entreprise/à chargement latéral
  
  
  • Correctif d'urgence
  
  
  • Ajout de fonctionnalités
  
  
• Les arguments contre le push de code qui sont
  
  
  
  • Les durées d'examen du Play/App Store sont plus courtes maintenant
  
  
  • Le Play/App Store l'en empêche
  
  
  • Tu n'en as pas besoin
  
  

Ce numéro est déjà chargé avec suffisamment de commentaires tel quel, veuillez donc ne pas ajouter de commentaires qui n'ajoutent rien à la conversation. Si l'équipe a quelque chose à dire, elle le postera ici, car ce post compte actuellement près de 100 participants et plus de 500 pouces, il n'est pas possible de l'ignorer.

Pour être honnête, je ne pense pas que cela devrait être votre préoccupation. Un développeur utilisera la fonctionnalité à ses risques et périls. Si Apple décide soudainement d'interdire toutes les applications utilisant le push de code, votre application devra alors utiliser une approche différente. Mais cela ne se produit pas pour JavaScript. Cela ne s'est pas produit pendant des années, pourquoi cela arriverait-il pour Flutter ? Ils ne peuvent même pas le vérifier. Les gens demandent cette fonctionnalité parce qu'elle est utile. Vous pouvez écrire de petits modules et les mettre à jour dynamiquement. C'est un changeur de jeu. Vous pouvez corriger un bogue dans un module à la volée. De plus, Apple ne peut pas vraiment vérifier ce que fait une application, elle n'en a pas les ressources. Ce serait impossible, j'espère que vous vous en rendez compte. De plus, à quoi ça sert ? Je peux écrire du code obscur et insérer une porte dérobée dans une application, déclenchée lorsque je fournis un JSON spécifique à la suite d'un appel REST. Comment Apple pourra-t-il le vérifier ? Ça ne peut pas. Il n'y a rien qu'Apple ou Android puisse faire pour arrêter cela. Les gens ont besoin de cette fonctionnalité et vous devez la mettre en œuvre. Ce que nous en faisons, c'est notre affaire, pas la vôtre. Vous l'avez dit vous-même, cette fonctionnalité a plus de 500 pouces levés et plus de 100 participants. Il est peut-être temps de le mettre en œuvre conformément à la demande de la communauté.

@dedalozzo De

Je ne fais pas partie de l'équipe Flutter, alors ne me ciblez pas pour demander des implémentations.

Pourtant, il est vrai qu'Apple et Google n'ont peut-être pas les ressources pour détecter cela (l'équipe de protection contre le jeu est active tout le temps, ils peuvent détecter automatiquement les comportements dangereux), mais l'implémenter "dans leur dos" donne maintenant à Apple une véritable raison d'appliquer une interdiction générale de Flutter, car il est essentiellement livré avec des outils qui vont explicitement à l'encontre de leurs politiques.

Vous pouvez également l'encadrer dans le cadre d'une question éthique (devriez-vous mettre en œuvre quelque chose qui ajoute des risques supplémentaires à une application et va à l'encontre des politiques du magasin, au nom du progrès ?) ou comme une question de planification (devriez-vous travailler sur quelque chose qui a un énorme " Si vous utilisez ceci, il est probable que vous soyez banni de l'app/play store ", que les utilisateurs voudront probablement éviter, et détourneront les ressources d'autres tâches avec un impact sûr et garanti ?).

Non seulement cela, mais enfreindre accidentellement la politique du Play Store/être lié à quelqu'un qui enfreint la politique du Play Store signifie essentiellement que votre compte est banni, ce serait donc jouer avec le feu, rendant les utilisateurs _encore moins susceptibles d'utiliser la fonctionnalité_.

De plus, comme indiqué ci-dessus, la distribution en dehors du Play Store vous permet de pousser les APK mis à jour.

Je suis désolé, je pensais que vous faisiez partie de l'équipe Flutter.

Ce que tu dis dans ton dernier commentaire est vrai. En fait, le push de code semble être toléré par Apple et Google, même s'il est limite et contraire aux règles.

Mais tant que votre application ne fait pas de mal, je ne pense pas qu'ils se donneront la peine de vérifier si vous envoyez réellement du code. Ils pourraient, si quelqu'un signale un comportement étrange. Mais à ce stade, ils prendront des mesures contre le développeur de cette application, et non contre l'ensemble des applications utilisant du code push.

Un travail en cours, mais permet le push de code https://github.com/chgibb/hydro-sdk

@chgibb Attendez... qui permet la poussée de code mais change également le tout de Dart à Typescript?

Existe-t-il un moyen de séparer ces deux choses? Pour obtenir du codepush tout en écrivant Dart comme d'habitude ?

@SpajicM qui ne fonctionne que _parce qu'il n'utilise pas Dart, à la place, il utilise probablement un moteur JS, tel que JavascriptCore, qui appartient à Apple, et ils semblent détourner le regard lorsqu'il est utilisé avec du code push.

Grattez cela, il utilise le bytecode Lua, qui est contraire à la politique du magasin sous toutes ses formes.

@miyoyo pourquoi est-ce spécifiquement contraire à la politique du magasin ?
@SpajicM c'est purement additif. Les pièces dactylographiées peuvent être intégrées dans une application Dart plus grande. Aussi petit que des morceaux de texte ou des écrans entiers.

Il est interdit par la politique du magasin de pousser tout type de code compilé, dont les fichiers .hc semblent être, car ils sont compilés en lua bytecode (peut-être avec des extensions, je n'ai pas vérifié).

Le cas d'utilisation spécifique consistant à envoyer du code _compilé_ aux applications est explicitement contraire à la politique du Play Store , et l'élément « pas de code source fourni » que vous _pouvez_ transmettre au javascript car, dans CodePush, ne s'appliquerait pas, enfreignant les directives d'Apple .

Je ne dis pas que le concept est mauvais, en fait, c'est du bon travail ! C'est juste que le téléchargement de bytecode sur Internet est explicitement contraire à la politique du magasin dans les deux cas.

Comment fonctionnent tous ces jeux mobiles avec leurs mises à jour en jeu ? Est-ce qu'ils envoient/téléchargent uniquement des ressources ?

@miyoyo de la 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...
Les fichiers .hc Hydro-SDK sont du pur bytecode Lua 5.2 sans extensions ni fonctionnalités spéciales. Ils sont exécutés dans un interpréteur sans fonctionnalité d'auto-mutation ou de génération de code. Rien de dart:io est exposé. Bien, il n'y a rien qui empêche un embedder d'exposer dart:io de File classe, ou d' exposer PlatformChannel s par exemple.

La section 2.5.2 d'Apple est un peu plus ambiguë en ce qui concerne la signification du mot « exécuter », ainsi que la modification des caractéristiques ou des fonctionnalités.

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 D'accord, je dirais que cela pourrait passer sur Android, même si je m'attendrais toujours à un rejet sur l'App Store. (Pour ne pas dire la réduction des performances de pointe, mais c'est probablement un détail sur les téléphones haut de gamme)

Les mises à jour du jeu @kuhnroyal Mobile utilisent soit Dynamic Asset Delivery pour les choses non exécutables , celles-ci sont généralement accélérées car elles nécessitent moins de vérification, les fichiers d'extension APK qui vous permettent d'effectuer des mises à niveau partielles, mais sont toujours soumis à des cycles de mise à jour réguliers du magasin et à des mises à jour régulières d'APK .

J'ai parlé avec le client : un titre indiquant que ce n'est plus une priorité pour eux.

Vous pouvez utiliser Localizely pour les mises à jour en direct des textes/traductions : https://localizely.com/flutter-over-the-air

Pour l'amour du flutter, construisez cette fonctionnalité ou guidez-nous sur la façon de la construire. Merci .

Les amis _s'il vous plait_, c'est la troisième fois que ceci est publié, mais _n'envoyez pas de commentaires à moins que vous n'ayez quelque chose à ajouter_ .

Consultez cet article pour plus de détails et pour mettre un pouce bleu sur le premier article.

Les messages n'ont plus d'impact, car je suis presque sûr que la plupart des membres de l'équipe ici ont désactivé les notifications pour ce message, réduisons le bruit _à moins que vous n'ayez quelque chose à ajouter_.

en attendant une alternative pour le push de code ?

en attendant une alternative pour le push de code ?

d'après mon expérience, il n'y a pas d'alternative

@samerdernaika @mfenej bien qu'il ne soit pas tout à fait prêt pour la production, ce projet a été lancé avec une poussée de code comme objectif explicite https://github.com/chgibb/hydro-sdk

@miyoyo

Le premier, _what_ est poussé, est l'endroit où se trouve le plus gros problème. Les directives d'examen d'Apple interdisent tout type de push de code, quel qu'il soit . Oui, la terminologie utilisée _inclut également le push de code javascript. Apple n'a apparemment pris aucune mesure à son encontre, et il peut y avoir de nombreuses raisons à cela, mais toutes les raisons publiées ici seraient de la pure spéculation.

Ce n'est pas vrai. Merci de bien vérifier et de ne pas diffuser de fausses informations !

La section 3.3.2 du contrat de licence développeur d'Apple stipule :

3.3.2 Sauf indication contraire dans le paragraphe suivant, une Application ne peut pas télécharger ou installer de code exécutable. Le code interprété peut être téléchargé sur une application, mais uniquement dans la mesure où ce code : (a) ne modifie pas l'objectif principal de l'application en fournissant des fonctionnalités ou des fonctionnalités qui sont incompatibles avec l'objectif prévu et annoncé de l'application telle qu'elle est soumise à l'application Store, (b) ne crée pas de magasin ou de vitrine pour d'autres codes ou applications, et (c) ne contourne pas la signature, le bac à sable ou d'autres fonctionnalités de sécurité du système d'exploitation.

Ils permettent très spécifiquement de télécharger du code interprété tel que JS tant que vous ne modifiez pas l'objectif principal de l'application. C'est ainsi depuis plus de 5 ans maintenant IIRC et je n'ai jamais entendu parler de quelqu'un qui se fait tirer dessus pour avoir utilisé le codepush de manière normale et responsable.

Jetez un œil à la section d'AppCenter sur la conformité aux directives de push de code et de magasin. AppCenter codepush (soutenu par Microsoft) est utilisé par de nombreuses applications sans problèmes de conformité de magasin. https://github.com/microsoft/react-native-code-push#store -guideline-compliance

Le gros bloqueur de codepush que je vois est qu'il ne vaut peut-être pas la peine d'être obligé d'utiliser compile-to-js ou d'interpréter Dart sur iOS au lieu d'être précompilé. Étant donné que Flutter cible le navigateur, je soupçonne cependant que les performances de compilation en js seraient suffisantes, mais peut-être toujours pas un compromis de performance acceptable pour l'équipe Flutter.

Peut-être qu'une solution tierce (comme AppCenter pour React Native) viendra combler cette lacune. CodePush est super utile !

Hmm, une recherche rapide sur Google révèle de nombreux exemples d'applications rejetant Apple qui incluent la capacité de push de code, voir par exemple

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

Étant donné que les temps d'examen de l'App Store sont maintenant presque toujours mesurés en heures et non en jours, je ne comprends pas pourquoi quelqu'un prendrait le risque. Si le push de code est intégré au moteur Flutter, Apple pourrait décider d'interdire toutes les applications Flutter.

@matthewlloyd, vous avez tout à fait raison de dire que les délais de révision ont diminué. J'ai moi-même soumis une application (propriétaire) à l'App Store ce matin et je l'ai fait approuver d'ici la fin de la journée d'aujourd'hui ! Mais c'est _récemment_. Nous, en tant qu'éditeurs d'applications mobiles, sommes toujours redevables aux caprices/capacités des équipes de révision pour réviser nos soumissions.

Une mise à jour entre les mains de votre utilisateur ne se déplace pas à la vitesse de l'examen de l'application. Le temps entre la "version du développeur", le "traitement de l'App Store", la propagation vers les serveurs de votre marché d'utilisateurs, etc. peut également prendre un certain temps. J'ai vu ces étapes ultérieures prendre plus de 24 heures dans des cas extrêmes.

À titre personnel, ma passion pour la poussée de code consiste à prendre en charge la chaîne d'approvisionnement de livraison des mises à jour. Sans parler des obstacles assez importants impliqués dans la tentative d'automatisation du processus actuel dans une configuration de CD cohérente étant donné l'état déplorable de l'outil CLI xcode .

Moins de 24 heures dans la grande majorité des cas est suffisant pour presque tout le monde, je pense. Si vous avez besoin d'obtenir une mise à jour via le processus de révision d'Apple plus rapidement que cela, par exemple pour une correction de bogue urgente, vous pouvez demander une révision accélérée. Je l'ai fait une fois, et l'examen de l'application était terminé littéralement 10 minutes après que j'ai fait la demande.

S'approprier la chaîne d'approvisionnement de livraison est quelque chose que l'on fait à ses risques et périls...

Directives de l'App Store d'Apple, section 2.5.2 (https://developer.apple.com/app-store/review/guidelines/#software-requirements) :

"2.5.2 Les applications doivent être autonomes dans leurs ensembles et ne peuvent pas lire ou écrire de données en dehors de la zone de conteneur désignée, ni télécharger, installer ou exécuter du code qui introduit ou modifie des fonctionnalités ou des fonctionnalités de l'application , y compris d'autres applications. Les applications éducatives conçues pour enseigner, développer ou permettre aux étudiants de tester du code exécutable peuvent, dans des circonstances limitées, télécharger du code à condition que ce code ne soit pas utilisé à d'autres fins. Ces applications doivent rendre le code source fourni par l'Application complètement visible et modifiable par l'utilisateur."

Exigences du programme de développement d'Apple, section 3.3.2 :

3.3.2 Sauf indication contraire dans le paragraphe suivant, une Application ne peut pas télécharger ou installer de code exécutable.

@AndrewMorsillo Peu importe ce qu'il y a dans chaque directive et peu importe la quantité d'informations fournies, le mieux que nous puissions obtenir est "Il est peut-être permis que nous ne soyons pas sûrs que ce ne soit pas une infraction bannable en fait, il se peut que nous ne soyons pas sûrs" .

Quoi qu'il en soit, Flutter n'exécute aucune fléchette interprétée sur iOS pour le moment, ajouter que ce serait un frein aux performances, et comme vous l'avez vous-même mentionné , en plus de mes articles précédents et de celui de très grise, et au pire c'est juste interdit.

Pour autant que je sache, échanger tout cela pour contourner un cycle d'examen de 24 heures et rédiger des tests n'en vaut pas la peine. (Je pouvais comprendre quand c'était une semaine, et ce n'est généralement que du côté d'iOS, ce qui est effectivement le plus gros point de discorde ici)

Il ne s'agit même pas seulement du processus de révision, il s'agit également des utilisateurs qui restent bloqués sur les anciennes versions de l'application car ils ont peut-être désactivé la mise à jour automatique.

Bien sûr, vous pouvez implémenter vous-même la vérification de la version minimale, mais ils doivent à nouveau passer par le Play Store et les gens sont malheureusement paresseux. Avec le push de code, il pourrait simplement mettre à jour rapidement l'application à chaque exécution (j'espère) et laisser l'utilisateur entrer de manière plus transparente.

@miyoyo Je ne sais pas pourquoi vous ressentez le besoin de répondre à chaque commentaire ou idée présenté ici. Les gens veulent ça. Vous avez dit aux gens de voter pour le problème, et nous l'avons voté jusqu'au sommet. Cela ne sera jamais résolu à moins que quelqu'un y réfléchisse activement et le pousse.

Il y a une autre façon de résoudre ce problème. J'avais vu beaucoup d'applications le faire. App si dehors
de date, affichez un message, fermez-le ou mettez à jour l'application. que tout.

Le vendredi 7 août 2020 à 07h38, SpajicM [email protected] a écrit :

Il ne s'agit même pas seulement du processus d'examen, il s'agit aussi des utilisateurs qui obtiennent
bloqué sur les anciennes versions de l'application car ils ont peut-être désactivé le
mise à jour automatique.

Bien sûr, vous pouvez implémenter vous-même la vérification de la version minimale, mais ils
encore faut-il passer par Play Store et les gens sont malheureusement paresseux. Avec
push de code, il pourrait simplement mettre à jour rapidement l'application à chaque exécution (j'espère) et
laissez l'utilisateur entrer de manière plus transparente.

@miyoyo https://github.com/miyoyo Je ne sais pas pourquoi tu ressens le
besoin de répondre à chaque commentaire ou idée qui est présenté ici.
Les gens veulent ça. Vous avez dit aux gens de voter pour le problème, et nous avons voté pour
tout en haut. Cela ne sera jamais résolu à moins que quelqu'un
y pense activement et le pousse.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/flutter/flutter/issues/14330#issuecomment-670242698 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA
.

Il y a une autre façon de résoudre ce problème. J'avais vu beaucoup d'applications le faire. L'application si obsolète, affiche un message, soit vous la fermez, soit vous mettez à jour l'application. que tout.

Probablement la pire façon UX... :/

@SpajicM

Il ne s'agit même pas seulement du processus de révision, il s'agit également des utilisateurs qui restent bloqués sur les anciennes versions de l'application car ils ont peut-être désactivé la mise à jour automatique.

Bien sûr, vous pouvez implémenter vous-même la vérification de la version minimale, mais ils doivent à nouveau passer par le Play Store et les gens sont malheureusement paresseux. Avec le push de code, il pourrait simplement mettre à jour rapidement l'application à chaque exécution (j'espère) et laisser l'utilisateur entrer de manière plus transparente.

Du point de vue UX, n'est-ce pas une _mauvaise_ façon de gérer les mises à jour ? Si quelqu'un désactive manuellement les mises à jour automatiques, pourquoi Flutter devrait-il annuler cela ? C'est discutable si une application devrait même avoir ce pouvoir, mais certainement pas l'ensemble du cadre.

Je pense que centraliser le processus de mise à jour via les magasins d'applications est préférable pour l'UX car ils peuvent gérer toutes les mises à jour via le magasin. L'UX au détriment du temps du développeur est un peu l'essentiel du développement d'applications. Et si vous avez besoin d'un correctif immédiat (par exemple, pour une vulnérabilité), vous pouvez obtenir une mise à jour accélérée ou refuser de laisser l'utilisateur utiliser l'application jusqu'à ce qu'elle soit mise à jour. Bien sûr, ce dernier n'est pas une bonne option, et le premier est ennuyeux, mais c'est parce qu'Apple et Google donnent la priorité aux utilisateurs et n'ont pas grand-chose à voir avec Flutter lui-même.

@chgibb

À titre personnel, ma passion pour la poussée de code consiste à prendre en charge la chaîne d'approvisionnement de livraison des mises à jour.

C'est un peu le problème avec ce fil – essayer de faire ce contre quoi Apple et Google mettent fortement en garde n'est pas une bonne idée si vous comptez utiliser leurs magasins d'applications. Comme l'a dit @miyoyo , il s'agit au mieux d'une zone grise, qui n'est pas exactement adaptée à un cadre utilisé par Google et d'autres entreprises/individus.

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

C'est en fait https://github.com/microsoft/react-native-code-push

Eh bien, Flutter ne peut toujours pas mettre à jour votre code à chaud, mais en fait, ce lien parlait d'images et cela m'a rappelé que Firebase Remote Config est une chose. L'inconvénient est que vous devez anticiper les morceaux de code qui pourraient avoir besoin d'être modifiés et vous attendre à ces changements dans votre application, mais une fois cela fait, il devrait être assez rapide de déployer de nouvelles modifications sans l'App Store (similaire à ce que fait React Native Code Push avec ses images)

@ardyfeb Les gens comme vous donnent une mauvaise

Il y a une autre façon de résoudre ça
sans utiliser la toile flottante

Il y a une autre façon de résoudre ce problème. J'avais vu beaucoup d'applications le faire. L'application si obsolète, affiche un message, soit vous la fermez, soit vous mettez à jour l'application. que tout.
…
Le ven. 7 août 2020 à 07:38, SpajicM @ . * > a écrit : Il ne s'agit même pas seulement du processus de révision, il s'agit également des utilisateurs qui restent bloqués sur les anciennes versions de l'application car ils ont peut-être désactivé la mise à jour automatique. Bien sûr, vous pouvez implémenter vous-même la vérification de la version minimale, mais ils doivent à nouveau passer par le Play Store et les gens sont malheureusement paresseux. Avec le push de code, il pourrait simplement mettre à jour rapidement l'application à chaque exécution (j'espère) et laisser l'utilisateur entrer de manière plus transparente. @miyoyo https://github.com/miyoyo Je ne sais pas pourquoi vous ressentez le besoin de répondre à chaque commentaire ou idée présenté ici. Les gens veulent ça. Vous avez dit aux gens de voter pour le problème, et nous l'avons voté jusqu'au sommet. Cela ne sera jamais résolu à moins que quelqu'un y réfléchisse activement et le pousse. — Vous recevez ceci parce que vous êtes abonné à ce fil. Répondez directement à cet e-mail, consultez-le sur GitHub < #14330 (commentaire) >, ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/ADS5AJFUU2V6MHQIP7AMZKLR7M5HPANCNFSM4EOFIZRA .

Cela sonne bien... si vous créez des applications bancaires.

Si quelqu'un a besoin de mises à jour en direct uniquement pour les traductions d'applications, voici un exemple d'application Flutter : https://github.com/localizely/flutter-ota-sample-app

Il semble que les directives d'Apple soient différentes de ce qu'elles étaient auparavant ?

C'est toujours pareil

2.5.2 Les applications doivent être autonomes dans leurs ensembles et ne peuvent pas lire ou écrire de données en dehors de la zone de conteneur désignée, ni télécharger, installer ou exécuter du code qui introduit ou modifie des fonctionnalités ou des fonctionnalités de l'application, y compris d'autres applications. . Les applications éducatives conçues pour enseigner, développer ou permettre aux étudiants de tester du code exécutable peuvent, dans des circonstances limitées, télécharger du code à condition que ce code ne soit pas utilisé à d'autres fins. Ces applications doivent rendre le code source fourni par l'Application complètement visible et modifiable par l'utilisateur.

Cependant, je ne trouve aucune autre référence à du code interprété ou exécutable.

Est-il possible que les détails sur l'écosystème de la pomme du message original ne soient plus vrais étant donné qu'ils ne semblent plus rien dire de spécifiquement sur les langages interprétés ou compilés ?