How do you handle obsolete cache entries in a mobile application

Question

I am creating an Android application (my first) that uses the REST API. I am using a background job to retrieve content, and I plan on using a GET request with the from_id parameter to get more content. Of course, everything that is extracted from the API is stored in SQLite db (I use greendao), and the application uses only the data that is already present there to be fast.

So the question is: what happens if this record is updated on the server? If the records that were once read are cached, why does the application notice that there are changes in synchronization? What strategies are feasible solutions?

Thanks.

EDIT:

As Satish P points out in his answer, client-server communication is handled using ETag (and I have to add the ability to use If-Modified-Since).

But my main problem is how to mix this with the user interface of the application. In this example:

• A list of items that have been retrieved from the REST service but from the client side is read from the local database to make the application more responsive.
• The user clicks on one of these items and a detailed view is displayed. Again, data is being downloaded from the local database. I assume that at this point a GET request is being requested for a particular record with either ETag headers or with-Since modification.
• It happens that the server returns a modified record, so the local data changes, so now you need to update everything that the user sees.

Problem: If the detailed view is already populated because the local database was read when a remote query is returned, how can I update the view? I do not think that only replacing the current data with more recent is acceptable, the user will see a change in blue.

Answer 1

Satish's answer is absolutely right in what you need for your server. The bottom line is that it should support ETags and 304 response codes if the content has not changed since the last time it was received from the server. Now on the client side there are three strategies that you can execute (each of them has its pros and cons):

• Use the cache if the content has not changed. This means that you will always make a request and display a progress bar for the user. If the server returns 304, your content has not changed, and the request will be quite fast (the moment you see this, you will show the contents in the cache). If the server actually returns new content, you continue to show a progress bar, and when the content loads, you display the new content. The good thing about this is that the user will only see valid content, therefore avoiding a lot of headaches on your part. The bad news is that the application does not seem so fast (especially if the content has changed and you are in a very slow connection).
• Use only the cache for a predefined period, and then return to the first case. There are a couple of cache headers ("max-age" and "Expires") to define this period. Until this period, you always use the cache (without a request), after which you make a request and see if the contents have changed. The good thing about this method is that during the above period the application is really fast. The bad news is that there is a chance that the user is looking at the wrong content.
• Use the cache and network for a predetermined period, and then return to the first case. You can use the cache headers mentioned earlier in a different way. Instead of showing only cached content, you can actually display cached content and make a request in the background. If this request returns with 304, it’s fine, otherwise you will have to update your user interface with new data (expect two responses, one with cached data and one with recently received data). The positive thing about this is that you get both quick experience and reliable data (most of the time). The negative is that you add a lot of complexity to your application (what happens if the user interacts with outdated data, and then a second answer appears, etc.).

In general, each strategy is valid depending on the use case. For example, if the user cannot interact with the screen on which the data is displayed (for example, the tv program), the third option is pretty good. If it is imperative that the user sees the correct data (say, a financial application), then the best option is better. If speed is more important than having the latest data (game or something else), then the second option is your best bet.

Answer 2

How effectively a client can perform caching depends solely on what support you get from the REST API that your client accesses.

Using ETag is an industry standard that allows you to make client-side caching more efficient, as well as a server, to serve a request faster. In short, ETag LIKE is an MD5 hash of the returned content. Read more about ETag here: http://en.wikipedia.org/wiki/HTTP_ETag

If it's a popular API like Google, Facebook, etc., they basically support ETags. Check out the links below:

Using ETag is best described here: https://developers.facebook.com/docs/reference/ads-api/etags-reference

• When a client performs a GET on a particular resource, the server must include an ETag when responding to it.
• The client must store the ETag for this resource against cached data.
• Whenever a client uses cache information, it must check the cache with an ETag. It may work differently depending on the implementation of the service.
  • Make a regular GET on the resource and include ETag as part of the request. If the content has not changed, the service, ideally, will not return any data, but will give a specific code (304 - not changed). The client knows that the cache remains valid and continues to use it.
  • Make a call to the HEAD resource, and the ETag returns. It is part of the standard HTTP specification. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html (see 9.4). In this case, the Client checks the ETag and decides whether to make a GET call.

An example resource in the above explanation looks below

GET http://serverapi.com/employees/2312312312 

Answer 3

Recently, I have been using GraphQL with Apollo. It processes all of these things automatically, which is simply awesome.

Answer 4

Screen updates can correctly handle Javascript by rewriting certain elements in the DOM - optionally using CSS formatting to pay attention to a change in the user interface - if each anchor point in the user interface has a unique ID / container identifier or can otherwise target JS.

A simple / istic way to defeat some caching is to add a query string to the resource you need. For example, a file called testfile.csv can be easily obtained through testfile.csv? 12345 - and the next time you want to bypass the cache, just refresh the query string, for example, testfile.csv? 23456. If manually updating the query string is difficult in your context, get a little smarter due to modest performance success via PHP: call the resource as testfile.csv so that the query string is automatically updated with every request after the resource is changed; the updated version will be served instead of the cached version.