Fixed
Status Update
Comments
gg...@google.com <gg...@google.com> #2
Thank you for reporting this And please provide below details for one feature which we need to consider as part of this bug:
Can you please explain in detail what exact you need (Be specific)?
* What is the desired behavior of the feature? (Be specific!)
* If relevant, why are current approaches or workarounds insufficient?
* If relevant, what new use cases will this feature will enable?
Can you please explain in detail what exact you need (Be specific)?
* What is the desired behavior of the feature? (Be specific!)
* If relevant, why are current approaches or workarounds insufficient?
* If relevant, what new use cases will this feature will enable?
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`.