Cache API responeses

[tclaus]

Searches for the same query shouldn't send over and over again to the API in a certain period of time.
The results could be stored for some minutes before sending again to the API.
Dont query frequently on weekends.

Don't forget to clear the list if it's getting too old.

[cafeina-software]

The old data that was retrieved should be saved in the app configuration folder. It's not very likely that a company like the data provider would provide historical misleading data, so for the old data it should be cached until the user wants to wipe out the cache and refresh all the data. If there is a expiration date of the cached data, it should not be too soon or too far.

This is specially true because of this:

• if the user is in a location without connection or with an unrealiable connection. The app should be resilient and allow to load the cached data without getting faulty.
• to save in the api calls credit. This is critical if you are a "free developer" user due to the very low number of free api calls per day, but also could help paying customers with the lowest tier subscription and high rate of calls, specially for lower income users that cannot affort paying for the higher tiers with higher perks. Why? because sometimes we go to one chart, then to another and we want to go back to the previous chart, and that data could end up being needlessly retrieved again from the server when it could have been cached while still fresh.
• users with data capped connections (such as using their mobile phones as an internet modem using their mobile data) will want to perform the least number of remote calls as possible if that is for already retrieved data.

[tclaus]

I agree so far with all your points and will keep this in mind when it cones to implementation.