Skip to content

Cache list of nearby places that need pictures #249

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
misaochan opened this issue Sep 4, 2016 · 8 comments
Closed

Cache list of nearby places that need pictures #249

misaochan opened this issue Sep 4, 2016 · 8 comments

Comments

@misaochan
Copy link
Member

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
Copy link
Collaborator

whym commented Apr 15, 2017

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
Copy link
Member

nicolas-raoul commented Apr 15, 2017 via email

@whym
Copy link
Collaborator

whym commented Apr 15, 2017

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
Copy link
Member

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
Copy link
Member

@nicolas-raoul As I commented here:

#2358 (comment)

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
Copy link
Member

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
Copy link
Member

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.

@nicolas-raoul
Copy link
Member

Reformulated as #5664

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants