I am developing a native iPhone app in Titanium. Within this app I am using data from a remote API (which I have developed in Rails 3). I want the user to cache the API data on their phones as much as possible. What I need help with is the concept of caching. What is the best way of doing it? The nature of the data in the API is that 开发者_开发百科it needs to be up to date. Because it is contact data that can change anytime.
I have no clue in how the cache process would work. If you someone can explain the best way of managing a caching process for the API I would be more than happy!
I am using JSON and Javascript.
"The nature of the data in the API is that it needs to be up to date. Because it is contact data that can change anytime"
If that's true then it makes any kind of caching redundant, as you would need to compare the cache to live data to check for changes, thus making the cache itself pointless.
The only reason you may still want to cache the data is to have it available off-line. That being the case i would use an SQLite database, which is native to the iphone.
titanium-cache is clean code with a unit tests and provides some sample code in the readme. I integrated this with my own project in a matter of minutes and it worked nicely.
I think the type of cache it's application dependent.
You can cache data on:
- client;
- server;
- other network element.
Critical point is refresh of data. A bad algorithm produce inconsistent data.
You can find interesting information on literature of distributed systems
Bye
A couple options here.
1) You can use ASIHTTPRequest and ignore cache headers to cache everything. When your app is being used, you can detect if the cache is being hit. If it is hit, you fire off a request to the server after the cache hit to request any new data. You can do this by appending a random URL param to the end of the URL since the cache keys off of the URL. If you have a good connection and new data, load it in. Otherwise do nothing and your user has the latest data when using the app under a good connection
2) Do most of #1 by always hitting the cache but instead of firing a non-cachable version of the same request to the server after hitting the cache, fire off a non-cacheable timestamp check to see if data was updated. If it has been, fire off the non-cachable full API request. If it hasn't or it fails, you can do nothing.
精彩评论