Vyvíjím doplněk, kde je můj hlavní pracovní postup přihlásit se k událostem v ArcGIS Pro a hlásit souhrn důležitých událostí na náš server, který pohání dashboard na webovém klientu. Velkým cílem našeho doplňku je být co nejméně rušivý pro uživatele. Tato myšlenka spolu s potřebou někdy použít MCT nás vede k silnému spoléhání se na QueuedTask.
Typický tok v naší aplikaci je něco podobného tomuto úryvku:
GPExecuteToolEvent.Subscribe((evt) => QueuedTask.Run(() => {
// parseGPEvent může vyžadovat MCT
var parsedEvent = Helper.parseGPEvent(evt);
if (parsedEvent != null) {
var name = $"tool:{parsedEvent.items[0].title.ToLower()}";
// nový konstruktor ArcEvent může vyžadovat MCT
this.ReportEvent(new ArcEvent(name, parsedEvent));
}
}));
Přečetl jsem si některou dokumentaci jako
- 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
Všechny tyto dokumenty vysvětlují, proč je dobré používat QueuedTask a kdy je to vyžadováno, ale žádný z nich opravdu nezmiňuje, co by se mělo v QueuedTask vyhnout kromě uživatelského vstupu. Vím, že existuje několik úskalí, jak jsme zabalili celé parsování události do QueuedTask a některé proměnné se mohou změnit mezi callbackem předplatného a vykonáním QueuedTask. Možná budu muset lépe řešit tuto situaci, ale hlavní obava je, jestli existuje něco, čemu by se mělo explicitně vyhnout v QueuedTask a jaké by mohlo být lepší řešení?
Myslím, že možná náš api volání (uvnitř ReportEvent) by bylo lépe vhodné pro BackgroundTask; nicméně mít události odeslané na náš server ve stejném pořadí, v jakém se staly na klientovi, je poněkud výhodné a dát je do BackgroundTask by znamenalo, že to již nebude garantováno. Nechci blokovat ui thread, takže neumisťovat je do žádného tasku by nebylo ideální, ale také jsem četl, že delší běžící úkoly by se měly vyhnout blokování MCT. Také jsem si všiml, že protože čekám na MCT, některé věci jako python window mohou blokovat odesílání našich událostí až do dokončení python skriptu. Tento GPExecuteToolEvent konkrétně může být trochu nesprávně hlášený, protože všechny události se nahromadí během běhu skriptu a pak všechny po sobě následují spustí, jakmile skript uvolní MCT.
Obecně platí, existuje něco kromě UI interakce, co by NEMĚLO být zahrnuto v QueuedTask? Máte nějaká doporučení pro tento konkrétní pracovní postup nebo další dokumentaci, která by mohla pomoci vysvětlit složitější případy použití? Zdá se, že většina příkladů doplňků sama o sobě moc práce nedělá, ale obvykle jen spouští Pro SDK příkazy.
