caching of Google Places API results
I'm building a mobile app that lists posts, each post has a place attached to it.
I want the list to be able to show distance from the user's location. without caching anything it would require to store the place reference for each post and while listing fetch the place's geometry from Google Places API, this sounds like a very bad idea.
am I allowed to store the place's id, reference, name and geometry in my db and deliver it with my API? this is for performance purposes only
another implementation might be to cache this data in a local sqlite db on the mobile device, but then the user will have to download the information for each uncached place so for a list of X different places the client will be doing X api calls, sounds slow and battery wasting.
am I allowed to have a central cache in my db in a table that'll be refreshed every once in a while and evicted if not accessed for lets say 30 days ?
Google's page on Places states that Caching of the Places ID is allowed.
The terms in 10.5.d state that you may store limited amounts of content for no more than 30 calendar days for performance reasons. Since this is what you are trying to do, then I would expect that you are ok to store the ID, location and name.
As you start to cache more information then you'll breach the terms of the API. It's not too clear what these are but I think as long as you are being reasonable then you'll be OK.
链接地址: http://www.djcxy.com/p/10822.html上一篇: Socket.IO客户端库缓慢加载