Bug P3
Status Update
No update yet.
Comments
ia...@gmail.com
One thing I should specifically note is that it was really important that rescheduling the work immediately in doWork() was really important for my use case - waiting until my doWork() would complete (which could take ~a minute+) would cause me to potentially miss further content URI changes.
In addition, I think if content URI work was split off from the other work, I would need unique work support as well. One other option would be that PeriodicWork could support content URIs as an alternative to an interval+flex (of course, naming is hard - RepeatingWork would probably be more appropriate if that architecture was chosen).
In addition, I think if content URI work was split off from the other work, I would need unique work support as well. One other option would be that PeriodicWork could support content URIs as an alternative to an interval+flex (of course, naming is hard - RepeatingWork would probably be more appropriate if that architecture was chosen).
Description
Version used: 1.0.0-alpha01
Devices/Android versions reproduced on: Android Wear running Android O
I have a requirement to continuously listen for content URI changes. I can schedule a OneTimeWork as follows:
workManager.beginUniqueWork(TAG, ExistingWorkPolicy.REPLACE,
OneTimeWorkRequestBuilder<ArtworkComplicationWorker>()
.setConstraints(Constraints.Builder()
.addContentUriTrigger(MuzeiContract.Artwork.CONTENT_URI, true)
.build())
.build()
).enqueue()
And I have to call this same method again in doWork() as there doesn't seem to be any way to repeatedly listen for content URI changes. I'd prefer to split content URI changes out from OneTimeWork as a separate type of work that would repeatedly be called whenever the content URI changes (which I assume would be the wanted behavior in almost all cases).