Ich entwickle ein Add-in, bei dem mein Hauptarbeitsablauf darin besteht, sich auf Ereignisse in ArcGIS Pro zu abonnieren und eine Zusammenfassung wichtiger Ereignisse an unseren Server zu melden, der ein Dashboard auf einem Webclient steuert. Ein großes Ziel unseres Add-ins ist es, für den Benutzer möglichst wenig störend zu sein. Diese Idee zusammen mit der Notwendigkeit, manchmal den MCT verwenden zu müssen, führt dazu, dass wir stark auf QueuedTask angewiesen sind.
Ein typischer Ablauf in unserer Anwendung sieht ungefähr so aus wie in diesem Ausschnitt:
GPExecuteToolEvent.Subscribe((evt) => QueuedTask.Run(() => {
// parseGPEvent kann MCT erfordern
var parsedEvent = Helper.parseGPEvent(evt);
if (parsedEvent != null) {
var name = $"tool:{parsedEvent.items[0].title.ToLower()}";
// der neue ArcEvent-Konstruktor kann MCT erfordern
this.ReportEvent(new ArcEvent(name, parsedEvent));
}
}));
Ich habe einige der Dokumentationen gelesen wie
- 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
Diese erläutern alle, warum es gut ist, QueuedTask zu verwenden und wann es erforderlich ist, aber keine von ihnen erwähnt wirklich etwas darüber, was man vermeiden sollte, in einem QueuedTask auszuführen außer Benutzereingaben. Ich weiß, dass es einige Fallstricke gibt, da wir das gesamte Ereignisparsing in einem QueuedTask verpackt haben und einige Variablen sich zwischen dem Abonnement-Callback und der Ausführung des QueuedTask ändern können. Ich muss das vielleicht besser abmildern, aber meine Hauptsorge ist, ob es etwas gibt, das explizit aus dem QueuedTask vermieden werden sollte und was eine bessere Lösung sein könnte?
Ich denke, vielleicht wäre unser API-Aufruf (innerhalb von ReportEvent) besser für einen BackgroundTask geeignet; allerdings ist es etwas vorteilhaft, dass die Ereignisse in der Reihenfolge an unseren Server gesendet werden, in der sie auf dem Client auftreten, und wenn man sie in einen BackgroundTask steckt, wäre das nicht mehr garantiert. Ich möchte den UI-Thread nicht blockieren, daher klingt es nicht ideal, sie gar nicht in irgendeine Task zu setzen. Aber ich habe auch gelesen, dass länger laufende Tasks vermeiden sollten, den MCT zu blockieren. Außerdem habe ich bemerkt, dass ich aufgrund des Wartens auf den MCT bestimmte Dinge wie das Python-Fenster blockieren können, sodass unsere Ereignisse erst nach Abschluss des Python-Skripts gesendet werden. Dieses GPExecuteToolEvent kann insbesondere etwas falsch gemeldet werden, weil alle Ereignisse sich während der Skriptausführung ansammeln und dann alle nacheinander ausgelöst werden, sobald das Skript den MCT freigibt.
Gibt es allgemein etwas außer UI-Interaktionen, das NICHT in einem QueuedTask enthalten sein sollte? Haben Sie Empfehlungen für diesen speziellen Arbeitsablauf oder weitere Dokumentationen, die komplexere Anwendungsfälle besser erklären könnten? Es scheint, dass die meisten Add-in-Beispiele nicht viel eigene Arbeit leisten, sondern typischerweise nur Pro SDK-Befehle ausführen.
