Basics: Android WorkManager

When developing an android app it is very important not to block the UI- or main thread. Doing so, will lead to a very bad and slow experience for the user. To avoid this from happening Android inc. developed lots of different classes and builders that help schedule tasks asynchronously. One of these tools is the WorkManager and its respective Workers. In the following article I will explain the WorkManager and its building blocks.

The WorkManager is a class that enqueues WorkerRequests that are predefined with custom Workers. Below one can depict an example Worker and how it is scheduled.

public class UploadWorker extends Worker {
   public UploadWorker(
       @NonNull Context context,
       @NonNull WorkerParameters params) {
       super(context, params);
   }

   @Override
   public Result doWork() {

     // Do the work here--in this case, upload the images.
     uploadImages();

     // Indicate whether the work finished successfully with the Result
     return Result.success();
   }
}
WorkRequest uploadWorkRequest =
   new OneTimeWorkRequest.Builder(UploadWorker.class)
       .build();
WorkManager
    .getInstance(myContext)
    .enqueue(uploadWorkRequest);

In this case, which is an example from the Android docs, one can notice that there are different types of WorkRequests, such as the OneTimeWorkRequest and PeriodicWorkRequest. Both have different use-cases that help in different environments. The OneTimeWorkRequest is self explanatory because it does exactly what its name states: It is a one-time Request that is send to the WorkManager and never repeated again. In comparison, the PeriodicWorkRequest occurs multiple times, defined in advance(Can be seen below).

PeriodicWorkRequest saveRequest =
       new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class, 1, TimeUnit.HOURS)
           // Constraints
           .build();

However, both Workers do the exact same in the end, they fulfill asynchronous tasks and protect the main-thread from being blocked. The WorkManager is extremely helpful when it comes to finishing tasks that require a lot of memory and may take some time to complete. For instance, in my future app Chatr, I will use Workers as background tasks that update my chats and messages. By doing this, the user can still interact with the UI and doesn’t need to wait at a loading screen for the action to be completed on the main thread. Nevertheless, Workers can also be used to update a database such as a Room Database frequently with the help of the PeriodicWorker which can also be triggered when the app isn’t open but one still needs new data. One can also start a Worker inside of another Worker to make a seamless thread travel amongst workers. In comparison to the ExecutorService, the WorkManager is more complex but also extremely helpful when one wants to have more specific and customised asynchronous background tasks. However, for shorter and faster tasks the ExecutorService has the upper hand, because it can be started with a simple Runnable Interface and a single thread.

All in all, I hope this short article did help some people understand the WorkManager in better detail. The WorkManager aids the developer in not having to always use the ExecutorService class but to also be able to rely on a new set of asynchronous tools that can be customised in further detail. If anybody has questions about the WorkManager I would be happy to answer your questions and feedback in the comments.