In Google I/O 2019, they introduced expanded and rebranded the Architecture Components into a larger umbrella of tools, components, and architectural guidelines, called Android Jetpack. For me, one of the more exciting additions that Google added to Jetpack this year was a new architecture component called, WorkManager. WorkManager is now in Stable release 2.2.0.

Challenges in background processing

• Background task consumes a device’ limited resources, like RAM and battery. It’s give poor experience for user if not handled correctly.
• If we want to maximise battery and enforce good app behaviour, Android OS restricts background work when app in (foreground) is not visible by user.
• Android 6.0 (API 23) introduced Doze mode and standby
• Android 7.0 (API 24) introduced Doze-on-the-go
• Android 8.0 (API 26) introduced limited background behaviour
• Android 9.0 (API 28) introduced App standby Buckets

What is WorkManager?

One of the Android Architecture component and part of Android Jetpack
using WorkManager we can schedule a deferrable and asynchronous task that is expected to run even if the app exits or device restarts and when the work’s constraints are satisfied.

Key Feature

• Backwards compatible up to API 14
• Add work constraints like network availability or charging status
• Schedule asynchronous one-off or periodic tasks
• Monitor and manage scheduled tasks
• Chain tasks together
• Ensures task execution, even if the app or device restarts
• Adheres to power-saving features like Doze mode

Constraints

A specification of the requirements that need to be met before a WorkRequest can run. By default, WorkRequests do not have any requirements and can run immediately. By adding requirements, you can make sure that work only runs in certain situations — to give an example, when you have an unmetered network and are charging. Below are various Constraints,

• requiresStorageNotLow()
• requiresBatteryNotLow()
• requiresCharging()
• requiresDeviceIdle() — This works after API 23
• getRequiredNetworkType():

WorkRequest can be of two type

OneTimeWorkRequest– That means you requesting for non-repetitive work.

PeriodicWorkRequest– This class is used for creating a request for repetitive work. This work executes multiple times until it is cancelled, with the first execution happening immediately or as soon as the given Constraints are met.

This work executes multiple times until it is cancelled, with the first execution happening immediately or as soon as the given Constraints are met.

Periodic work has a minimum interval of 15 minutes.

If you need to schedule work that happens exactly at a certain time or only during a certain time window, you should consider using OneTimeWorkRequests.

The normal lifecycle of a PeriodicWorkRequest is ENQUEUED -> RUNNING -> ENQUEUED. By definition, periodic work cannot terminate in a succeeded or failed state, since it must recur.

Dependencies

dependencies {
  def work_version = "2.2.0"

// (Java only)
implementation "androidx.work:work-runtime:$work_version"

// Kotlin + coroutines
implementation "androidx.work:work-runtime-ktx:$work_version"

// optional - RxJava2 support
implementation "androidx.work:work-rxjava2:$work_version"

// optional - GCMNetworkManager support
implementation "androidx.work:work-gcm:$work_version"

// optional - Test helpers
androidTestImplementation "androidx.work:work-testing:$work_version"}

Let’s see an example where we schedule concurrent tasks that applies filters to an image. The result is then sent to a compress task and then to an upload task. We can define a set of constraints for these tasks and specify when they can be executed:

All these workers define a precise sequence: e.g. we don’t know the order in which the images will be filtered, but we know that the Compress worker will start only after all the Filter workers have completed.

If you need to schedule background work follow below thing.

WorkManager’s Resources

• Documentation
• Reference guide
• WorkManager Release notes
• Codelab
• StackOverflow

Presentation

Check My Github Repository

Conclusion

Now WorkManager API is stable channel, it is a great choice to schedule and perform tasks in the background in your Android app. It could be the ideal API to use because of its ease-of-use and regular API updates, thanks to Google making it a part of the Android Architecture Components.

If you have any difficulty in understanding or anything I have missed in the process, please let me know in the comments below.