UWP と AppService と BackgroundTask

IoT Core は UWP で、UWPアプリとしてやりたいことを実行するのだけれど、そのUWPアプリについてさっぱり知らなかったのが敗因だった。

いまだに分かっていないのだけれど、以下のような経過をたどった結果の整理をメモしておく。

なお、やりたいことは「センサーのデータを短い間隔で取得し続ける」こと。

GUIのアプリでは、実行されている間はできていた
AppService で処理するようにしたら、関連するアプリを落としたら処理が終わってしまった
どうやら、普通のBackgroundTask として実装するのがよさそうだと気づいた

UWP アプリ

msdn.microsoft.com

まぁなんだ。制約事項が頭に来るはずもない。

しっかり開発するならこの辺りの資料をしっかりと読むべきなのだけれど、脊髄反射でとりあえず動かしたいお年ごろには辛い。

今回のはまりどころは主にリソースへのアクセス権限と、ライフサイクルに関する部分。（この辺りはAndroidアプリや、iOSアプリと同様なんじゃないかなぁ？）

UWPアプリは原則として自分が所属している空間（大体はユーザー、アプリごとに異なるフォルダ）のリソースにしかアクセスできない。そのため、他のアプリに所属しているリソースは参照できない。

ライフサイクルに関しては、Running（大体においてGUIが表示されている状態）ではないときには一切の実行が止まる。常に処理をし続けたいといった要求を実現するには、そのための仕組みに則る必要がある。

これらはそれぞれ、AppService と BackgroundTask で解決できる。

msdn.microsoft.com

AppService

msdn.microsoft.com

要点はここ。

アプリサービスは、バックグラウンドタスクとして実装されます。これにより、フォアグラウンドアプリケーションは、背後でタスクを実行する、別のアプリケーションのアプリサービスを呼び出すことができます。

あるアプリは他のアプリのリソースにはアクセスできない。これを解決する為の手段が AppService であるようだ。

他のアプリに公開してもいい処理やリソースを AppService として実装する。

動きとしては、ライフサイクルを知っておくのが重要だ。

バックグラウンドタスクが作成されると、Run() が呼び出されます。バックグラウンドタスクは Run が完了すると終了するため、バックグラウンドタスクが要求に引き続き対応できるように、コードは保留されます。

AppService は後に書く BackgroundTask の1種で、Run() を抜けてもタスクが終了しないようにする手段も同じ。

タスクが取り消されると、OnTaskCanceled() が呼び出されます。タスクが取り消されるのは、クライアントアプリが AppServiceConnection を破棄したとき、クライアントアプリが中断されたとき、OS がシャットダウンまたはスリープ状態になったとき、または OS がリソース不足になりタスクを実行できなくなったときです。

ただし、AppService は、サービスを必要としていたアプリの都合で終了する。

バックグラウンドで定常タスクを実行するような用途には向かない。それらは、通常のBackgroundTaskとして実装、実行することになる。