I’m at page 473, and the text says I can run my app and I will eventually see a notification when a new photo becomes available. This hasn’t been my experience, and as I’m reviewing the code, I guess it isn’t my expectation either. My confusion is around the use of a OneTimeWorkRequest (on page 462)… later in the chapter this is changed to a PeriodicWorkRequest, but not by where I’m at now on page 473. Since I’m using a OneTimeWorkRequest, and it is firing right after the app launch and returning a success result, why would there be any expectation that it will fire again?
I have been able to get the notification if I:
- Stop the app while it is on a search.
- Wait a while
- Launch again
If I don’t have a search term current, I’m shorted with the “No saved query, finishing early” message, and no notification is sent.
I guess the code is working like I might expect after reviewing it, but the text on p. 473:
And that is it. Run your app, and you should eventually see a notification icon appear in the status bar (Figure 22.4). (You will want to clear any search terms to speed things along.)
… really makes it sound like this should actually be polling. I’d love any feedback to better understand what is going on - thanks!
Yeah, you are definitely onto something. At this point in the chapter, you are not yet using PeriodicWorkRequest. However, PollWorker will be enqueued every time PhotoGalleryFragment is launched. So essentially, every time you launch the app, another run of PollWorker will be queued up.
I think the confusing part here might be the parenthetical:
(You will want to clear any search terms to speed things along.)
You note that having an empty search query will short circuit the PollWorker and prevent the user from seeing a notification.
I think we at BNR should probably rewrite that sentence. If I changed it to:
(You will want to have a simple query, such as “dogs” or “flowers”, in order to see the notification pop up.)
Would that help clear up some confusion?
Yes - I think that is a definite improvement. Can you help me understand the nature of the OneTimeWorkRequest however?.. it seems to me that the PollWorker does get queued up each time I run the app, but is dequeued and run almost immediately after launch. Once dequeued, it won’t run again, correct? My reading of the book seemed to imply that you could run the app and then wait around for an eventual notification. My experience has been that you can run the app, make a search, kill the app, THEN wait around… launch it a few hours later when there is something new, and you’ll get the notification.
Maybe I’m misreading the book, but that was my struggle: sounded like I could launch and wait, but in reality I need to launch-kill-wait-launch, or launch-wait-kill-launch… I needed a second launch to queue and run the PollWorker and get the notification.
Correct.
You should be able to just launch and wait in the app, BUT it might take a little bit (15 minutes-ish). Once you enqueue the OneTimeWorkRequest, you are kinda left up to the whims of the system. Your device isn’t gonna be a jerk and needlessly wait to perform your request, but it does want to balance your request with the best possible experience for the user. One thing that you could try out is setExpedited(). It is a relatively new feature within WorkManager and it should fire off your work essentially as soon as you request it. Older versions of WorkManager really would make you wait, but it seems like this new API should make things a little easier for you.
Try it out and let me know how it goes.
My PollWorker has always been dequeued and run shortly after the launch of the app… I haven’t experienced any waiting at all. That may be a source of my confusion about what should happen… I just haven’t seen it go as the book has described it.