バックグラウンド処理とWorkManager
本連載は、Android Jetpackを紹介しています。今回から3回にわたって、WorkManagerを紹介していきます。今回は、まず、WorkManagerとは何かから話を始めていきます。
サンプルデータは、GitHubから参照できます。
バックグラウンド処理の選択肢
一言でバックグラウンド処理といっても、Androidにはいくつか選択肢が用意されています。例えば、音楽アプリなどは、画面を閉じていても視聴が続けられます。このようなアプリの場合は、Serviceクラスを主に利用したフォアグラウンドサービスを利用します。
また、現在の天気情報を表示するアプリのように、どこかのWeb APIにアクセスしてデータを取得の上、画面に表示させるようなアプリの場合は、Executorを主とした、いわゆるJavaのスレッドを利用した処理になります。Kotlinならば、コルーチンという選択肢もあります。いずれにせよ、いわゆる非同期処理を利用することになります。
これらの選択肢では対応できないバックグラウンド処理が必要な場面があります。例えば、クラウドにデータが保管されているメモアプリを考えます。ユーザはメモアプリに何かを書き込み、アプリを閉じます。アプリは入力されたデータをクラウドに送信する必要があります。それは、たとえユーザがアプリを閉じていても、場合によっては、端末を再起動させたとしても、どこかのタイミングでクラウドに送信されておく必要があります。
このような場合、ここで紹介した2種の方法、すなわち、フォアグラウンドサービスと非同期処理は向きません。フォアグラウンドサービスは、そもそもUIスレッドで動作するものですし、非同期処理はスレッドが分かれているとはいえ、アプリのライフサイクルと関連します。そもそも、端末（Android OS）そのものを再起動されてしまうと、フォアグラウンドサービスであろうが、非同期処理であろうが、それらのプロセスは強制終了し、再起動後に再開することはあり得ません。
バックグラウンド処理実行を保証するWorkManager
このように、場合によってはOSの再起動が行われても、必ず最後まで実行させたい場合に利用する選択肢が、WorkManagerです。WorkManagerは、一度設定されたバックグラウンド処理の実行を、OSレベルで保証する仕組みです。このようなWorkManagerには、大きく以下の2種があります。
- OneTimeWorkRequest：バックグラウンド処理が1回のみ実行される場合に利用する。
- PeriodicWorkRequest：バックグラウンド処理を繰り返し実行する場合に利用する。
WorkManagerを紹介する前編にあたる今回は、OneTimeWorkRequestをベースに、WorkManagerの使い方の基本を紹介していきます。中編と後編は、WorkManagerの応用的な使い方とPeriodicWorkRequestを紹介します。
