Tenho desenvolvido um add-in onde meu fluxo de trabalho principal é assinar eventos no ArcGIS Pro e relatar um resumo dos eventos importantes para nosso servidor, que alimenta um painel em um cliente web. Um grande objetivo do nosso add-in é ser minimamente intrusivo para o usuário. Essa ideia, junto com a necessidade de às vezes ser obrigado a usar o MCT, faz com que dependamos fortemente do QueuedTask.
Um fluxo típico em nossa aplicação é fazer algo parecido com este trecho:
GPExecuteToolEvent.Subscribe((evt) => QueuedTask.Run(() => {
// parseGPEvent pode exigir MCT
var parsedEvent = Helper.parseGPEvent(evt);
if (parsedEvent != null) {
var name = $"tool:{parsedEvent.items[0].title.ToLower()}";
// o novo construtor ArcEvent pode exigir MCT
this.ReportEvent(new ArcEvent(name, parsedEvent));
}
}));
Eu li parte da documentação como
- 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
Todos eles documentam por que é bom usar QueuedTask e quando é necessário, mas nenhum realmente menciona algo a evitar dentro de um QueuedTask, exceto entrada do usuário. Sei que há algumas ressalvas sobre como envolvemos toda a análise do evento em um QueuedTask e algumas variáveis podem mudar entre o callback da assinatura e a execução do QueuedTask. Talvez eu precise melhorar isso, mas minha principal preocupação é se há algo que deve ser explicitamente evitado no QueuedTask e qual seria uma solução melhor?
Acho que talvez nossa chamada de API (dentro do ReportEvent) possa ser mais adequada para um BackgroundTask; no entanto, enviar os eventos para nosso servidor na mesma ordem em que acontecem no cliente é algo benéfico e colocá-los em BackgroundTask parece que isso não seria mais garantido. Não quero bloquear a thread da UI, então não colocá-los em nenhuma tarefa parece não ser ideal, mas também li que tarefas de longa duração devem evitar bloquear o MCT. Também notei que, porque estou esperando pelo MCT, certas coisas como a janela python podem bloquear nossos eventos de serem enviados até a conclusão do script python. Este GPExecuteToolEvent em particular pode acabar sendo relatado incorretamente porque todos os eventos se acumulam enquanto o script está rodando e depois disparam todos seguidos assim que o script libera o MCT.
Em geral, há algo além da interação com UI que NÃO deveria ser incluído em um QueuedTask? Você tem alguma recomendação para esse fluxo de trabalho específico ou documentação adicional que possa ajudar a explicar casos de uso mais complexos? Parece que a maioria dos exemplos de add-in não fazem muito trabalho por conta própria, mas normalmente apenas executam comandos do Pro SDK.
