Ik ontwikkel een add-in waarbij mijn hoofdworkflow is om me te abonneren op gebeurtenissen in ArcGIS Pro en een samenvatting van belangrijke gebeurtenissen naar onze server te rapporteren, die een dashboard aanstuurt op een webclient. Een groot doel van onze add-in is om minimaal storend te zijn voor de gebruiker. Dat idee, samen met de noodzaak om soms de MCT te gebruiken, zorgt ervoor dat we sterk vertrouwen op QueuedTask.
Een typische flow in onze applicatie is iets doen langs de lijnen van deze snippet:
GPExecuteToolEvent.Subscribe((evt) => QueuedTask.Run(() => {
// parseGPEvent kan MCT vereisen
var parsedEvent = Helper.parseGPEvent(evt);
if (parsedEvent != null) {
var name = $"tool:{parsedEvent.items[0].title.ToLower()}";
// de nieuwe ArcEvent constructor kan MCT vereisen
this.ReportEvent(new ArcEvent(name, parsedEvent));
}
}));
Ik heb wat documentatie gelezen zoals
- 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
Deze documenteren allemaal waarom het goed is om QueuedTask te gebruiken en wanneer het vereist is, maar geen van hen vermeldt echt iets over wat je moet vermijden in een QueuedTask behalve gebruikersinvoer. Ik weet dat er een paar kanttekeningen zijn omdat we het hele event parsing in een QueuedTask hebben verpakt en sommige variabelen kunnen veranderen tussen de subscription callback en de uitvoering van de QueuedTask. Misschien moet ik dat beter aanpakken, maar mijn grootste zorg is of er iets expliciet vermeden moet worden in de QueuedTask en wat een betere oplossing zou kunnen zijn?
Ik denk dat onze api-aanroep (binnen ReportEvent) misschien beter geschikt is voor een BackgroundTask; echter, het is enigszins voordelig dat de gebeurtenissen in dezelfde volgorde naar onze server worden gestuurd als ze op de client plaatsvinden, en het plaatsen ervan in BackgroundTask klinkt alsof dat niet langer gegarandeerd zou zijn. Ik wil de ui-thread niet blokkeren, dus ze niet in een taak plaatsen klinkt ook niet ideaal, maar ik heb ook gelezen dat langer lopende taken moeten vermijden om de MCT te blokkeren. Ik heb ook gemerkt dat omdat ik wacht op de MCT bepaalde dingen zoals het python venster onze gebeurtenissen kunnen blokkeren totdat het python script voltooid is. Deze GPExecuteToolEvent kan in het bijzonder enigszins verkeerd gerapporteerd worden omdat alle gebeurtenissen zich opstapelen terwijl het script draait, en dan allemaal achter elkaar afgevuurd worden zodra het script de MCT vrijgeeft.
In het algemeen, is er iets anders dan UI-interactie dat NIET in een QueuedTask opgenomen moet worden? Heeft u aanbevelingen voor deze specifieke workflow of verdere documentatie die complexere gebruikssituaties beter kan uitleggen? Het lijkt erop dat de meeste add-in voorbeelden zelf niet veel werk doen, maar meestal gewoon Pro SDK commando's uitvoeren.
