Fixed
Status Update
Comments
su...@google.com <su...@google.com> #2
This will be available in alpha02. The methods are Worker#isStopped and Worker#onStopped.
Note that "stopping" is a superset of cancellation. onStopped will be called when the Worker is cancelled, but also when it is otherwise pre-empted (say through some constraint not being met).
Note that "stopping" is a superset of cancellation. onStopped will be called when the Worker is cancelled, but also when it is otherwise pre-empted (say through some constraint not being met).
ro...@gmail.com <ro...@gmail.com> #3
Is there a way to differentiate a Worker being halted vs completely cancelled? Imagine a case where a Worker is doing a multipart upload, if the Worker is cancelled we would need to tell the server that no more parts will be uploaded. The issue I see is that enqueuing a separate Worker in onStopped to handle cancelling the upload (on the server) would cause the upload to be cancelled if constraints are unmet while the Worker is running. This means when the constraints are met again and the Worker 'resumes', it would need to start over even if it was 'paused' the middle of an upload.
su...@google.com <su...@google.com> #4
Why not enqueue that second worker when you explicitly cancel that work? Work is only ever cancelled by the developer, not by WorkManager.
ro...@gmail.com <ro...@gmail.com> #5
Work is not cancelled by WorkManager but it can be stopped when constraints are not met, correct? It would be ideal to have a distinction in the Worker between when the work is temporarily stopped vs being permanently cancelled, even if cancellation is only triggered by the developer.
Having special considerations for cancellation outside of the Worker makes little sense when a primary goal is to internalize the actual work being done by a Worker.
Having special considerations for cancellation outside of the Worker makes little sense when a primary goal is to internalize the actual work being done by a Worker.
su...@google.com <su...@google.com> #6
Fair enough, I'll reopen the bug and add some more context. This may potentially be an argument in the onStopped method.
su...@google.com <su...@google.com> #7
This is fixed and will be available in alpha03.
Description
Version used: alpha01
WorkManager exposes method for cancellation of work. However, I currently don't see how this could be used if the work has already started.
Arguably, being able to cancel an ongoing work is very basic and must have functionality. Not being able to do so will render the entire framework unusable in many scenarios. It can also negatively impact the end users (e.g. by consuming too much battery/bandwidth).
Cancellation mechanism should be given a very good thought. As a starting point for a discussion, I propose adding two methods to Worker:
1) protected final boolean isCancelled() - will return true if the work has been cancelled
2) protected void onCancelled() - will be called after WorkManager determines that a specific Worker needs to be cancelled. Default implementation will be no-op.