Workmanager : Scheduling Jobs in Android

In Android, if we need to enqueue some deferrable work that is a guarantee to execute after some time when the specified constraints are met then we can use WorkManager.

Note that the work should be deferrable i.e. postponed background work. This means any task that doesn't require User Interaction and can run after some time is a deferred task. Workmanager provides the guarantee that the system will run the postponed work even if the app is closed.

Before we used to use other APIs for scheduling tasks like Job scheduler, Alarm Manager with Broadcast receiver, and Firebase Dispatcher. It was a complex and time-consuming task.

Under the hood, Workmanager uses the features of its predecessors in modern and consistent API that supports back to API level 14. 

If a device API level is 14-22, Workmanager will use a combination of AlarmManager and Broadcast Receiver. If the API level is 23 and above, it will choose Job Scheduler. And if our task uses Firebase it will use Firebase Dispatcher.

We can use two types of work requests to schedule tasks with Workmanager : 

1. One time work requests
2. Periodic work requests

For example, if our app shows the details of an inventory, then we can use periodic work requests to schedule tasks to run after a specific period for example 30 min repeatedly. These types of tasks are called Periodic work requests.

And let's say we need to upload data to our server and the internet is not available. Then we can schedule this task to run at an approximate time considering the availability of the internet and the battery charge level of the device. These types of requests are called One time work requests.

Workmanager also offers Flexible Retry Policies, including an exponential backoff policy.

We can also chain our individual work tasks together which allows us to control running the task sequentially or parallel, depending on whatever is our requirement.

Also, Workmanager allows to integrate RxJava and Coroutine which provides the flexibility to plug in your own asynchronous APIs. Workmanager performs the task in background work asynchronously on our behalf.

Setting Up WorkManager : 

We need to first import the library into our Android project. We can find the following dependencies here (https://developer.android.com/topic/libraries/architecture/workmanager/basics).
Add these dependencies in our app Gradle file : 

def work_version = "2.5.0"
implementation "androidx.work:work-runtime:$work_version"

 

To create a work we need to create a Worker class that will extend Worker class and overrides its doWork() method like below.

class SomeWork(appContext: Context, workerParams: WorkerParameters) : Worker(appContext, workerParams) {
    override fun doWork() : Result {
            // Do the task here
            
            return Result.success()
    }
}

 

The doWork() always returns Result. This Result informs the WorkManager service if the task succeeded or failed, which allows it to decide if it should be retried or not.

Result.success(): The work finished successfully.
Result.failure(): The work failed.
Result.retry(): The work failed and should be tried at another time according to its retry policy.

Now in our activity, we will create a function that will run the code to schedule the work. We will use WorkRequest for this.

Here is the sample to create a WorkRequest for one-time work.

 

val someWorkRequest: WorkRequest = OneTimeWorkRequest
                                    .Builder(SomeWork) // pass the name of the Worker class here
                                    .build()

                                                    
Then we need to submit this WorkRequest to WorkManager using its enqueue method :

 

WorkManager
    .getInstance(myContext)  // pass the application context here
    .enqueue(someWorkRequest) // pass the workrequest created in previous step
    

This worker will execute depending on the constraint specified in your work request and system optimization. 

There are 4 states of work: BLOCKED, ENQUEUED, RUNNING & SUCCEEDED.

BLOCKED state happens only when the work is blocked by the chain of works. ENQUEUED occurs as soon as it's next in the chain of workers and eligible to run or if there is some constraint to be met. When work is executing then it's in RUNNING state. And after the completion, it enters into SUCCEEDED state.

We can also observe the status of the WorkManager by Live data and update the UI accordingly. We can also define any retry policy, delay, or backoff policy. We will explore further in the next blog series.