Flutter: Flutter devrait fournir une abstraction pour l'exécution en arrière-plan

Créé le 2 mai 2016  ·  139Commentaires  ·  Source: flutter/flutter

Les clients aimeraient exécuter le code de fléchette en tant que processus d'arrière-plan sur iOS et Android, pour des choses comme la synchronisation des données lorsque le wifi est disponible mais que l'application n'est pas ouverte, etc.

@mpcomplete a créé un processus d'arrière-plan sur Android pour exécuter le code Dart afin de mettre à jour le flutter. Mais je ne suis pas au courant d'un parallèle sur iOS.

Ce problème suit le développement des API dans les plugins ou autres. La prise en charge du moteur pour ces abstractions est suivie dans https://github.com/flutter/flutter/issues/6192.

truckable wellbeing engine framework plugin new feature

Commentaire le plus utile

Mise à jour rapide : l'exécution en arrière-plan pour iOS est implémentée et en cours d'examen (PR flutter/engine#5539). Une fois que cela atterrira, je commencerai à mettre à jour l'exécution en arrière-plan d'Android pour avoir une interface cohérente et publier un exemple de plugin. Nous espérons que tout cela sera fait d'ici la fin du mois.

Tous les 139 commentaires

Le code qui s'exécute en arrière-plan doit-il être écrit en Dart ou en Java/Objective-C ?

Cela s'est produit dans le contexte de la volonté de mettre à jour le modèle de données local lorsque la connectivité était disponible. par exemple, les plans de métro/les heures auxquelles vous pourriez entrer/sortir d'un métro. Je pense donc que l'objectif serait que le code exécuté soit Dart afin que vous n'ayez pas besoin d'avoir un code de manipulation de modèle de données distinct pour chaque plate-forme.

CC @kasperl; nous avons exploré de nombreuses façons d'exécuter du code en arrière-plan sur nos différentes cibles, et peut-être que certains enseignements pourraient en être tirés.

Avons-nous des cas d'utilisation de nos utilisateurs ? Le seul que j'ai entendu était "Nous voulons exécuter du code sur l'appareil, en réponse à un message push. Nous voulons synchroniser les données sur l'appareil, même si l'application n'est pas ouverte."

Il est généralement assez restreint de ce qu'une application est réellement autorisée à faire en arrière-plan, donc dans ce cas, je pense que nous pouvons nous inspirer des cas d'utilisation à partir de là. Par exemple, voici le modèle iOS :
https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html

Je crois que c'est le même bogue que # 6192, oui.

Ajout d'une balise feuillue et d'une valeur de jalon à partir de # 6192

@mravn-google @sigurdm quelque chose à penser !

Attribution à Mikkel pour une toute première enquête afin de mieux comprendre la faisabilité et le coût.

Voici une mise à jour de Leafy :

En raison des limitations des notifications de données (c'est-à-dire des notifications qui nécessitent que l'application réponde d'une manière ou d'une autre), leafy se penche vers l'utilisation de notifications d'affichage (c'est-à-dire des notifications qui sont poussées directement sur l'écran de l'utilisateur sans implication de l'application). La prise en charge de ceux-ci existe déjà dans Flutter.

Cependant, lors de conversations avec d'autres équipes, un autre cas d'utilisation est apparu : si vous souhaitez prendre en charge les appareils portables ou les widgets [écran d'accueil] à partir de votre application, vous devrez écrire l'interface utilisateur en code natif, car ces surfaces ne sont pas encore prises en charge par Flutter. Cependant, il serait bien de pouvoir "réveiller l'application et demander des données" afin que la couche de modèle et la logique métier puissent être partagées entre l'application flottante et l'application portable. N'ayant jamais écrit l'un d'entre eux, je ne sais pas comment les applications natives existantes le font, mais cela semble certainement être un cas d'utilisation valable pour les tâches en arrière-plan.

Je viens de parler à l'auteur de Flutter talk pour Berlin DroidCon, et c'était l'une de ses principales demandes. "Comment faire cela, à la manière Flutter"

Pour être clair, il est actuellement possible d'écrire des processus d'arrière-plan dans le cadre d'une application utilisant Flutter. Cependant, ces processus ne peuvent exécuter que du code Obj-C/Swift ou Java/Kotlin. Ce bogue concerne la correction de la limitation de notre moteur pour permettre l'exécution de code Dart dans ces processus d'arrière-plan, ainsi que la possibilité de fournir une abstraction pour permettre la planification d'un tel travail d'arrière-plan à partir de Dart (qui appartient probablement à un plugin une fois que le FlutterView-doit-à- la restriction d'être à l'écran est supprimée).

https://github.com/flutter/flutter/issues/6192#issuecomment -258928555 discute de la limitation actuelle du moteur et de notre intention de la résoudre. Pour info @a-siva

Ceci est également lié à (un doublon de ?) https://github.com/flutter/flutter/issues/5048.

Nous avons un cas d'utilisation que je ne vois pas mentionné : nous suivons la localisation toutes les 5 secondes et avons certaines autres informations attachées à cet événement, dont la logique métier est implémentée dans Dart. Si notre utilisateur met une autre activité au premier plan, nous devons afficher une notification persistante et continuer à exécuter ce code Dart toutes les 5 secondes.

C'est un blocage pour nous. J'aimerais connaître les solutions de contournement que nous pourrions mettre en œuvre pour le moment, car cela retardera l'expédition.

J'essaierais simplement de laisser la minuterie active et de voir ce qui se passe. Je ne pense pas que ce serait fiable, mais notre application a également un cas d'utilisation de nettoyage de cache unique (15 minutes après que l'application a été mise en arrière-plan) et nous l'avons vue s'exécuter avec succès. Nous le planifions pendant que l'application est arrêtée dans Dart. Quelque chose comme ça:

<strong i="6">@override</strong>
void didChangeAppLifecycleState(AppLifecycleState state) {
    if (state == AppLifecycleState.paused) {
        new Future.delayed(const Duration(seconds: 5), () => _doSomething());
    }
}

Cela ne fonctionnerait pas si :

  • L'application est explicitement tuée par l'utilisateur (par exemple à partir du sélecteur de tâches).
  • L'application est tuée par le système d'exploitation en raison de la pression de la mémoire.
  • Sur iOS ? Je ne pense pas que nous ayons essayé cela, alors n'hésitez pas à essayer de faire rapport.

Je ne suis pas sûr des homologues iOS, mais sur Android, un plugin flutter pourrait être créé qui lance un service de premier plan, ce qui donne au processus une priorité plus élevée et le rend moins susceptible d'être tué pendant les périodes exigeantes en ressources. Cela donnerait-il également au chronomètre Dart de longue durée une meilleure chance de survie?

Oui, cela pourrait aider puisque votre activité (donc votre vue flottante) restera active. Je ne suis toujours pas convaincu que nous ayons suffisamment de clarté pour faire un plugin.

S'il s'agit de prendre en charge l'interrogation périodique des informations en arrière-plan, il serait peut-être préférable de concevoir un plugin juste pour cela. Cela devrait permettre d'enregistrer un rappel dans Dart qui est invoqué via une minuterie dans le code natif plutôt que d'implémenter la minuterie dans Dart. Nous pourrions le faire avec un service sur Android.

OU

Nous pourrions simplement avoir un HowTo pour créer des applications KeepAlive™ Flutter.

Sur iOS, vous pouvez définir un UIBackgroundMode dans votre Info.plist pour qu'il soit beaucoup moins probable que l'application soit tuée.

Sur Android, configurez un service vide. Il s'agit principalement d'un changement AndroidManifest.xml + une implémentation de classe de service triviale.

Un plugin KeepAlive générique ne semble pas fonctionner car il nécessiterait toujours une configuration manuelle sur iOS et il n'est pas clair s'il faut utiliser le service de premier plan/arrière-plan sur Android (le service de premier plan est plus difficile à tuer mais nécessite une notification persistante).

Même avec un service de premier plan, le système d'exploitation peut toujours tuer notre processus pour une raison quelconque.

Je pense que la solution idéale doit utiliser le gestionnaire d'alarmes d'Android, qui est destiné aux cas où vous souhaitez que votre code d'application s'exécute à un moment précis, même si votre application n'est pas en cours d'exécution. Mais même avec cela, comment pourrions-nous redémarrer le processus Dart avec le même état, puisque nous aurons un utilisateur Firebase connecté effectuant des écritures de base de données authentifiées ?

@pauldemarco d'où ce bogue ... Il n'y a aucun moyen pour Flutter pour le moment d'exécuter du code Dart dans n'importe quel état sans FlutterView en cours d'exécution. Cela inclut Alarm Manager, Wearable/Native Widget Data Sync ou Push Notifications (bien que le cas d'utilisation du dernier disparaisse lentement https://github.com/flutter/flutter/issues/6192).

Je pense que le problème _same state_ devrait être résolu au niveau de l'application et non au niveau de Flutter. Pour les applications natives, vous avez le même problème. Une fois qu'un processus est mort, vous ne pouvez pas récupérer l'état à moins de l'enregistrer quelque part (préférences partagées ou sqlite par exemple). Vous feriez probablement la même chose dans votre code Dart. Une chose que Flutter peut faire est de communiquer des messages tels que applicationWillTerminate sur iOS et onSaveInstanceState sur Android afin que vous puissiez vous y préparer.

Des questions:

  • Quels sont les modèles iOS et Android pour l'exécution en arrière-plan ?

    • Quels signaux peuvent déclencher l'exécution de l'application ?

    • Combien de temps dois-tu courir ? Comment savez-vous quand cela s'épuise?

  • Quel modèle d'exécution voulons-nous pour l'exécution en arrière-plan ? (par exemple, un isolat séparé ? Utilisez le fil principal dart:ui ?)
  • Voulons-nous prendre en charge l'exécution de code sans que l'application (comme dans runApp ) n'ait été exécutée en premier ?
  • Pouvons-nous collecter une liste canonique des cas d'utilisation ?

Actuellement, ce n'est pas prévu dans un avenir proche. C'est un processus important, nous aurions besoin de déplacer autre chose de notre liste de priorités à court terme pour le faire bientôt.

Cas d'utilisation
Nous avons différents modes de fonctionnement qui enregistrent les événements à différents intervalles (5 secondes, 10 minutes, 30 minutes, 6 heures). Nous avons besoin d'un moyen de garantir que le processus de journalisation s'exécute, que l'application soit en cours d'exécution ou non.

Quels signaux peuvent déclencher l'exécution de l'application ?

Sur Android, cela se ferait via un PendingIntent envoyé à partir d'une alarme programmée dans AlarmManager.
Je ne suis pas sûr de la contrepartie iOS à cela pour le moment.

Combien de temps dois-tu courir ? Comment savez-vous quand cela s'épuise?

Nous devons d'abord rassembler les informations nécessaires à l'événement, dont certaines sont asynchrones (localisation GPS), puis enregistrer l'événement dans une banque de données en ligne (Firebase). Tout ce processus peut durer jusqu'à 30 secondes.

Quel modèle d'exécution voulons-nous pour l'exécution en arrière-plan ? (par exemple, un isolat séparé ? Utilisez le fil principal dart:ui ?)

Je ne pense pas que cela nous importe, nous ne ferons aucun calcul coûteux.

Voulons-nous prendre en charge l'exécution de code sans que l'application (comme dans runApp) ne soit exécutée en premier ?

Je ne suis pas sûr des implications ici. Je suppose que puisque nous initialisons notre logique métier et notre état dans l'application normale, il serait préférable d'exécuter ces éléments en premier, afin que nous puissions utiliser les rapports d'incident, etc.

Je peux ajouter un autre cas d'utilisation, cette fonctionnalité est la seule chose qui m'empêche de finaliser mon application. J'avais une application Android pour cela et j'ai décidé de créer une version plus récente et meilleure qui, idéalement, fonctionne également sur iOS. Je ne connais pas les composants d'iOS (lors de mes recherches, j'ai découvert que les tâches d'arrière-plan dans iOS sont beaucoup plus restreintes que sur Android), mais je peux nommer les composants Android que j'ai utilisés.

Quels signaux peuvent déclencher l'exécution de l'application ?

La plupart du code est également déclenché par une alarme dans AlarmManager.

Cependant, pour déclencher cette alarme tout le temps, du code est exécuté au démarrage de l'appareil et également lors de la mise à niveau du package (android.intent.action.MY_PACKAGE_REPLACED) car les alarmes précédentes seraient supprimées.

Combien de temps dois-tu courir ? Comment savez-vous quand cela s'épuise?

Idéalement moins d'une seconde. Une petite requête réseau est faite et le résultat est conservé, dans certains cas une notification s'affiche. Après cela, la méthode revient.

Quel modèle d'exécution voulons-nous pour l'exécution en arrière-plan ? (par exemple, un isolat séparé ? Utilisez le fil principal dart:ui ?)

Peu m'importe aussi.

Voulons-nous prendre en charge l'exécution de code sans que l'application (comme dans runApp) ne soit exécutée en premier ?

Dans mon cas, après avoir exécuté une fois, ce serait bien, mais si quelque chose comme un récepteur de démarrage est possible, il devrait fonctionner même si l'application n'a pas été démarrée auparavant.

https://stackoverflow.com/questions/41924890/how-do-i-run-code-in-the-background-even-with-the-screen-off est la question de débordement de pile la plus consultée de Flutter autant que je peux dire. :) Il semble vraiment y avoir un intérêt pour cet espace.

https://github.com/flutter/flutter/issues/6192 a été réactivé pour fournir la prise en charge sous-jacente de l'exécution réelle du code Dart lorsqu'un FlutterView n'est pas rendu.

C'est sur notre radar à court terme, mais ce sera au moins quelques mois.

Désolé d' avoir désaffecté @zanderso de ce bogue, je voulais l'affecter au bogue d'exécution en arrière-plan sous-jacent (#6192)

CC @kasperl; nous avons exploré de nombreuses façons d'exécuter du code en arrière-plan sur nos différentes cibles, et peut-être que certains enseignements pourraient en être tirés.

@mit-mit avez-vous documenté vos découvertes sous une forme ou sous une autre ?

Une autre raison de vouloir un traitement en arrière-plan est si vous souhaitez créer une application Streaming Audio. L'utilisateur ouvre l'application pour démarrer un flux audio. Le processus d'arrière-plan télécharge le flux et lit la fin audio reçoit les événements pour démarrer/arrêter/pause/ff/rembobiner la fin envoie des événements pour modifier l'interface utilisateur, par exemple les métadonnées audio de la barre de recherche à ui. Vous avez besoin d'un processus d'arrière-plan lorsque l'utilisateur quitte vos applications, le téléchargement/la lecture du flux doit continuer

Nous y travaillons actuellement. Pas d'ETA pour le moment.

@zanderso a posté une mise à jour ici : https://github.com/flutter/flutter/issues/6192#issuecomment -342214725

@a-siva m'informe que cela est toujours en cours ; Android est opérationnel et nous travaillons actuellement sur iOS.

Nous avons un cas d'utilisation pour cela où nous aimerions suivre l'emplacement de l'utilisateur en arrière-plan pour enregistrer s'il s'est rendu ou non à un endroit spécifique à un moment précis (c'est-à-dire lors d'un événement).

@bjornbjorn ne pouvez-vous pas utiliser des barrières géographiques pour cela ? je ne sais pas si IOS a quelque chose de similaire mais vous pouvez réaliser ce Play Service Geofencing

y a-t-il des nouvelles @Hixie ? Je suis actuellement au stade où j'ai besoin que mon application s'exécute en tant que service d'arrière-plan (la plupart de l'application est écrite en Go), mais elle finit par être tuée. J'ai commencé à implémenter le service de premier plan côté Java, mais ça va être assez désagréable si je dois éventuellement le réimplémenter pour iOS.

Certains estiment que cela sera disponible pour Android la semaine prochaine ou le mois prochain serait vraiment apprécié :)

@rusenask comme détaillé dans https://github.com/flutter/flutter/issues/6192 , nous avons maintenant un plugin pour cela sur Android ! Veuillez consulter https://pub.dartlang.org/packages/android_alarm_manager et faites-nous savoir si cela répond à vos besoins.

Cela semble prometteur et je pourrais probablement changer mon application de style "démon" en "rafales périodiques" avec ce gestionnaire d'alarmes. Pour vous réveiller, consommez toutes les nouvelles et arrêtez-vous.

Cependant, idéalement, j'utiliserais quelque chose qui permet à mon processus de toujours s'exécuter au premier plan. https://stackoverflow.com/questions/15758980/android-service-needs-to-run-always-never-pause-or-stop . En bref, mon application exécute un bot, elle doit donc presque toujours s'exécuter.

Nous devrons nous assurer que nous avons documenté cela avant de considérer que cela est fait.

Doit-on ouvrir un nouveau numéro de documentation ?

@zanderso -- @mjohnsullivan est le meilleur contact pour la documentation.

L'ETA est-elle connue ?

@it2bz ETA pour quoi exactement ? Prise en charge sur Android ? Documentation? Prise en charge sur iOS ? Exemples?

@Hixie Support sur Android et iOS et au moins une documentation de base avec des exemples

Pour iOS, pouvez-vous préciser exactement ce que vous aimeriez ? Apple a des restrictions strictes sur ce que les applications peuvent faire en arrière-plan, il serait donc utile pour nous de savoir exactement à quelles API vous souhaitez que nous nous connections.

Je recherche une opportunité de travail de fond avec l'emplacement de l'utilisateur

On dirait que c'est le fil "demander des trucs d'arrière-plan", donc je vais commencer. Je voulais implémenter un lecteur de musique utilisant le flutter, mais je ne sais pas s'il serait possible (au niveau de l'API) de continuer à jouer de la musique même si l'application est minimisée sur le téléphone. Je sais que sur Android, vous pouvez démarrer un service qui pourra continuer même si l'application est fermée. Il relancerait alors l'activité si besoin. Est-ce que quelque chose de similaire est possible sur le flutter en ce moment ?

@SirWindfield Votre meilleur pari serait d'utiliser l'API de lecteur multimédia natif de chaque plate-forme, qui continuera à jouer séparément de l'application.

@kirbyfan64 Je le pensais, merci !

@Hixie , une solution comme celle-ci (Cordova) : https://github.com/katzer/cordova-plugin-background-mode , ou comme celle-ci (Swift) : https://github.com/yarodevuci/backgroundTask serait sympa pour les tâches d'arrière-plan Flutter.

@holospeed Ce sont des approches qu'Apple ne vous laisserait probablement pas expédier, donc je suppose que nous ne voudrions pas passer du temps à les mettre en œuvre nous-mêmes. C'est certainement quelque chose que nous vous invitons à mettre en œuvre en tant que package fourni par la communauté sur pub, si vous vous souciez des applications personnelles sur iOS, cependant.

Peut-être qu'une solution serait de créer des plugins d'arrière-plan spécifiques comme un plugin pour la lecture audio en arrière-plan et un plugin pour le GPS/Localisation en arrière-plan, etc. au lieu d'essayer de créer un mécanisme d'arrière-plan abstrait qui doit tout prendre en charge.

Est-il possible d'exécuter une minuterie en arrière-plan qui amène l'application à la
premier plan à un moment donné ?

Le mercredi 21 mars 2018 à 08h49, Dylan Drost [email protected] a écrit :

Peut-être qu'une solution serait de créer des plugins d'arrière-plan spécifiques comme un
plugin pour la lecture audio en arrière-plan, et un plugin pour GPS/Location
en arrière-plan, etc. au lieu d'essayer de créer un arrière-plan abstrait
mécanisme qui doit tout supporter.


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/3671#issuecomment-374867947 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AK-c-E0KdEkvbH5uCBIM8FaAbYQkSU2tks5tghQWgaJpZM4IVsUk
.

@ iBob101 Je pense que cela est possible si vous utilisez le plugin android_alarm_manager en combinaison avec le plugin android_intent .

Dans mon cas d'utilisation, toutes les tâches d'arrière-plan dont j'ai besoin consistent à lire de l'audio en arrière-plan à un moment donné, donc je pense que la suggestion de @ aegis123 est excellente, nous pouvons commencer petit et, avec le temps, fournir un mécanisme qui prend en charge tout processus d'arrière-plan

J'en ai également besoin pour jouer de la musique en arrière-plan.

J'ai regardé comment cela a été fait dans le plugin android_alarm_manager et d'après ce que je peux comprendre, un code Dart est invoqué sur Android en appelant runFromBundle . La fonction Dart invoquée est spécifiée par le point d'entrée, mais que se passe-t-il si cette fonction a besoin d'informations à transmettre ? Un exemple de cas d'utilisation serait une application de chat qui permet des réponses directes via des notifications. Selon ce lien , la notification autorisera la saisie à distance, mais il ne semble pas possible de transmettre le texte qui a été lu à la fonction Dart afin qu'il puisse être traité afin que la réponse puisse être envoyée.

Un autre exemple est une application de messagerie qui affiche une notification lorsqu'un nouveau courrier électronique a été reçu, des actions peuvent être présentées, dont la possibilité d'archiver le courrier électronique, ce qui est fait par une fonction Dart. Cependant, cette fonction aurait besoin de savoir quel e-mail doit être archivé.

@MaikuB , vous pouvez créer un PR pour permettre la transmission d'un dictionnaire pouvant contenir des paires clé-valeur.

De manière générale cependant, pour mon exemple d'utilisation, j'aurais besoin de quelque chose de similaire au composant de service androids. Et puisque Flutter n'est pas conçu pour avoir toutes les API disponibles que chaque système d'exploitation peut fournir, il pourrait en fait être une meilleure idée d'écrire l'application en kotlin/java ou en swift.

Je crois que @bkonyi examine actuellement ce que nous pouvons faire sur iOS pour ce problème.

Cela signifie que nous ne pouvons pas avoir de service en arrière-plan avec Flutter ? Par exemple : un service permettant d'afficher des notifications push à partir du serveur.

@s-bauer Toujours courir n'est pas une chose pour Android, sauf peut-être les notifications de premier plan, mais je n'ai pas trouvé de mentions de startForeground sur votre code.

Je ne sais pas quelles sont vos spécifications, mais rappelez-vous que les téléphones Android se mettent en veille profonde après quelques heures avec l'écran éteint et sans être déplacés. Tous les services (à l'exception du premier plan) vont être planifiés, mais le système d'exploitation pense que c'est le mieux. Une notification push provenant de FCM ou une alarme provenant d'AlarmManager sous une configuration spécifique sont peut-être les 2 seules choses sous le contrôle d'un développeur qui sont capables de réveiller un appareil / une application Android quand le développeur le souhaite, mais pas pour une quantité indéfinie de temps. Il existe de nombreuses autres méthodes qui dépendent de ce que le système d'exploitation pense être le mieux pour la batterie. Voir à propos du mode somnolence pour plus de détails. https://developer.android.com/training/monitoring-device-state/doze-standby

