There are many considerations and best practices for handling background work, described in a series of publications of the Google Power blog. One of the recurring call-outs is an Android Jetpack library called WorkManager, which extends the capabilities of the JobScheduler framework API and is compatible with Android 4.0+ (API 14+).
In this blog post, Android training in Chandigarh will explore the basics of WorkManager, how and when to use it, and what happens behind the scenes. Then we will dive into more complex use cases.
What is WorkManager?
WorkManager is one of the Android Architecture Components and part of Android Jetpack, a new and stubborn way to create modern Android applications.
WorkManager is an Android library that runs deferred background jobs when the work’s constraints are satisfied. WorkManager is intended for tasks that require a guarantee that the system will execute them even if the application exits.
In other words, WorkManager provides a battery-friendly API that encapsulates the long-standing evolution of Android background behavior restrictions. This is critical for Android applications that need to run background tasks!
Read also: Build a Modular Android app architecture.
When to use WorkManager?
WorkManager handles the background work that must be executed when several constraints are met, regardless of whether the application process is active or not. Background work can be started when the application is in the background, when the application is in the foreground or when the application starts in the foreground but goes to the background. Regardless of what the application is doing, background work should continue to run or restart if Android removes its process.
A common confusion about WorkManager is that it is for tasks that must be executed in a “background” thread but do not need to survive the death of the process. This is not the case. There are other solutions for this use case, such as Kotlin routines, ThreadPools or libraries such as RxJava. You can find more information about this use case in the background processing guide.
There are many different situations in which you need to run the work in the background and, therefore, different solutions to run the work in the background. This blog post on background processing provides a lot of excellent information on when to use WorkManager. Check out this blog diagram:
In the case of WorkManager, it is better for background work that has to end and is deferred.
To begin, ask yourself:
Does this task need to be completed?
If the user closes the application, is it necessary to complete the task? An example is a note-taking application with remote synchronization; Once you finish writing a note, wait for the application to synchronize your notes with a background server. This happens even if you switch to another application and the operating system needs to close the application to reclaim some memory. It should also happen even if you restart the device. WorkManager ensures that tasks are completed.
Is this task deferrable?
Can we execute the task later or is it only useful if it is executed at this time? If the task can be executed later, then it is deferrable. Returning to the previous example, it would be good to have your notes uploaded immediately but, if this is not possible and synchronization occurs later, it is not a big problem. WorkManager respects the background restrictions of the operating system and tries to execute its work in a battery-efficient way.
Therefore, as a guide, WorkManager is intended for tasks that require a guarantee that the system will execute them, even if the application exits. It is not intended for background work that requires execution at an exact time or requires immediate execution.
If you need your work to run at an exact time (such as an alarm clock or an event reminder), use AlarmManager. For work that must be executed immediately but is long-running, you must often ensure that the work is executed in the foreground; whether that’s by limiting execution to the foreground (in which case the work is no longer true background work) or using a Foreground Service.
WorkManager can and should be paired with other APIs when you need to activate some background work in more complex scenarios:
- If your server activates the job, WorkManager can be paired with Firebase Cloud Messaging.
- If you are listening to broadcasts using a broadcast receiver and then need to activate long-term work, you can use WorkManager. Note that WorkManager provides support for many common Constraints that are normally come through as broadcasts; In these cases, you do not need to register your own broadcast receivers
Why use WorkManager?
WorkManager runs background work while dealing with compatibility issues and best practices for battery and system status.
In addition, with WorkManager, you can schedule both periodic tasks and complex dependent task chains: background work can be executed in parallel or sequentially, where you can specify an order of execution. WorkManager seamlessly handles inputs and outputs between tasks.
You can also set criteria on when the task should run in the background. For example, there is no reason to make an HTTP request to a remote server if the device does not have a network connection. Therefore, you can set a restriction that the task can only execute when there is a network connection.
As part of guaranteed execution, WorkManager is responsible for persisting your work on device or application reboots. You can also easily define retry strategies if your work stops and you want to try again later.
Finally, WorkManager allows you to observe the status of the work request so you can update your UI.
To summarize, WorkManager offers the following benefits:
- Handles compatibility with different versions of the operating system
- Follow the best health practices of the system
- Supports asynchronous one-off and periodic tasks
- Supports chained tasks with input/output
- Allows you to set constraints when the task is executed
- Guarantees the execution of tasks, even if the application or device restarts
Let’s look at a specific example in which we build a pipe of concurrent tasks that apply filters to an image. The result is sent to a compression task and then to an upload task.
We can specify when they can be run and define a set of constraints for these tasks.
All these workers define a precise sequence: eg. We do not 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.
How the WorkManager scheduler works.
To be sure compatibility with API level 14, WorkManager selects an appropriate way to schedule background tasks based on the API level of the device. WorkManager could use JobScheduler or a combination of BroadcastReceiver and AlarmManager.
Is WorkManager ready for production use?
WorkManager is now in beta. This means that there will be no major changes to the API in this important review.
When WorkManager will launch as stable, it will be the preferred way to execute background tasks. For this reason, this is a great time to start using WorkManager and help improve it.
For now, that’s all for this post, there are many things to learn and if you want to learn mobile application development course for creating some real Android apps Android training in Chandigarh is best for you.
Recommended article: Why Choose Android Jetpack to Improve Mobile Development?