There's no need to do the work that OnlineFileRequest does on a separate thread from the DefaultFileSource thread, and having AsyncTasks proxy to other tasks across a thread boundary adds needless complexity.
If the server keeps sending replies considered from the client in the
past (there is no way to tell if the server or client clock is wrong),
the client will try to interpolate a valid expiration time based
on the delta of the expiration intervals sent by the server.
If the intervals are always the same, exponential backoff kicks in
until we get a different expiration time from what we already have.
When we receive an expired tile, we don't immediately retry
because in case the server keeps serving an expired tile, that
would cause an infinite retry cycle.
Now we add an exponential delay, similarly to what we do for
connection errors.
If we don't do this, we can activate a request twice.
The issue here is that we use memory address as the 'key'. So if
we destroy a request, another request might take the same memory
address, or the same 'key'.
The entry at 'pendingRequests' survives the 'cancel()' and is
ultimatelly removed at 'activatePendingRequest()'. This is fine
unless a request is created using the same 'key' before we call
'activatePendingRequest()'.
The check if the request was canceled at 'activatePendingRequest()'
will be no longer valid, activating the request. At the same time
the request will be activated again by the task scheduled at the
constructor of the 'OnlineFileRequestImpl' class.
This allows the FileSource interface itself to support revalidation. We could (and probably should) now rewrite HTTPContextBase implementations as FileSource implementations.
* Move asset:// URL handling to DefaultFileSource.
* AssetFileSource implements FileSource interface and follows familiar implementation patterns.
* Move default implementation to platform/default, zip implementation to platform/android.
* Don't bother with modified / expires / etag -- assets are not cached so it doesn't matter.
* Don't bother with interleaving individual IO calls on the implementation thread. That adds a lot of complexity for very little benefit.
In the cache response case, we don't want the failedRequests logic; cached errors, should they occur, shouldn't affect the scheduling behavior for real requests.
We already had a condition that checks if a response is immediately available for an incoming request. Call the callback there, rather than in addObserver.
In every case where setResponse is called, notify was called soon after. In one case immediately, in another, after intervening functions which are safe to reorder after notifications.
The null-check of response is safe to eliminate because response must not be null inside setResponse.
There is no need for the timer to be created only under certain conditions. Stopping a non-started timer is a no-op. Therefore it can simply be a direct member.
While here, rename the variable. It's a timer, not a request.
