Fixed
Status Update
Comments
gg...@google.com <gg...@google.com> #2
This will be available in 1.0.0-alpha03
al...@gmail.com <al...@gmail.com> #3
Same here, this sounds like a great feature! I'm pretty sure the issue template questions have already been addressed.
su...@google.com <su...@google.com> #4
Hi everyone, we'll look into this. In the meantime, please file WorkManager-specific bugs to "Android Public Tracker > App Development > Architecture Components > WorkManager". We can triage the bugs and feature requests faster this way. Thanks!
su...@google.com <su...@google.com> #5
In the upcoming alpha03 release, Worker will have access to a new method, getRunAttemptCount(), that will return the current run count. Based on this value, you can choose to return a different worker Result and possibly end execution.
The reason I didn't put it in the WorkerRequest.Builder as a max retry count is that it's not clear what State the work should enter if it exceeds the max retry count. Should it be considered CANCELLED (which, so far, is a user-initiated state)? Should it be considered FAILED (that seems wrong)? I think it's better if the developer has control over this so that whatever State the work should be in at the end.
The reason I didn't put it in the WorkerRequest.Builder as a max retry count is that it's not clear what State the work should enter if it exceeds the max retry count. Should it be considered CANCELLED (which, so far, is a user-initiated state)? Should it be considered FAILED (that seems wrong)? I think it's better if the developer has control over this so that whatever State the work should be in at the end.
Description
Oftentimes, we have jobs that we'd like to retry - for example, if network cuts out during a background upload - but we don't want to retry them indefinitely. It would be very useful to specify this as part of the work request, especially for jobs for which we wouldn't otherwise manually track state:
```
class MyWorker extends Worker {
@Override
WorkerResult doWork() {
try {
doSomeNetworkThing();
return WorkerResult.SUCCESS;
} catch (IOException e) {
// Oh no, the network is spotty. Retry, unless this is the Nth attempt, in which case
// just fail
if (/**/) { //
return WorkerResult.RETRY;
} else {
return WorkerResult.FAILURE;
}
}
}
}
```
It would be nice if, instead, we could do this declaratively:
```
new OneTimeWorkRequest.Builder(MyWorker.class)
.setBackoffPolicy(BackoffPolicy.exponential().withMaxRetries(10)) // let's just pretend this API exists
.build();
```
The above API would specify a policy such that, if the `MyWorker#doWork()` returns `WorkerResult.RETRY` 10 times, the scheduler will consider that to be equivalent to `WorkerResult.FAILURE`.