Rework network request cancellation and stale request handling

[baka-kaba]

There are some situations where a request should be cancelled when a new one comes in - say you're moving quickly through a bunch of pages by tapping the next arrow, the current request should end as the new one is queued.

This would cut down on unnecessary network traffic (especially if we add a short delay before launching the request, to make sure the user has finished tapping), but it also avoids bugs - it's possible to queue up enough requests that they arrive out of order, so the user ends up looking at the wrong page etc.

There's already code in place to handle this - each AwfulRequest can supply a unique tag, usually as a static member so all the requests of a certain type are grouped together. And NetworkUtils#cancelRequest cancels all queued requests with the supplied tag, so it's possible to interrupt all PostRequests for example (ThreadDisplayFragment does this in #syncThread).

AwfulFragment also has a #queueRequest method that allows you to set a "cancel on destroy" flag, which tags a request with the fragment instead so they can all be cleaned up when it dies. This calls a #cancelNetworkRequests method, which can be overridden to also call NetworkUtils#cancelRequest with a particular request tag to clean up any requests tagged that way too (ThreadDisplayFragment also does this)

if that's all a bit confusing, yep it could do with being reworked

[Sereri]

Like, I'm not saying "this has to stay in", especially because of the discoverability, but this partly was in response to people wanting to cache threads for later reading. Go to a thread, quickly queue the pages that you want to read and you're done.
Honestly it would be nicer to have some sort of GUI around it anyway, so feel free to change this so that it cancels old requests

[baka-kaba]

Yeah but didn't we already remove that? I can page through a bunch of thread pages, and the logs only show some of the requests, so it sorta works. I'm not sure how Volley handles it once the request has been started, I'd have thought it would outright stop the response handling, but it seems like once the (pretty quick) network request comes back with a response, it carries on handling it and delivering the results. It's pretty inconsistent, and I feel like results arriving out of order will cause problems in the depths of the app

And yeah caching is good, but I'd want to make that a separate process that doesn't hammer the site, something a bit like the forum updater that gradually crawls the forum hierarchy. What's the taxman's policy on downloading for offline reading? Thought I heard someone say he's not keen

[Sereri]

Honestly most of Lowtax's "policies" are not really existent and more interpretation. It's like lore or something. As far as I know Lowtax doesn't really care about the apps at all, probably to a fault. However it's better to not piss him off so everyone tries to avoid that. It's kinda like he's old testament god where you don't know how he will react to X, so you try the least offensive version to not make him smite you.