Categories
android mobile rest sqlite synchronization

How do you handle stale cache records in mobile app

I am in the process of creating an android app (my first) that consumes a REST API.
I use a background job to fetch content and I plan to use a GET request with a from_id parameter in order to get more content. Of course anything fetched from the API gets stored in the SQLite db (I am using greendao) and the app only uses data that is already present there, in order to be snappy.

So, the question is: What happens if a given record is updated on the server? If records once read are cached, how come the app will notice that there are changes to sync? Which strategies are feasible solutions?

Thanks.

EDIT:

As Satish P points out in his answer, the client-server communication is handled with ETag (and I must add the possibility of using If-Modified-Since).

But my main concern, is how to mix this with the app UI. Given this example:

  1. A list of elements, which have been retrieved from the REST service but client-side are read from the local database to make the app more responsive.
  2. User clicks in one of those elements and a detailed view is show. Again, the data is loaded from the local database. I guess that at this point a GET request for the specific record is requested, either with ETag or If-Modified-Since headers.
  3. It happens that the server returns a modified record, thus the local data is modified, so now it’s time to update whatever the user is seeing.

Problem: If the detailed view is already populated because the local database read was already done when the remote request returns, how can I update the view? I don’t think that just replacing current data with the fresher one is acceptable, the user would see a change out of the blue.