私はArcGIS Proのイベントにサブスクライブし、重要なイベントの概要をサーバーに報告してウェブクライアントのダッシュボードを駆動するアドインを開発しています。私たちのアドインの大きな目標は、ユーザーへの影響を最小限に抑えることです。その考えと時にはMCTを使用する必要があることから、QueuedTaskに大きく依存しています。
私たちのアプリケーションの典型的なフローは、次のスニペットのようなものです：
GPExecuteToolEvent.Subscribe((evt) => QueuedTask.Run(() => {
// parseGPEventはMCTを必要とする場合があります
var parsedEvent = Helper.parseGPEvent(evt);
if (parsedEvent != null) {
var name = $"tool:{parsedEvent.items[0].title.ToLower()}";
// 新しいArcEventコンストラクターはMCTを必要とする場合があります
this.ReportEvent(new ArcEvent(name, parsedEvent));
}
}));
以下のようなドキュメントをいくつか読みました。
- 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
これらはすべてQueuedTaskを使う利点や必要な場合について説明していますが、ユーザー入力以外でQueuedTaskに含めるべきでないものについてはほとんど触れていません。私たちはイベント解析全体をQueuedTaskでラップしているため、サブスクリプションコールバックとQueuedTask実行間で変数が変わる可能性があるなどいくつか注意点があることは知っています。それについては改善が必要かもしれませんが、主な懸念はQueuedTaskから明示的に避けるべきものがあるかどうか、そしてより良い解決策が何かということです。
おそらくReportEvent内のAPI呼び出しはBackgroundTaskに適しているかもしれません。しかし、イベントがクライアント上で発生した順序でサーバーに送信されることは有益であり、BackgroundTaskにするとその保証がなくなるように思えます。UIスレッドをブロックしたくないのでタスクに入れないのも理想的ではありませんが、長時間実行されるタスクはMCTのブロックを避けるべきだとも読んでいます。また、MCTを待っているためにPythonウィンドウなどがPythonスクリプト完了までイベント送信をブロックすることにも気づきました。特にこのGPExecuteToolEventはスクリプト実行中にすべてのイベントがキューに溜まり、その後スクリプトがMCTを解放すると一気に発火するため、誤った報告になることがあります。
一般的にUI操作以外でQueuedTaskに含めてはいけないものはありますか？この特定のワークフローについて何か推奨事項やより複雑なユースケースを説明する追加ドキュメントをご存知でしょうか？多くのアドイン例はあまり多くの処理をせず、通常はPro SDKコマンドを実行するだけのようです。
