In the previous chapter, we have mentioned the term work constraints, but the relevant content is not covered. Also, the related method of delay has been used previously. So in this section, we’ll talk about work constraints.

Work constraints of the WorkManager

Constraints ensure that work is delayed until the best conditions are met. The following constraints apply to WorkManager.

NETWORKTYPE Constrain the type of network required to run the job. Such as wi-fi (UNMETERED).
BatteryNotLow If set to true, work will not run when the device is in “low battery mode”.
RequiresCharging If set to true, work can only run while the device is charging.
DeviceIdle If set to true, the user’s device must be idle before it can work. You are advised to use this constraint if you want to run batch operations. Otherwise, the performance of other actively running applications on the user’s device may be reduced.
StorageNotLow If set to true, work will not run when there is insufficient storage space on the user’s device.

To create a set of Constraints and associate them with a piece of work, create a Constraints instance with contraints.Builder () and assign it to workRequest.Builder ().

For example, the following code builds a work request that will only run if the user’s device is charging and connected to a Wi-Fi network:

Constraints = new Constraints.Builder().setrequiredNetworkType (NetworkType.unmetered) // Set the connection to WiFi .setrequiresCharging (true) // Set is charging. Build (); WorkRequest myWorkRequest = new OneTimeWorkRequest.Builder(MyWork.class) .setConstraints(constraints) .build();Copy the code

If multiple constraints are specified, the work will run only if all constraints are met.

If a constraint is no longer met while the work is running, the WorkManager stops the worker. The system will retry work when all constraints are met.

Delayed work of the WorkRequest

If the work has no constraints, or if all constraints are met when the work is queued, the system may choose to run the work immediately. If you do not want the work to run immediately, you can specify that the work will not start until after a minimum initial delay.

The following example shows how work can be set to run at least 10 minutes after joining the queue.

WorkRequest myWorkRequest =
      new OneTimeWorkRequest.Builder(MyWork.class)
               .setInitialDelay(10, TimeUnit.MINUTES)
               .build();
Copy the code

This example shows how to set an initial latency for OneTimeWorkRequest, and you can also set an initial latency for PeriodicWorkRequest. In this case, scheduled work is delayed only on the first run.

WorkManager’s retry & retreat policy

If you need the WorkManager to work again, you can return result.retry () from the worker. The system will then reschedule the work based on the retreat delay time and the retreat policy.

  • The backoff delay specifies the minimum wait time after the first attempt before retrying the work. This value cannot exceed MIN_BACKOFF_MILLIS (10 seconds).
  • The retreat policy defines how the retreat delay time increases over time during subsequent retries. WorkManager supports two retreat policies, namelyLINEAR 和 EXPONENTIAL.

Each work request has a retreat policy and retreat delay time. The default policy is EXPONENTIAL with a latency of 10 seconds, but you can replace this setting in the work request configuration.

Here is an example of a custom backoff delay time and policy.

​
WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
               .setBackoffCriteria(
                       BackoffPolicy.LINEAR,
                       OneTimeWorkRequest.MIN_BACKOFF_MILLIS,
                       TimeUnit.MILLISECONDS)
               .build();
​
Copy the code

In this example, the minimum backoff delay is set to the minimum allowed, which is 10 seconds. Because the policy is LINEAR, the retry interval increases by about 10 seconds with each retry attempt. For example, the first run ends with result.retry () and retry 10 seconds later; Then, if the work continues to return result.retry () after subsequent attempts, it will retry after 20 seconds, 30 seconds, 40 seconds, and so on. If the retreat policy is set to EXPONENTIAL, the sequence of retries approaches 20, 40, 80 seconds, and so on.

※ Note: The backoff delay time is not accurate. It may vary by a few seconds between retries, but it is never less than the initial backoff delay time specified in the configuration.

Reference literature:

Define the work request | | Android Developers Android Developers (Google, cn)