Working with WorkManager

We have seen how to do work on the main application thread, and we have seen how to use background threads for things like disk and network I/O.

Sometimes, though, we may need to do work that happens completely independently of the UI

• The user requests to download a large file but asks for the download to be performed overnight
• We want to synchronize with a server periodically, such as every couple of hours
• The user asks us to perform some slow on-device task, such as converting a video between formats, and we want to do that work when the device is plugged in and is not being actively used by the user
• And so on

Your primary option for those scenarios is WorkManager.

The Role of WorkManager

This is not to say that WorkManager is the only solution for background work. WorkManager is designed for “deferrable” work — work that you need to have done but does not have to happen right away. This includes the possibility that the work will be done sometime after your current process has terminated, because the user left your app and a lot of time passes before it is time to do your work.

However, there are scenarios for which WorkManager is optimized. Alternative scenarios might be better handled using other techniques:

• WorkManager is designed for discrete, “transactional” tasks, not ongoing work. So, for example, WorkManager is not designed to play music continuously in the background. A “foreground service” is the solution to use for that, with background threads as needed (e.g., for disk I/O to read in the playlist details).
• WorkManager is designed for work that will happen sometime, but not at some specific time. If you need to get control at a specific time — such as to alert the user about an upcoming calendar event — use setExactAndAllowWhileIdle() on AlarmManager.
• WorkManager is designed for work that will happen eventually, but perhaps not immediately. If you have background work that has to be done in real time in response to user input (e.g., download the video that they just purchased), use a simple thread or, better yet, a reactive framework (Kotlin coroutines, RxJava, etc.). If you are concerned that the work might take too long, and your process might be terminated while that work is ongoing, use a foreground service.
• WorkManager is designed for work that might happen completely asynchronously with respect to your current process. Hence, it is not useful for cases where the work that you are doing only affects the current process, particularly its UI. So, for example, downloading avatar icons to display in your app may not make sense once the UI is gone, as you may never need those icons. For that, use a thread pool, reactive solutions (e.g., RxJava, Kotlin coroutines), or libraries that in turn use those sorts of things.

Foreground services and AlarmManager are powerful techniques, but ones that we will not be exploring in this particular book. The Busy Coder’s Guide to Android Development, while older, offers material on those subjects.