J'ai développé un add-in où mon flux de travail principal consiste à s'abonner aux événements dans ArcGIS Pro et à rapporter un résumé des événements importants à notre serveur qui alimente un tableau de bord sur un client web. Un grand objectif de notre add-in est d'être le moins intrusif possible pour l'utilisateur. Cette idée, ainsi que la nécessité d'utiliser parfois le MCT, nous fait beaucoup dépendre de QueuedTask.
Un flux typique dans notre application est de faire quelque chose dans le genre de ce snippet :
GPExecuteToolEvent.Subscribe((evt) => QueuedTask.Run(() => {
// parseGPEvent peut nécessiter MCT
var parsedEvent = Helper.parseGPEvent(evt);
if (parsedEvent != null) {
var name = $"tool:{parsedEvent.items[0].title.ToLower()}";
// le nouveau constructeur ArcEvent peut nécessiter MCT
this.ReportEvent(new ArcEvent(name, parsedEvent));
}
}));
J'ai lu une partie de la documentation comme
- https://github.com/Esri/arcgis-pro-sdk/wiki/ProConcepts-Framework#using-queuedtask
- https://www.youtube.com/watch?v=9tQKOMoLa2w
- https://github.com/esri/arcgis-pro-sdk/wiki/ProConcepts-Asynchronous-Programming-in-ArcGIS-Pro#using-queuedtask
Tous expliquent pourquoi il est bon d'utiliser QueuedTask et quand c'est requis, mais aucun ne mentionne vraiment ce qu'il faut éviter dans un QueuedTask excepté l'entrée utilisateur. Je sais qu'il y a quelques mises en garde car nous avons enveloppé toute l'analyse d'événement dans un QueuedTask et certaines variables peuvent changer entre le rappel d'abonnement et l'exécution du QueuedTask. Je devrais peut-être mieux gérer cela, mais ma principale préoccupation est s'il y a quelque chose qui devrait être explicitement évité dans le QueuedTask et quelle pourrait être une meilleure solution ?
Je pense que peut-être notre appel API (dans ReportEvent) serait mieux adapté à un BackgroundTask ; cependant, faire en sorte que les événements soient envoyés à notre serveur dans le même ordre qu'ils se produisent sur le client est assez bénéfique et les mettre dans BackgroundTask semble ne plus garantir cela. Je ne veux pas bloquer le thread UI donc ne pas les mettre dans une tâche ne semble pas idéal, mais j'ai aussi lu que les tâches longues devraient éviter de bloquer le MCT. J'ai aussi remarqué que parce que j'attends le MCT, certaines choses comme la fenêtre python peuvent bloquer l'envoi de nos événements jusqu'à la fin du script python. Ce GPExecuteToolEvent en particulier peut finir par être quelque peu mal rapporté car tous les événements vont s'accumuler pendant que le script tourne, puis seront tous déclenchés consécutivement une fois que le script libère le MCT.
En général, y a-t-il autre chose que l'interaction UI qui NE DOIT PAS être incluse dans un QueuedTask ? Avez-vous des recommandations pour ce flux de travail particulier ou une documentation supplémentaire qui pourrait aider à expliquer des cas d'utilisation plus complexes ? Il semble que la plupart des exemples d'add-in ne font pas beaucoup de travail eux-mêmes, mais exécutent généralement juste des commandes Pro SDK.
