Quest Search icons sometimes get stuck onscreen
How to Reproduce
I think it's if you go offline while performing a quest search, that icon stays stuck onscreen. In this state if you subsequently perform another quest search it says you can't as you're offline, but the stuck icon doesn't disappear. You have to wait until you're online again to clear it.
Edit: start a search, switch away from SC, turn off WiFi, return to SC does the trick for me.
Versions affected
Android 9.0 SC v19.1
Can confirm
Hm, actually it is not stuck. It is still downloading. The icon will vanish as soon as the download really stops, and that is when the request times out.
The downloader is oblivious of the fact whether the smartphone is connected or not. If it is not connected, it will simply timeout.
Edit: But of course, the download is only started when the device is connected.
The downloader could listen to connectivity changes and actively cancel the download, that would make the icon (and the download) go away immediately when connection is lost. But I think this would be quite bad for people with an unstable connection(?)
Another option is to reduce the timeout. However, the reason why downloads are not practically instant is not because there is a lot of data being downloaded but because the Overpass API takes some time to answer, sometimes for certain quests, quite long. So, setting the timeout to something short will also not be a good idea.
Do you have any idea how else to solve or mitigate this? Otherwise this'd be a will-not-fix.
Off the top of my head: if the connection is lost, offer a way to manually cancel the search (or always?). Or just hide the indicator and disable the ability to start searching in a new location -- maybe that's also a good place to put a notice that there's no connectivity ("Can't scan for quests when offline").
The downloader could listen to connectivity changes and actively cancel the download, that would make the icon (and the download) go away immediately when connection is lost. But I think this would be quite bad for people with an unstable connection(?)
Yes I think I'd agree there.
Another option is to reduce the timeout. However, the reason why downloads are not practically instant is not because there is a lot of data being downloaded but because the Overpass API takes some time to answer, sometimes for certain quests, quite long. So, setting the timeout to something short will also not be a good idea.
What is the current timeout? I was still seeing it stuck onscreen after 10s of minutes wandering around offline.
Do you have any idea how else to solve or mitigate this? Otherwise this'd be a will-not-fix.
Perhaps fade out/background when offline?
Off the top of my head: if the connection is lost, offer a way to manually cancel the search (or always?). Or just hide the indicator and disable the ability to start searching in a new location -- maybe that's also a good place to put a notice that there's no connectivity ("Can't scan for quests when offline").
They sound good.
The new download indicator is certainly a lot clearer, but it's also a lot more obtrusive if you're trying to map while it's present.
What is the current timeout? I was still seeing it stuck onscreen after 10s of minutes wandering around offline.
180s, that's the server-side timeout of overpass.
I am not sure about the suggestions so far. I think I will leave the ticket open for some time. It is not a bug at least, but maybe enhancable behavior.
What is the current timeout? I was still seeing it stuck onscreen after 10s of minutes wandering around offline.
180s, that's the server-side timeout of overpass.
I've just started a search, switched away from SC, turned off my WiFi (mobile data was already off) and waited 5 minutes and the icon is still stuck onscreen. Pressing the menu and Scan for quests still says "You are offline".
Turning the WiFi back on and leaving it for another 5 minutes that search still doesn't complete.
At this point, pressing Scan for quests offers the stop and scan here or continue prompt. Pressing continue and waiting five minutes still produces no progress.
Then opting for scan here instead finally completes this scan and moves onto the next one.
So something isn't working right with the timeouts, for me at least, I'd suggest the particular behaviour I'm seeing is a bug, especially as it doesn't resume properly when back on the network.
Okay, hm
Tried it on a different device and was able to reproduce it there. Found a bug there: If an error occurs during download and it is cancelled (i.e. connection lost is an error), the service wouldn't set the "is downloading" boolean flag back to false.