While demonstrating the app in a poor bandwidth area today, the need for local tile caching was sorely apparent.
When we do a build of the app for a specific local area it would make a lot of sense to enable a local tile cache to cover at least that area. An alternative implementation would just be to enable a cache size of x-thousand tiles and implement this as a stack so that new tiles replace much older ones.
seems to suggest that a subclassing implementation to run requests through a local cache would not be hard.
Obviously we should be aware that some tile providers do not permit caching. However, anything coming from the tile.cyclestreets.net server can be cached.
While demonstrating the app in a poor bandwidth area today, the need for local tile caching was sorely apparent.
When we do a build of the app for a specific local area it would make a lot of sense to enable a local tile cache to cover at least that area. An alternative implementation would just be to enable a cache size of x-thousand tiles and implement this as a stack so that new tiles replace much older ones.
http://nshipster.com/mktileoverlay-mkmapsnapshotter-mkdirections/ see "Implementing Custom Behavior with MKTileOverlay Subclass"
seems to suggest that a subclassing implementation to run requests through a local cache would not be hard.
Obviously we should be aware that some tile providers do not permit caching. However, anything coming from the tile.cyclestreets.net server can be cached.