Work manager start android

Урок 30. WorkManager. Критерии запуска задачи.

В этом уроке задаем критери для запуска задачи.

Полный список уроков курса:

WorkManager позволяет нам задать критерии запуска задачи, например — включенный интернет на девайсе. Когда вы передадите такую задачу в WorkManager.enqueue, то будет выполнена проверка, что есть интернет. Если он есть, то задача запустится. А если его нет, то задача будет висеть в статусе ENQUEUED, пока инет не появится.

Если задача запущена и интернет по каким-то причинам пропал, то задача будет остановлена и снова запланирована (ENQUEUED).

Давайте рассмотрим, какие критерии мы можем задать.

Для примера будем использовать такую задачу.

Цикл из 10 пауз и логирование статуса isStopped. Если задача была остановлена, то выходим с статусом FAILURE.

Также логируем метод onStopped.

В Activity код для отслеживания статуса задачи:

setRequiresCharging (boolean requiresCharging)

Критерий: зарядное устройство должно быть подключено.

Код добавления критерия выглядит так:

В Constraints.Builder включаем критерий setRequiresCharging, создаем объект Constraints и передаем его в OneTimeWorkRequest.Builder в метод setConstraints.

Для теста я запустил задачу при отключенном зарядном устройстве, затем включил зарядку, затем снова выключил зарядку.

21:06:40.077 onChanged: ENQUEUED
21:06:57.866 doWork: start
21:06:57.872 onChanged: RUNNING
21:06:58.867 0, isStopped false
21:06:59.868 1, isStopped false
21:07:00.869 2, isStopped false
21:07:01.871 3, isStopped false
21:07:02.266 onStopped
21:07:02.279 onChanged: ENQUEUED
21:07:02.872 4, isStopped true

21:06:40
При запуске задача была поставлена в ожидание, потому что критерии запуска не были выполнены — зарядное устройство не было подключено.

21:06:57
Я подключил зарядное устройство и WorkManager запустил задачу. Она начала выполняться, статус isStopped = false.

21:07:02
Я отключил зарядное устройство. Критерий не выполнен, задача остановлена (onStopped) и снова запланирована (ENQUEUED).
Флаг isStopped теперь равен true, мы это обрабатываем и выходим из цикла.

Обратите внимание, что статус FAILURE нам не пришел. Т.е. при остановке задачи полностью игнорируется ее результат.

На всякий случай напомню, что запланированная задача никак не зависит от приложения. Можно запустить задачу и закрыть приложение. Потом через какое-то время включить зарядник и задача начнет выполняться.

Остальные критерии устанавливаются и ведут себя аналогично, поэтому я уже не буду приводить код, а только кратко опишу.

setRequiresBatteryNotLow (boolean requiresBatteryNotLow)

Критерий: уровень батареи не ниже критического.

Я проверил этот критерий на AVD эмуляторе. Задача начинает выполняться при уровне заряда больше 20, а останавливается при меньше 16.

setRequiredNetworkType (NetworkType networkType)

Критерий: наличие интернет.

Мы можем указать, какой именно тип сети интернет (NetworkType) должен быть при запуске задачи:

CONNECTED — WiFi или Mobile Data
UNMETERD — только WiFi
METERED — только Mobile Data
NOT_ROAMING — интернет должен быть не роуминговый
NOT_REQUIRED — интернет не нужен

setRequiresDeviceIdle (boolean requiresDeviceIdle)

Критерий: девайс не используется какое-то время и ушел в спячку. Работает на API 23 и выше.

setRequiresStorageNotLow (boolean requiresStorageNotLow)

Критерий: на девайсе должно быть свободное место, не меньше критического порога. Не придумал, как это можно быстро протестить, поэтому не могу подсказать сколько это в мегабайтах.

addContentUriTrigger (Uri uri, boolean triggerForDescendants)

Критерий: задача запустится, когда обновится содержимое указанного Uri. Что означает флаг triggerForDescendants — я пока не знаю. Как только выясню, напишу. Работает на API 24 и выше.

Для одной задачи можно задавать сразу несколько критериев.

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме

Источник

Working With WorkManager in Android Like A Pro