Sur iPhone, les choses sont beaucoup plus restreintes.

De plus, je ne vois pas pourquoi un service ou une connexion doit rester actif pour recevoir des notifications push de FCM ou d'APNS, peut-être qu'il me manque quelque chose ?

Mise à jour rapide : l'exécution en arrière-plan pour iOS est implémentée et en cours d'examen (PR flutter/engine#5539). Une fois que cela atterrira, je commencerai à mettre à jour l'exécution en arrière-plan d'Android pour avoir une interface cohérente et publier un exemple de plugin. Nous espérons que tout cela sera fait d'ici la fin du mois.

@bkonyi cela résoudrait-il également le problème avec : https://github.com/flutter/flutter/issues/17566 ?

@piotrpalek , oui, bien que le comportement sera probablement un peu différent de ce qu'il était auparavant, car nous ne pouvons plus partager l'isolat de l'interface utilisateur pour les rappels pour diverses raisons. Toute communication avec l'interface utilisateur de premier plan devra être établie sur des ports d'isolat, MethodChannel s, ou toute autre méthode qui ne repose pas sur le partage de mémoire avec l'isolat principal.

Mise à jour du statut : les modifications d'exécution en arrière-plan iOS et Android sont en cours d'examen et sont toujours en cours d'itération. Je m'attends à ce que les changements iOS dans flutter/engine#5539 atterrissent dans les prochains jours, en l'absence de demandes de modifications majeures, et les changements Android dans flutter/engine#5640 devraient, espérons-le, être effectués la semaine prochaine après avoir traité les commentaires de l'examen. Merci pour votre patience!

Impressionnant. Oui, j'avais vu les PR car ils faisaient tous deux référence à ce problème. Vous avez mentionné faire un exemple de plugin et j'ai vu celui d'iOS, y aura-t-il un échantillon Android ? Je suppose que le plug-in du gestionnaire d'alarmes Android pourrait être mis à jour une fois les modifications apportées

@MaikuB , oui, le plugin AlarmManager sera mis à jour une fois que flutter/engine#5640 atterrira et que flutter/plugins#642 sera terminé.

Bonjour. Une mise à jour concernant ce sujet ? La résolution a été reportée au jalon bucket7. Va-t-il vraiment atterrir là-bas ? C'est une fonctionnalité cruciale pour notre projet. Merci pour toute réponse.

J'ai malheureusement dû changer de priorités pendant quelques jours, mais je me remets à travailler là-dessus maintenant. Nous y sommes _presque_, alors merci d'avoir été si patient !

Maintenant que flutter/engine#5539, flutter/engine#5947 et flutter/engine#5954 ont atterri, toutes les fonctionnalités nécessaires à l'exécution en arrière-plan sur Android et iOS sont implémentées dans le moteur et devraient être intégrées au référentiel Flutter principal lors de la prochaine roulis moteur. La documentation et les exemples sont en préparation, et le correctif du plug-in android_alarm_manager est en cours de révision (flutter/plugins#642).

@bkonyi android_alarm_manager fonctionnera-t-il également sur les OI maintenant ?

@ianldgs , malheureusement non. iOS ne fournit aucun type de mécanisme pour exécuter du code sur une base périodique, il n'est donc probablement pas possible de créer une implémentation iOS (voir cet article SO ). Il est souvent possible d'atteindre les mêmes objectifs en utilisant l'un des modes d'exécution en arrière-plan limités (par exemple, des changements d'emplacement importants, des notifications push, un changement d'état Bluetooth, etc.).

@bkonyi , cela résoudra-t-il un problème que nous rencontrons actuellement avec l'impossibilité d'exécuter des tâches d'arrière-plan natives pendant une période prolongée (3 minutes) sur iOS ?

Pour clarifier, voici notre problème actuel...

Fond:
Notre application utilise des balises Bluetooth pour déterminer combien de temps quelqu'un passe à un endroit. Nous avons écrit tout notre code de balise nativement dans AppDelegate.swift.

Publier:
Flutter semble fermer notre application après quelques secondes lorsque nous exécutons du code natif en arrière-plan après avoir été réveillés par un événement de localisation (entrée/sortie de région dans ce cas) même si nous prolongeons notre temps d'exécution en arrière -plan.

Pourquoi pensons-nous que c'est lié à Flutter :
Nous avons testé notre code de balise natif avec une application iOS native et n'avons aucun problème à obtenir 180 secondes de temps d'exécution en arrière-plan.

Ce que nous avons essayé :
La seule solution de contournement avec laquelle nous avons réussi est de mettre un délai de 30 secondes dans le main() avant runApp() lorsque notre application a été lancée en arrière-plan. Cependant, cela a causé d'autres problèmes.

Toutes mes excuses pour la longue explication, mais c'est un énorme problème pour nous et nous essayons de sortir dans les prochaines semaines.

Nous espérons vraiment que ce correctif résoudra également notre problème.

Enfin, pour être clair, nous ne nous soucions pas tellement de l'exécution du code de fléchettes en arrière-plan. Au contraire, notre principale préoccupation est simplement de ne pas laisser Flutter terminer prématurément notre application lorsqu'il est réveillé en arrière-plan.

Toute aide serait extrêmement appréciée.

Merci!

@AndrewPetrovics, malheureusement, je ne pense pas que cela résoudra les problèmes que vous rencontrez, car ces modifications visent principalement à permettre l'exécution du code Dart en arrière-plan. Je ne suis pas très familier avec les politiques d'exécution en arrière-plan d'iOS, mais je travaille actuellement sur un plugin de géorepérage pour Android + iOS qui ressemble à votre cas d'utilisation, donc je garderai un œil sur le problème que vous rencontrez une fois Je commence la partie iOS aujourd'hui/demain.

@chinmaygarde , seriez-vous au courant des problèmes rencontrés par @AndrewPetrovics ? Peut-être que cela vaut la peine de déposer un nouveau problème.

@bkonyi , ça sonne bien. Nous avons fini par trouver une solution de contournement pour le moment, mais c'est très hacky. Je créerai un problème séparé quand j'en aurai l'occasion.

Merci!

@bkonyi Puis-je demander, quand android_alarm_manager 0.2.0 sera-t-il publiquement déployé sur pub.dartlang.org ?

@ethael , il devrait être disponible maintenant, attendait juste d'obtenir les autorisations pour publier la mise à jour.

Existe-t-il des exemples ou une documentation de cela disponible?
Merci!

@Solban il y a deux exemples dans le référentiel flutter/plugins :

J'ai également un plugin de géorepérage en cours qui prend en charge à la fois Android (Kotlin) et iOS (Obj-C), mais je ne sais pas si cela va vivre en flutter/plugins ou non.

Voici une documentation utile pour les fonctionnalités liées à l'exécution en arrière-plan :

  • La classe PluginUtilities pour transmettre des rappels entre isolats
  • L' IsolateNameServer qui est utile pour enregistrer des objets SendPort avec Flutter pour d'autres isolats à rechercher (cela semble manquer de documentation réelle, mais l'interface est plutôt simple).
  • Le FlutterNativeView qui est utilisé pour générer l'isolat d'arrière-plan pour le plugin sur Android
  • Le FlutterHeadlessDartRunner qui est utilisé pour générer l'isolat d'arrière-plan pour le plugin sur iOS

Actuellement, il n'y a pas de documentation formelle sur l'écriture de plugins avec des capacités d'exécution en arrière-plan. Cependant, il devrait y avoir un article Medium sur le blog Flutter dans les semaines à venir qui passera en revue le processus de conception, de mise en œuvre et d'utilisation de plugins qui utilisent l'exécution en arrière-plan.

Existe-t-il une solution pour continuer le travail en arrière-plan ? La seule façon correcte d'exécuter en continu du code long dans Android est Foreground service .
Un exemple de cas d'utilisation serait le suivi de la localisation GPS continue.

@audkar actuellement, il n'y a pas de plugin capable de gérer un travail d'arrière-plan continu, mais cela ne signifie pas que cela ne peut pas être fait. Un plugin utilisant la fonctionnalité que j'ai référencée ci- dessus en combinaison avec un service de premier plan (au lieu du JobIntentService que j'ai utilisé pour le plugin de geofencing) fonctionnerait bien.

Je suis actuellement en train de porter mon SDK de géolocalisation en arrière-plan iOS / Android / Geofencing vers Flutter. Il s'appellera flutter_background_geolocation .

J'ai environ 5 jours d'expérience avec Dart / Flutter mais je comprends. Il devrait être prêt dans les 2 semaines (bien que les documents prennent un peu plus de temps avec des exemples spécifiques à Dart).

Ce SDK a presque 5 ans et est pris en charge à plein temps. Il a été développé à l'origine pour Apache Cordova , puis porté plus tard sur React Native et NativeScript . Cela fonctionne également dans les applications natives pures. Sous le capot, c'est la même bibliothèque principale Obj-c + Java utilisée avec chaque plate-forme de développement.

Le SDK a été développé à l'origine pour suivre les premiers intervenants dans les zones sinistrées (par exemple : ouragans, tremblements de terre) dans un environnement où le réseau cellulaire est probablement détruit. Il devait continuer à suivre même si l'application était terminée ou l'appareil redémarré. Le plugin contient sa propre base de données SQLite et un service HTTP pour télécharger automatiquement des emplacements sur votre serveur. Ceci est particulièrement important pour Android dans le cas où l'application a été fermée, ne laissant que le service de premier plan du SDK fonctionnant "sans tête".

:avertissement : Ce SDK n'est pas conçu pour les applications sociales. il est conçu spécifiquement pour les cas d'utilisation de "suivi de flotte" (par exemple : taxi, service de livraison, intervention d'urgence, jogging, etc.).

Voici une brève vidéo de démonstration .

Voir la philosophie de fonctionnement .

Modifier Je vais également porter une autre bibliothèque en tant que flutter_background_fetch , qui sera incluse en tant que dépendance de flutter_background_geolocation . Ce module réveillera une application iOS / Android en arrière-plan environ toutes les 15 minutes, vous offrant 30 secondes de temps d'arrière-plan pour effectuer un travail périodique. Voir la version react-native pour plus d'informations.

Ok, j'ai publié flutter_background_geolocation . Il y a probablement encore quelques trous à brancher dans la façade des bibliothèques natives et les exemples dans les docs doivent être traduits à partir de la version React Native.

@christocracy bonne nouvelle. qu'en est-il de la récupération en arrière-plan ? des estimations concernant celui-ci?

@ethael Fetch arrivera dans environ 2 semaines de plus. C'est un plugin très simple.

@bkonyi J'ai essayé votre plugin de changement d'emplacement pour expérimenter l'exécution en arrière-plan. Il semble que le rappel de fléchette exécuté à partir du coureur sans tête ne puisse pas utiliser d'autres plugins, échouant avec MissingPluginException .

Sur Android, avec le plugin android_alarm_manager, vous avez résolu ce problème avec AlarmService.setPluginRegistrant(this); pour enregistrer en interne les plugins du service d'arrière-plan. Mais je ne vois pas comment obtenir l'équivalent pour iOS.

Est-il actuellement possible d'appeler d'autres plugins depuis un runner sans tête sur iOS ? Si oui, comment pouvons-nous enregistrer des plugins dans ce contexte ?

@bkonyi Ce problème n'est pas résolu et devrait être rouvert. L'AlarmManager semble au mieux être une solution de contournement car il ne prend en charge que les événements chronométrés. Flutter a besoin de quelque chose de plus générique, vous pouvez donc écouter certains événements comme un appareil Bluetooth à portée, par exemple. Et il doit mieux prendre en charge iOS. Je comprends qu'iOS est beaucoup plus restrictif, mais Flutter devrait prendre en charge les éléments disponibles pour les programmeurs natifs.

J'étais ravi de commencer avec Flutter, mais il semble qu'il y ait beaucoup de problèmes comme celui-ci qui le rendent inutilisable pour toutes les applications, sauf les plus simples. J'attendais plus de Google, et je pense qu'il est injuste de leur part d'attendre des développeurs qu'ils créent des plugins pour combler les principales lacunes qu'ils ont laissées.

@ dude8604 Google ne fournira pas tout et oui, c'est aux développeurs de plugins tiers (comme moi) de contribuer des plugins à l'écosystème. J'en amène deux actuellement moi-même.

J'ai passé beaucoup de temps avec Cordova, React Native et NativeScript. Après 2 semaines avec Flutter, je pense que c'est assez excellent, même s'il y a certainement des trous (un composant Map multiplateforme, par exemple, auquel je suis sûr que je contribuerai dans un avenir proche.)

Je suis un développeur de plugins professionnel spécialisé dans le fonctionnement en arrière-plan d'iOS et d'Android (géolocalisation et géofencing, en particulier) depuis 5 ans. Que voudriez-vous savoir?

@christocracy Je suis d'accord qu'il doit y avoir des plugins tiers, mais l'exécution en arrière-plan ou au moins la possibilité d'enregistrer des fonctions de rappel pour certains événements semble être quelque chose qu'un framework d'application devrait fournir. Mon problème n'est pas d'avoir à créer des plugins pour étendre les fonctionnalités de base, mais de publier un framework qui manque de fonctionnalités de base et d'attendre que les développeurs consacrent leur temps à une entreprise à but lucratif pour combler les lacunes. Quoi qu'il en soit, ce n'est pas le bon endroit pour en parler.

Je souhaite exécuter un service en arrière-plan et lire certains événements, traiter et éventuellement enregistrer les données et, le cas échéant, créer une notification qui lancera l'application principale si vous appuyez dessus. Voici quelques exemples d'événements : nouveau périphérique Bluetooth à portée, données entrantes sur une prise, données entrantes provenant d'un périphérique USB, SMS reçus, emplacement GPS modifié, tentative de connexion d'un périphérique Bluetooth, un certain bouton physique est enfoncé, les données de l'accéléromètre dépassent un valeur spécifiée, si l'application principale est terminée, et beaucoup d'autres choses auxquelles je ne pense pas. Si quelqu'un pouvait créer un plugin complet (avec une licence gratuite ou open source) pour cela qui fonctionne sur iOS et Android, je pense que ce problème pourrait être résolu. Et je serais éternellement reconnaissant de pouvoir commencer à développer avec Flutter.

@ mec8604 Je pense que je sais ce que tu veux. Pour faire une grande partie de cela, il faut évidemment un service de premier plan, avec sa notification persistante requise. L'utilisateur est conscient de votre service en cours d'exécution.

Contactez-moi via mon profil github.

Considérez que React Native était essentiellement comme "vous obtenez des boutons, des champs de texte et une vue de liste, le reste dépend de vous" et il est devenu ce qu'il est maintenant grâce à la communauté. Google ne peut pas gérer toutes les implémentations et il est insensé de penser que l'équipe Flutter sera en mesure de reproduire toutes les fonctionnalités fournies par Android et iOS lorsque ces fonctions seront ajoutées par des équipes 100x (10 000x ?) la taille de Flutter.

Les android_alarm_manager et image_picker ne semblent pas fonctionner (si les deux sont installés) après l'avoir implémenté dans un nouveau projet exécutant Flutter 0.8.3-pre.47 . L'application force la fermeture. L'exemple fonctionne donc j'ai tout copié dans l'exemple et configuré ma base de feu mais ne fonctionne toujours pas.

Pour ajouter le problème que @deckerst a soulevé, je ne suis pas sûr qu'il soit approprié de considérer cela comme fermé lorsqu'il n'y a pas de parité entre Android et iOS en ce qui concerne la possibilité d'exécuter du code qui utilise d'autres plugins

Edit: je viens de remarquer qu'il y a un autre problème pour suivre cela

Juste pour que cet article soit référencé ici pour ceux qui ne l'ont pas vu :
https://medium.com/flutter-io/executing-dart-in-the-background-with-flutter-plugins-and-geofencing-2b3e40a1a124

Merci @slightfoot. J'ai vu cela et c'est là que j'ai trouvé le ticket (#21925) pour que l'exécution sans tête d'iOS fonctionne avec les plugins. Avoir une référence entre ces deux billets aurait été utile.

Sur une note connexe, existe-t-il un plan pour inclure l'exécution sans tête dans la documentation officielle, par exemple dans le cadre du livre de recettes ? Je suppose que oui, mais je pense que cela vaut la peine de demander étant donné qu'il y a probablement une plus grande partie de la communauté qui ne saurait pas vérifier le support

Bon point @MaikuB , a ajouté un bogue de doc pour ça !

Prise en charge de l'arrière-plan en flutter directement, voir https://www.youtube.com/watch?v=_LfjILXswJs

Je ne comprends pas bien. Si Flutter prend désormais en charge l'exécution en arrière-plan, pourquoi le didacticiel contient-il principalement du code spécifique à la plate-forme ?

Obtenez Outlook pour Android https://aka.ms/ghei36


De : tonka [email protected]
Envoyé : vendredi 21 septembre 2018 03:39:28
À : flotter/battre
Cc : Philip Weiss ; Mention
Objet : Re : [flutter/flutter] Flutter devrait fournir une abstraction pour l'exécution en arrière-plan (#3671)

Prise en charge de l'arrière-plan en flutter directement, voir https://www.youtube.com/watch?v=_LfjILXswJs


Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/flutter/flutter/issues/3671#issuecomment-423490126 ou désactivez le fil de discussion https://github.com/notifications/unsubscribe-auth/ABWxFrGMGvfFtwkf025Q2Je6lUTZu2aPks5udMHggaJpZM4IVsUk .

@ dude8604 le tutoriel est destiné aux développeurs de plugins qui souhaitent développer un plugin pour effectuer une opération d'arrière-plan particulière.

Les consommateurs d'un plugin particulier sont aveugles (autant que possible) aux implémentations spécifiques à la plate-forme.

Donc, en tant que consommateur, existe-t-il un moyen d'exécuter du code arbitraire en arrière-plan, s'il n'y a pas de plugin pour mon cas d'utilisation spécifique ?


De : Chris Scott [email protected]
Envoyé : samedi 22 septembre 2018 17:43:16
À : flotter/battre
Cc : Philip Weiss ; Mention
Objet : Re : [flutter/flutter] Flutter devrait fournir une abstraction pour l'exécution en arrière-plan (#3671)

@ dude8604 https://github.com/dude8604 le tutoriel est destiné aux développeurs de plugins qui souhaitent développer un plugin pour effectuer une opération d'arrière-plan particulière.

Les consommateurs d'un plugin particulier sont aveugles (autant que possible) aux implémentations spécifiques à la plate-forme.


Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/flutter/flutter/issues/3671#issuecomment-423783230 ou désactivez le fil de discussion https://github.com/notifications/unsubscribe-auth/ABWxFhmlurQ08wWXLmMvE3E6yQ_lYvS1ks5udtkkgaJpZM4IVsUk .

@ mec8604 Non.

Autant que je sache actuellement :

Vous ne pouvez pas "exécuter du code arbitraire en arrière-plan". Android est strict maintenant . iOS l'a toujours été.

@ mec8604 , @christocracy a raison. La fonctionnalité d'exécution en arrière-plan présentée dans l'article Medium est destinée aux développeurs qui souhaitent créer des plugins capables d'exécuter du code Dart en arrière-plan. La plupart des utilisateurs de Flutter n'auront jamais à écrire de code spécifique à la plate-forme pour une exécution en arrière-plan, à moins qu'il n'y ait pas de plug-in existant correspondant à leur cas d'utilisation, car ces plug-ins résumeront le code spécifique à la plate-forme derrière une interface Dart.

Les android_alarm_manager et image_picker ne semblent pas fonctionner (si les deux sont installés) après l'avoir implémenté dans un nouveau projet exécutant Flutter 0.8.3-pre.47 . L'application force la fermeture. L'exemple fonctionne donc j'ai tout copié dans l'exemple et configuré ma base de feu mais ne fonctionne toujours pas.

@ rupert2133 cela vous dérangerait-il de signaler un problème avec plus d'informations ? N'hésitez pas à me mentionner pour que je sois prévenu. Ce problème concernait l'exigence plus large d'exécution en arrière-plan du code Dart et est fermé, de sorte que toute réponse supplémentaire ici risque d'être enterrée.

L'android_alarm_manager et l'image_picker ne semblent pas fonctionner (si les deux sont installés) après

Cela me rappelle. Hier, lors de l'implémentation de Headless Android dans mon plugin, j'ai eu une erreur provenant de googlemaps ici .

Lorsque tous les plugins sont réenregistrés dans l'état Headless, registrar.activity() == null .

J'ai dû pirater cela manuellement pour que mon application démarre:

public static void registerWith(Registrar registrar) {
    final GoogleMapsPlugin plugin = new GoogleMapsPlugin();
+    Activity activity = registrar.activity();
+    if (activity != null) {
      registrar.activity().getApplication().registerActivityLifecycleCallbacks(plugin);
      registrar
              .platformViewRegistry()
              .registerViewFactory(
                      "plugins.flutter.io/google_maps", new GoogleMapFactory(plugin.state, registrar));
+    }
  }

Cela va être un problème avec un grand nombre de plugins, je suppose.

Je souhaite exécuter un service en arrière-plan et lire certains événements, traiter et éventuellement enregistrer les données et, le cas échéant, créer une notification qui lancera l'application principale si vous appuyez dessus. Voici quelques exemples d'événements : nouveau périphérique Bluetooth à portée, données entrantes sur une prise, données entrantes provenant d'un périphérique USB, SMS reçus, emplacement GPS modifié, tentative de connexion d'un périphérique Bluetooth, un certain bouton physique est enfoncé, les données de l'accéléromètre dépassent un valeur spécifiée, si l'application principale est terminée, et beaucoup d'autres choses auxquelles je ne pense pas. Si quelqu'un pouvait créer un plugin complet (avec une licence gratuite ou open source) pour cela qui fonctionne sur iOS et Android, je pense que ce problème pourrait être résolu. Et je serais éternellement reconnaissant de pouvoir commencer à développer avec Flutter.

@bkonyi Alors, laquelle des choses ci-dessus puis-je faire actuellement avec les plugins existants ? Puis-je utiliser AlarmManager pour interroger ces événements ? Mais AlarmManager ne fonctionne pas sur iOS, n'est-ce pas ?

@ dude8604 Le meilleur que vous obtiendrez pour les événements périodiques sur iOS est via l'API "background-fetch". Je porterai ce plugin pour flutter bientôt.

L'API iOS "Background Fetch" réveillera une application endormie en arrière-plan environ toutes les 15 minutes (il s'agit de l' intervalle le plus rapide possible ) fournissant à votre application exactement 30 secondes de temps d'exécution en arrière-plan. Cependant, iOS utilise (vraisemblablement) l'apprentissage automatique et limitera cela en fonction de l'heure de la journée et de la fréquence d'utilisation de l'appareil / de l'application (par exemple : la nuit, lorsque l'utilisateur dort probablement, les événements de récupération peuvent survenir une fois par heure.

@christocracy @bkonyi Donc, tout cela et leurs équivalents Android pourraient être transformés en plugin ? Comment puis-je faire une demande de fonctionnalité pour cela ?

@ mec8604 Vous ne pouvez pas simplement agiter une baguette magique et *poof* . Vous allez mettre vos gants de travail et le faire vous-même. Si vous ne pouvez pas le faire vous-même, vous trouvez quelqu'un qui peut le faire et vous lui payez des dizaines de milliers de dollars.

@christocracy Vous avez raison, mais j'espérais que l'une des plus grandes entreprises au monde aurait les ressources nécessaires pour développer un produit complet et ne pas obliger ses utilisateurs à dépenser des dizaines de milliers de dollars pour le rendre suffisamment utilisable.

Eh bien, oui, c'est une grande entreprise.

Cette corporation est également composée d'individus, qui ne sont pas omniprésents. Aucun cadre ne peut jamais tout couvrir, car si vous essayez, votre projet va se transformer en un tas de brûlures… eh bien, des ordures.
Il existe des centaines d'API spécifiques à la plate-forme et aucune équipe ne va les couvrir. Vous devrez en lier vous-même.

@ mec8604 Considérez que votre définition de "tout en vedette" n'est pas la même que la mienne. Leur responsabilité est de gérer l'intersection.

1 f you write this

Avons-nous une direction claire de la part des docs ? J'ai vu Release Preview 2 dire qu'il prend en charge l'exécution en arrière-plan. Quelques exemples seraient bien d'aller.

@Pushan-Gupta background-execution est une chose spécifique au plugin.

Cela dépend de ce que vous voulez faire. Localisation du suivi ? Recevoir des notifications push ? Surveiller les clôtures géographiques ? Détecter les appareils BT ? Des balises ? Jouer de la musique?

Il n'y a pas "un seul anneau pour les gouverner tous, la prise en charge de l'exécution en arrière-plan"

@christocracy Désolé je ne le savais pas. Je visais une chose précise. Supposons que je souhaite faire une demande de publications à partir de l'application. Mais la connexion est coupée. Dès que l'appareil revient en ligne, que l'application soit ouverte ou non, la file d'attente de ces demandes de publication doit être traitée.

Exemple : Whatsapp met les messages en file d'attente avant de les envoyer au serveur. Si l'appareil est hors ligne, il stocke la file d'attente et la dessert dès qu'il est en ligne.

BTW J'ai un PR en cours, discutant de l'enregistrement du plugin pour les isolats d'arrière-plan. Si quelqu'un a une idée...

https://github.com/flutter/engine/pull/6396

Quel est l'intérêt de FlutterHeadlessDartRunner actuellement ?
J'ai actuellement implémenté l'exécution en arrière-plan sur Android (pas de plugin juste FlutterNativeView(ctx, true) ), et c'était assez facile à faire.
Mais sur iOS, ça plante

func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: <strong i="10">@escaping</strong> () -> Void) {
    let headless = FlutterHeadlessDartRunner.init()
    headless.run(withEntrypoint: "main") // just EXC_BAD_ACCESS here
}

Hey,
S'il vous plaît aider dans l'application de rappel dans Flutter iOS

@MohdLucky Et l'aide dont vous avez besoin est... ?

@christocracy avez-vous une mise à jour sur l'état de mise en œuvre du plugin background_fetch s'il vous plaît ?

pas mis à jour sur l'état de mise en œuvre du plugin background_fetch , veuillez fournir un exemple de code pour
exécution d'une notification en arrière-plan.

Toute mise à jour à ce sujet... Je pensais vraiment que cela faisait partie du flutter :( ..c'est à peu près les mêmes problèmes que les autres solutions hybrides Web ont...

@radvansky-tomas Je ne sais pas pourquoi les gens ne comprennent tout simplement pas que ce n'est pas de la responsabilité de Flutters. Même si vous devez implémenter l'exécution en arrière-plan de manière native, vous avez toujours l'avantage d'une seule base de code. L'écriture d'un plugin flutter qui fait votre travail en arrière-plan ne prend qu'un ou deux jours de travail. J'ai eu le même problème, j'avais besoin d'un service Android qui serait capable de jouer de la musique pour moi. Je viens de l'écrire en kotlin, j'ai implémenté la couche de communication en utilisant flutter et plus tard j'ai fait de même pour iOS.
Il est tout à fait possible d'utiliser uniquement les systèmes d'arrière-plan natifs du système.
Au lieu de vous plaindre ici que X n'est pas implémenté, vous pouvez littéralement l'implémenter sans aucun problème en utilisant l'écosystème fourni par l'équipe.

@SirWindfield Malheureusement, vous ne savez pas de quoi vous parlez. C'est une partie essentielle de l'architecture, pas le plugin lui-même.

Flutter est présenté comme une solution multiplateforme produisant du code natif, c'est-à-dire qu'on s'attend à ce qu'il puisse exécuter du code dans son langage (Dart) à chaque fois que le système d'exploitation le permet.

Ainsi, si l'application s'exécute après la réception de la notification à distance et que vous pouvez placer un point d'arrêt dans le code natif existant, vous devriez pouvoir appeler votre code flutter/dart où se trouvent vos services, modèles et enfin l'interface utilisateur.

Pour le faire dans votre cas... disons que votre musique joue en arrière-plan et que vous terminez votre liste de lecture... après 10 minutes, votre application s'arrête. Ensuite, vous appelez siri ou utilisez des écouteurs pour relancer la lecture de votre application, quel que soit le point d'entrée que vous avez choisi... le code natif est exécuté, mais pas son interface utilisateur, votre code flottant n'est pas initialisé et vous êtes perdu comme moi avec mes notifications.

Donc non, ce n'est pas possible, je peux écrire une notification de capture de plug-in natif pour moi, mais j'ai ensuite besoin d'accéder à la logique métier flutter pour traiter les données, dans mon cas, crypto décrypter et publier une notification locale avec un contenu décrypté

Nous allons, je l'ai largement testé sur mon téléphone et cela fonctionne sans aucun problème.
Il se peut que mon téléphone n'ait jamais tué l'application. Mon mal alors.

@christocracy une mise à jour concernant le plugin background_fetch Chris ?

@ethael Voici le dépôt vide que vous pouvez surveiller pour les mises à jour.
https://github.com/transistorsoft/flutter_background_fetch

@radvansky-tomas, vous pouvez gérer les événements d'arrière-plan dans le code Dart en créant un isolat d'arrière-plan comme décrit dans ce post moyen sur l'exécution en arrière-plan . Vous devrez probablement écrire du code natif pour chaque plate-forme en fonction de vos besoins particuliers, sauf s'il existe déjà un plugin qui fait ce que vous voulez (peu probable, car je ne connais pas de nombreux plugins qui prennent en charge l'exécution en arrière-plan pour le moment).

@bkonyi Merci pour la réponse, j'ai commencé à changer le plugin firebase_messaging pour prendre en charge l'exécution en arrière-plan... mais ce problème concerne davantage une manière générique de le faire. Je veux dire qu'il devrait faire partie de template = runner et de son côté fléchette où les développeurs peuvent exécuter un tel code sans tête, certaines règles, la norme de modèle comme c'est le cas actuellement sur certains blogs, suggestions, etc.

Quelques travaux initiaux effectués : https://github.com/radvansky-tomas/plugins/tree/master/packages/firebase_messaging

Suivre quelques guides de https://github.com/bkonyi/FlutterGeofencing

Je devrais le terminer d'ici la fin de cette semaine, je ne travaille que sur des bits iOS pour l'instant. Un exemple de projet utilise le plugin de notification local pour montrer que le message a été reçu en arrière-plan (notification silencieuse), puis en publie un nouveau local, pour manifester le succès.

Quelques travaux initiaux effectués : https://github.com/radvansky-tomas/plugins/tree/master/packages/firebase_messaging

Suivre quelques guides de https://github.com/bkonyi/FlutterGeofencing

Je devrais le terminer d'ici la fin de cette semaine, je ne travaille que sur des bits iOS pour l'instant. Un exemple de projet utilise le plugin de notification local pour montrer que le message a été reçu en arrière-plan (notification silencieuse), puis en publie un nouveau local, pour manifester le succès.

@goderbauer et moi cherchions en fait à ajouter ce support, mais nous serions plus qu'heureux de vous aider avec la conception et les révisions si vous envisagez de faire une demande d'extraction.

J'ai donc à peu près terminé cette partie, donc maintenant je peux recevoir des notifications push silencieuses et mon rappel écrit en fléchette est exécuté pendant que l'application est en arrière-plan.

Cependant, je ne peux accéder à aucun autre plugin là-bas. Le rappel doit être une méthode root/statique et ne comprend vraiment pas comment appeler quoi que ce soit à partir de là.

J'ai donc essayé de faire un test simple, d'utiliser le plug-in de notification locale flutter pour envoyer une notification locale après la réception d'une notification silencieuse, mais le plug-in ne semble pas accessible (non enregistré?)

J'ai trouvé des messages similaires ici : https://github.com/flutter/engine/pull/6396

Y a-t-il une autre étape nécessaire que je dois faire pour charger ces plugins ?

Mon rappel au niveau racine :
void callback(FirebaseMessage m, MessageEvent e) async { print('Message $m Event: $e'); final SendPort send = IsolateNameServer.lookupPortByName('messaging_send_port'); send?.send(e.toString()); }

La question n'est pas de savoir comment accéder à tous les codes de fléchettes + plugins à partir de ce rappel... interroger firestore, etc.

Mon implémentation de Background Fetch est enfin disponible.
background_fetch

@christocracy Vous avez raison, mais j'espérais que l'une des plus grandes entreprises au monde aurait les ressources nécessaires pour développer un produit complet et ne pas obliger ses utilisateurs à dépenser des dizaines de milliers de dollars pour le rendre suffisamment utilisable.

C'est tellement vrai. Si vous obtenez le temps des gens, vous devriez leur donner quelque chose en retour. Si ce n'est pas le cas, ne créez pas ces titres marketing fantaisistes !

Il semble que ce problème cause toujours des problèmes aux gens? Il est fermé et contient de nombreux commentaires, il est donc peu probable que nous apportions de nombreux changements concrets au projet à partir de ce problème. :( (Nous devrons en déposer de nouveaux pour faire plus de progrès, je m'attends.)

Je serais très intéressé à ce que nous documentions les changements concrets souhaités ici. On dirait que plus d'exemples d'arrière-plan sont souhaités ? (par exemple https://github.com/flutter/flutter/issues/23794)

Dans tous les cas, nous aimerions que les problèmes individuels soient classés avec des demandes individuelles. Comme d'autres l'ont noté ci-dessus, Flutter est un projet vaste et complexe, et bien que nous ayons une grande équipe (et en pleine expansion) ici chez Google, nous n'avons toujours pas assez d'ingénieurs travaillant à plein temps sur Flutter pour répondre à tous les problèmes simultanément. Flutter est 100% open source et tous nos problèmes sont sur GitHub. Les correctifs sont toujours les bienvenus bien sûr. :)

Pour tout problème/changement souhaité, veuillez déposer de nouveaux problèmes pour faire savoir à tous les contributeurs comment nous pouvons vous aider davantage : https://github.com/flutter/flutter/issues/new

Merci!

Défi @eseidel accepté : #24278

J'espérais éviter d'écrire du code spécifique à l'appareil et avoir une implémentation de l'API Flutter Dart peut-être basée sur des événements qui cacheraient les spécifications de l'appareil et du système d'exploitation et une implémentation spécifique.

déjà résolu ici

@ Krunal79-flutter comment exactement, cette approche aurait toujours les mêmes problèmes. Le fait est que dans votre scénario, le flutter est déjà initialisé et son accès en arrière-plan n'est alors pas approprié. Le problème que j'avais et que j'ai, c'est lorsque l'application est réellement morte et que la notification silencieuse (ou l'extension d'application) va réveiller votre application et que vous devez exécuter la logique "dart" alors que le flutter n'est pas encore en cours d'exécution (c'est-à-dire qu'aucune interface utilisateur n'est présente).

Cela devrait vraiment être un problème beaucoup plus prioritaire pour celui qui gère l'équipe Flutter. La mise en œuvre de la fonctionnalité d'arrière-plan est une énorme douleur pour le développeur Flutter moyen et elle tombe souvent en panne de manière non triviale. Et je suis sûr que beaucoup de développeurs d'applications sont actuellement aux prises avec cela.

@tomoerlemans010 , veuillez consulter le commentaire dans https://github.com/flutter/flutter/issues/3671#issuecomment -438113161.

Ce problème particulier est fermé, veuillez ajouter des commentaires à d'autres problèmes ouverts liés à l'exécution en arrière-plan ou en créer un nouveau avec les problèmes auxquels vous êtes confrontés.

Cette page vous a été utile?
0 / 5 - 0 notes