He estado desarrollando un complemento donde mi flujo de trabajo principal es suscribirme a eventos en ArcGIS Pro y reportar un resumen de eventos importantes a nuestro servidor que impulsa un panel en un cliente web. Un gran objetivo de nuestro complemento es ser mínimamente intrusivo para el usuario. Esa idea junto con la necesidad de a veces tener que usar el MCT, dependemos mucho de QueuedTask.
Un flujo típico en nuestra aplicación es hacer algo similar a este fragmento:
GPExecuteToolEvent.Subscribe((evt) => QueuedTask.Run(() => {
// parseGPEvent puede requerir MCT
var parsedEvent = Helper.parseGPEvent(evt);
if (parsedEvent != null) {
var name = $"tool:{parsedEvent.items[0].title.ToLower()}";
// el nuevo constructor ArcEvent puede requerir MCT
this.ReportEvent(new ArcEvent(name, parsedEvent));
}
}));
He leído parte de la documentación 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 estos documentan por qué es bueno usar QueuedTask y cuándo es requerido, pero ninguno realmente menciona algo para evitar estar en un QueuedTask excepto la entrada del usuario. Sé que hay algunas advertencias sobre cómo hemos envuelto todo el análisis del evento en un QueuedTask y algunas variables pueden cambiar entre la devolución de llamada de suscripción y la ejecución del QueuedTask. Puede que necesite mejorar eso, pero mi principal preocupación es si hay algo que debería evitarse explícitamente en el QueuedTask y cuál podría ser una mejor solución.
Creo que quizás nuestra llamada api (dentro de ReportEvent) podría estar mejor adaptada a un BackgroundTask; sin embargo, que los eventos se envíen a nuestro servidor en el mismo orden en que ocurren en el cliente es algo beneficioso y ponerlos en BackgroundTask suena como que eso ya no estaría garantizado. No quiero bloquear el hilo ui así que no ponerlos en ninguna tarea no parece ideal, pero también he leído que las tareas de larga duración deberían evitar bloquear el MCT. También he notado que porque estoy esperando por el MCT ciertas cosas como la ventana python pueden bloquear nuestros eventos para ser enviados hasta la finalización del script python. Este GPExecuteToolEvent en particular puede terminar siendo algo mal reportado porque todos los eventos se acumulan mientras el script está corriendo, luego todos se disparan uno tras otro una vez que el script libera el MCT.
En general, ¿hay algo además de la interacción UI que NO debería incluirse en un QueuedTask? ¿Tienes alguna recomendación para este flujo de trabajo particular o documentación adicional que pueda ayudar a explicar casos de uso más complejos? Parece que la mayoría de los ejemplos de complementos no hacen mucho trabajo por sí mismos, sino que típicamente solo ejecutan comandos Pro SDK.
