[MUSIC PLAYING]
FLORINA MUNTENESCU: WorkManager provides a set of APIs
that make it easy to schedule asynchronous tasks
for immediate or deferred execution
that are expected to run even if the app is closed
or the device restarts.
For Kotlin users, WorkManager provides first-class support
for coroutines.
In this video, you'll learn the basics
of WorkManager with coroutines by building
on the WorkManager [INAUDIBLE].
So let's get started.
The WorkManager library is the recommended choice for any task
that should continue to run even if the user navigates away
from that particular screen.
If the user puts the application in background
or if the device restarts.
So common tasks could be uploading logs or reporting
data, applying filters to images, or saving the image,
or periodically syncing local data with the network.
But if your immediate task can end when the user leaves
a certain scope--
so if the task should end when the user leaves a screen--
then you should not use WorkManager.
This is a place where you should use Kotlin coroutines directly.
OK, getting back to our [INAUDIBLE],,
the WorkManager [INAUDIBLE] stores an image
and saves our result on disk.
So let's see what was needed to achieve this.
We added a work runtime ktx dependency.
This brings a couple of Kotlin extension functions
and coroutines support.
We started then by implementing our own worker class.
This is where we put the code for the actual work you want
to perform in the background.
You will extend the worker class and override the doWork method.
As this is the most important class,
we'll go over it in detail a little bit later.
Then we build our work request.
In our case, we want to perform the work only once.
So we use a one-time work request filter.
As input, we set the URI of the image we want to block.
And here's a Kotlin tip--
to create the input data, use the workDataOf function
that creates the dataFilter, puts the key value pair,
and creates the data for us.
To schedule the work and make it run,
we use the WorkManager class.
We can provide tasks to be done and constraints to these tasks.
When you use a worker, WorkManager automatic
calls worker doWork on a background threat.
The result returned from doWork informs the WorkManager service
whether the work succeeded and, in case of failure,
whether or not the work should be retried.
Worker doWork is a synchronous call.
You're expected to do the entirety of your background
work in a blocking fashion and finish it by the time
the method exits.
If you call on an asynchronous API in doWork
and return a result, your callback
might not operate properly.
OK, but what if we do want to do asynchronous work?
Let's complicate our example and say
that we want to save the URIs of all the files that have
been blurred in the database.
So for this, I extended the [INAUDIBLE]
and created a simpler blurred image entity,
a Dao class to insert and get images in the database.
If you have to do asynchronous work like saving there
in a [INAUDIBLE] or doing network requests,
in Kotlin, we recommend using a coroutine worker.
A coroutine worker allows us to do asynchronous work
using Kotlin coroutines.
The doWork method is a suspend method.
So this means that we can easily call our suspending Dao
call here.
By default, doWork uses dispatchers on default.
You can override this with a dispatcher that you need.
In our case, we don't need to do this
because Room already moves the insert
work on a different dispatcher.
Check out the Room Kotlin APIs math skills
video for more details.
And that was it.
That is how we used WorkManager to blur images and save
their URIs in the database.
So start using coroutine worker to perform
asynchronous work that needs to complete even
if the user closes your app.
If you want to learn more about WorkManager,
stay tuned for a future series dedicated
to covering it in depth.
Until then, check out our [INAUDIBLE]
and documentation linked in the description below.
Thanks for watching.
[MUSIC PLAYING]