| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Use the newly added NetworkStatus::Set().
|
|
|
|
|
|
|
|
| |
This API will let the client force a network status. If set
to Offline, we won't make network requests.
When set make to Online, it will trigger the pending requests
and try to fetch tiles from the network.
|
| |
|
|
|
|
|
|
| |
status.requiredResourceCountIsPrecise
Change the name and reverse the sense. Naming things in the positive is better than naming them in the negative.
|
| |
|
| |
|
|
|
|
| |
Instead, the eviction policy accounts for the actual size needed for an incoming put.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When inserting an cached resource, or removing a region, remove least-recently used resources and tiles, not used by offline regions, until the used database size, as calculated by multiplying the number of in-use pages by the page size, is less than the maximum cache size minus 5 times the page size.
In addition, OfflineDatabase may be configured to ignore cache puts of individual resources larger than a certain size.
This policy is similar but not identical to the former SQLiteCache policy:
* It accounts for offline, by exempting resources required by offline regions from eviction.
* It must delete from two tables (resources and tiles), rather than one. Currently the strategy is naive: evict 50 rows at a time from each table.
* It makes maximumCacheSize and maximumCacheEntrySize completely independent. The SQLiteCache implementation evicted when `usedSize > maximumCacheSize - 2 * maximumCacheEntrySize`. This evicts when `usedSize > maximumCacheSize - 5 * pageSize`.
* It uses a non-unlimited default value for maximumCacheSize: 50 MB. We should have always had a limit in place; "a cache without an eviction policy is a resource leak".
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
For AssetFileSource and the node FileSource this was already the case; this makes the other implementations consistent.
|
| |
|
|
|
|
| |
This results in OnlineFileSource containing precisely the logic we want for reuse by OfflineFileSource, and no more.
|
|
|
|
| |
There is no such thing as a cancelled response, only cancelled requests. A request that is cancelled does not have its callback called with a Response.
|
| |
|
| |
|
| |
|
|
|
|
| |
This allows the FileSource interface itself to support revalidation. We could (and probably should) now rewrite HTTPContextBase implementations as FileSource implementations.
|
| |
|
|
|
|
| |
Response::isExpired() had subtle and potentially confusing behavior around Seconds::zero(). It's best to inline it and comment why.
|
| |
|
|
|
|
| |
There is only one implementation and we're unlikely to add more.
|
| |
|
|
|
|
| |
I regenerated assets.zip so that all file paths have an `assets/` prefix, as the Android AssetFileSource implementation asserts, and removed `TEST_DATA` from the paths.
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
When we introduce OfflineFileSource, the behavior of existing tests should
not change.
|
|
|
|
|
| |
* Rename existing DefaultFileSource to OnlineFileSource
* Restore a DefaultFileSource that's a passthrough to OnlineFileSource
|
| |
|
| |
|
|
|
|
|
|
|
| |
Added aliases for std::chrono typedefs (eg. 'Seconds' for
std::chrono::seconds). These aliases are used together with templated
helper functions to replace time_t with std::chrono::seconds for most
cases, in particular for 'modified' and 'expires' values in Response.
|
| |
|
| |
|
|
|
|
| |
This should be abstracted by util::RunLoop
|
| |
|
|
|
|
| |
We're now reparsing tiles when they expire. We're also swapping out buckets atomically to avoid flickering data; i.e. we're displaying the old data as long as we don't have a new parsed bucket for that layer yet. The parsed buckets now live in the *TileData objects rather than in the TileWorker; only partially parsed == pending buckets will remain in the TileWorker. Once they're parsed, they're moved to the *TileData object.
|
| |
|
|
|
|
| |
It's not implemented in GCC 4.9.2's stdlib (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57250). Instead, we're now always using a mutex to protect access; we previously created a mutex only on cancelation, but since we're always canceling now, it makes sense to allocate it right away.
|