How can we schedule our application tasks at a particular time or periodically? How can we add constraints to our scheduled task like network availability(only Wifi some times) or if the device is charging? We see such tasks occurring in our day to day applications like WhatsApp and PlayStore App updates. Can we chain up such tasks together? We have a solution for all these questions and many more in Android Development.

Work Manager

Welcome to the Android-Work Manager blog.

So let’s discuss Work Manager and its use in background processing in this blog.

We have a lot of ways to do background processing in Android, like AsyncTasks, Loaders, Alarm Managers, etc., Which one to use when? How can we come to a decision on the same?

For more information, please refer to background processing guide

As an Android Developer, we should have an idea of the latest optimizations Android is coming up with its newer versions of OS being released for better performance. Also, we cannot guarantee every android device being used in the market contains the latest version of the Android OS installed. So, we should think about backward compatibility to reach the maximum number of devices that are present in the market(at least a min SDK of KitKat).

So how do we categorize our work that needs to be scheduled based on its importance?

Let’s say our work is to open a contacts screen by clicking on the Contacts button. This is something that is only related to the UI part. Hence the main thread or the UI thread is enough to perform this piece of work. We don’t need this to be done when our device is in doze state. This is an example of a Foreground Service. It’s a guaranteed execution and it needs to be done immediately.

Now, let’s say we have to perform a task but it need not be immediate. Like you want to set a reminder for the day after tomorrow at 8 pm. Now, this reminder will occur nearly after 48 hrs. So the device can be in a doze mode or alive during this period. We have a handful of APIs to perform these tasks. Like Job Schedulers, Firebase Job dispatchers, or Alarm manager with Broadcast receivers in the previous versions.

Now, what if we have a functionality that needs all the properties of these APIs. We tend to come with a combination of all the APIs discussed. That’s a lot of APIs to be used for in a single application. This is where WorkManager comes into the picture.

BackWard Compatible

WorkManager is Backward compatible up to API 14 -Uses JobScheduler on devices with API 23+, Uses a combination of BroadcastReceiver + AlarmManager on devices with API 14–22

WorkManager is intended for tasks that are deferrable — that is, not required to run immediately — and required to run reliably even if the app exits or the device restarts. For example:

• Sending logs or analytics to backend services
• Backing up user data with Server on a Periodic basis (Eg: WhatsApp, Google, etc.,)

Constraint Aware

WorkManager is constraint aware. In our day to day usage, we see our phone getting the latest software updates and we are requested to keep our devices in charging mode for these updates to happen as it may take time and insufficient charge can lead to improper installation of software. Sometimes, we see our apps getting updated as soon as we connect our phones to our power adapters. These kinds of tasks are constraint aware.

Accepts Queries

WorkManager is Queryable. A work that is handed off to the system by the WorkManager can be in a Blocked State, Running State or a Cancelled State. We can get the state of the work by passing the id of the Work like below:

By doing this, we can improve the UX by displaying a progress bar while the task is being executed by the work manager.

Chainable

WorkManager is Chainable. Let’s say we have a series of works that are dependent on each other, we can chain them up with Work Manager. You can also specify the order in which the works that are chained should be done.

Let’s say we want to upload photos to the server. For this task to be done, let’s say we want to compress the images first and then upload it. These tasks need to be done on a background thread as they are time taking tasks and it is evident in this case that they are dependent on each other. We can chain up these tasks by using the Work Manager.

In the above code snippet, work 1, work 2 and work 3 can be referred to as three different images that are extracted in parallel since they are a part of beginWith(). work 4 can be referred for compress and then work 5 can be upload. This way we can chain up our tasks.

WorkManager can be used to perform a unique task(OneTimeWorkRequest) or a recurring task(PeriodicWorkRequest) based on the requirement.

In order to execute a OneTimeWorkRequest or the PeriodicWorkRequest, we have to pass the work to these requests which are our Worker class. This is where our business logic is written in the doWork() method:

The doWork() method runs on the background thread. We can see here a success result is returned once the uploadImages is successful. The other two enum values for the return type are a failure and retry. Return types success and failure are fairly obvious, but what does retry do here? Let’s say we are performing a task with a Work Manager with a constraint that is network connected. If the network get’s disconnected in the midst of the work being done, we can retry the task.

