Backgrounding the app defeats caching

[1ec5]

If you send the host app to the background and bring it back to the foreground, all visible tiles are forcibly reloaded, HTTP requests and all. At best, the entire map appears to flash in and out. At worst, tiles go AWOL until they’re refetched and rerendered.

Source::update() calls addTile(), which creates a new VectorTileData and calls TileData::request() because the cache introduced in #1255 is empty. It might be worth noting that backgrounding and foregrounding the app causes Map::stop() and start() to be called, respectively.

/cc @ansis @incanus

[jfirebaugh]

Not sure of the current status, but on the 1065-separate-ui-from-map-thread branch, Map::stop() shuts down the rendering thread completely, which basically deallocates everything.

I'm not sure anyone understands the current backgrounding/foregrounding strategy. I've never been able to get anyone to write up an explanation anyway.

[1ec5]

ref #1065

[incanus]

I'm not sure anyone understands the current backgrounding/foregrounding strategy. I've never been able to get anyone to write up an explanation anyway.

I think @kkaefer might, and I know much of this is complicated by various orders of things happening between iOS and Android for these sequences.

[jfirebaugh]

ref #678

[jfirebaugh]

Fixed in #1065.