Apps-android-commons: Cache list of nearby places that need pictures

[misaochan]

The list of nearby places that need pictures that was implemented in #73 does not explicitly cache the downloaded file that is used as the data source. AFAIK the data is stored temporarily (so if a user goes back to the main screen and then wants to load the list again, it will be very fast this time), but once the app has been closed it needs to be re-downloaded.

[whym]

As of now

• The list taken from wiki-needs-pictures is stored on RAM (NearbyPlaces.places). This will be gone and have to be retrieved again when the app is restarted. Because it is slow and consumes a lot of mobile data to retrieve, caching it in a local storage (normally the SD card) would be nice. Bonus point if it will be automatically refreshed when wifi is available.
• The list taken from Wikidata Query is not cached at all. Mobile data consumption for retrieving this is modest, but still, caching it would be nice for offline usage.

[nicolas-raoul]

(retracted)

[whym]

Isn't it nice if Wikidata-based (somwehat old) results are available when you are going to shoot pictures in an area with very sparse network connectivity for an extended length of time? I admit that supporting this may be something more than a cache, something significantly more complicated than storing a single master CSV of wiki-needs-pictures, though.

An alternative approach may be to allow the user to save a list of "to shoot" places from a map view (which is not implemented yet).

[nicolas-raoul]

I used to think that we should not cache Wikidata, as it only takes a fraction of a megabyte, and is real-time info. Indeed using WikiShootMe I really appreciate being able to see a point disappear from the map immediately after uploading a picture. I only leave the area when there is no point left on the map.

But now I changed my mind because:

• Wikidata queries are quite time-consuming
• I often go to countries where I have no Internet connection, or last weekend I was in the countryside where my operator does not have an antenna, and I could not use Nearby even though there were actually items to shoot in the area.
• The information size is tiny. Even caching everywhere I have ever been in my whole life would probably not even take a megabyte.
• Seeing points disappear from Nearby is enjoyable, but it can be achieved with caching too. When I upload a picture for a particular Wikidata item, just remove that item from the cache. The probability that another Wikidata user is adding pictures for the same area is practically zero.

[maskaravivek]

@nicolas-raoul As I commented here:

https://github.com/commons-app/apps-android-commons/issues/2358#issuecomment-460910579

We can use OkHttp cache implementation to enable caching. I am working on both the points mentioned in my comment. This should make our Nearby loading super quick.

[nicolas-raoul]

Cool! :-)
If we can not invalidate the cache for a particular item (the item I just uploaded a picture for), then I suggest invalidating the whole cache every time I upload a picture via Nearby.
Can OkHttp's cache be invalidated programmatically?

[maskaravivek]

Cool! :-)
If we can not invalidate the cache for a particular item (the item I just uploaded a picture for), then I suggest invalidating the whole cache every time I upload a picture via Nearby.
Can OkHttp's cache be invalidated programmatically?

Yes, the cache control header can be set for any request. Setting it to null would make it not use cache.