Inputs and Outputs

Not just this, we can create data as inputs and get outputs as data with respect to WorkManager requests. The inputs and outputs are stored as key-value pairs in the Data object.

So, how do we create a data object? Let’s create a simple map in kotlin and convert it into a workData so that it gives a Data object

Now, where can we retrieve this data? It can be done in the overridden doWork method in our Worker class

Now, we see that the compressImages is returning a map of images mapped to their respective sizes. Let’s say we need this data. We can set the output from our worker thread as a Data object.

If we are using a chain of work requests here, the key observation is that the output of a worker will become input for its child workRequests.

Let’s say we use a UploadWorker after the CompressWorker, the compressedImages that is executed in the CompressWorker can be an input to the UploadWorker. It can be retrieved similarly in the doWork method of the UploadWorker class.

This works fine if we have only one worker request chained with another work request. What if we have multiple work requests(running parallel) chained with another work request that needs input from all these parallelly running work requests like

What if the input for work 4 should be the combined output of work 1, work 2 and work 3? InputMerger to the rescue.

InputMerger

InputMerger is a class that combines data from multiple sources into one Data object. There are two different types of InputMergers provided by WorkManager:

OverwritingInputMerger (default) attempts to add all keys from all inputs to the output. In case of conflicts, it overwrites the previously-set keys.

ArrayCreatingInputMerger attempts to merge the inputs, creating arrays when necessary.

Important note:

There might be instances where we get outputs containing similar keys. So, we must be cautious in choosing our Inputmergers. If we want to override the key values, we can go for OverwritingInputMerger. If we want to save all the instances of the respective Key, we have to use ArrayCreatingInputMerger. It creates an array of values(if the values for a key are more than one) for the respective key.

Exception-Example case study for ArrayCreatingInputMerger:

Let’s say we have a key, “age”. One work request has value 30(Int) in it for this key. Another work request has value “three days”(String) in it for the same key. Can the ArrayCreatingInputManager merger these values and create an array for the key “age”? No. It gives an exception. So, it is expected that the datatypes of the values for similar keys should be the same.

How to use InputMerger

Work Manager can cancel the unwanted tasks or tasks that are scheduled by mistake. All that we need to do is to send the task id to cancelWorkById() method :

The Tag Support

The ids that we are referring to here are auto-generated and generally large numbers that are not easily readable by humans. Let’s say we have to log them we are unsure whether we are logging the correct workRequest Id. To overcome this issue, each work request can have zero or more tags. We can query or delete our work requests by using these tags.

Now, if we want to see the status of all the works that are associated with a given tag, we can just use

The above statement returns a LiveData
> as more than one work request can be associated with a single tag. We can use this result to get the statuses like

Similarly, we can use the tags to cancel the work like:

Existing Work-Keep it unique or Add Operations with Keep, Replace and Append

Keep, Replace and Append

These three properties add advantage to using Work Manager.

Let’s say we have a work request with tag “image_1” that is already enqueued with the WorkManager.

Let’s say we define this work request to upload a particular image. And if by mistake, we click on upload the same image, this property helps us in not repeating the task.

So, if there is work already with “upload” ongoing, it will keep that request. If there isn’t one, it will enqueue this particular request.

Replace

This will replace any ongoing work with the name “upload” and replaces it by enqueuing this particular work.

Append

This helps in appending the respective work request to an already existing unique work request with the name “upload”(if it exists)

Note: Please be careful when you add the constraints to the work requests in a chain of work requests. Each and every work request that is being chained may not need the same constraints. For example, if our work request contains image upload and we are chaining compress image and upload image work requests together, compressing an image may have constraints related to storage and uploading image can have a constraint with respect to the network connection. So, add the constraints accordingly.

References

Work Manager from the Android Developers Youtube Channel from Google i/o 18.- This video link also describes how the Work Manager operates under the hood. A snapshot of the same is being give here:

That’s all about WorkManager! Hope this article has been of use to you and has given you a basic idea of how Work Manager is useful for us.

Источник