¿Cómo manejas los registros de antememoria de caché en la aplicación para móviles

Estoy en el proceso de crear una aplicación para Android (mi primera) que consume una API REST. Utilizo un trabajo de fondo para buscar contenido y planeo usar una solicitud GET con un parámetro from_id para obtener más contenido. Por supuesto cualquier cosa obtenida de la API se almacena en el SQLite db (estoy usando greendao) y la aplicación sólo utiliza los datos que ya están presentes allí, con el fin de ser ágil.

Por lo tanto, la pregunta es: ¿Qué sucede si un registro determinado se actualiza en el servidor? Si los registros una vez leídos se almacenan en caché, ¿por qué la aplicación se dará cuenta de que hay cambios en la sincronización? ¿Qué estrategias son soluciones factibles?

Gracias.

EDITAR:

Como señala Satish P en su respuesta, la comunicación cliente-servidor se maneja con ETag (y debo agregar la posibilidad de usar If-Modified-Since).

Pero mi principal preocupación, es cómo mezclar esto con la aplicación de interfaz de usuario. Dado este ejemplo:

Se lee una lista de elementos que se han recuperado del servicio REST, pero del lado del cliente, de la base de datos local para que la aplicación sea más sensible.
El usuario hace clic en uno de esos elementos y se muestra una vista detallada. Nuevamente, los datos se cargan desde la base de datos local. Supongo que en este punto se solicita una solicitud GET para el registro específico, ya sea con cabeceras ETag o If-Modified-Since.
Sucede que el servidor devuelve un registro modificado, por lo que los datos locales se modifican, por lo que ahora es el momento de actualizar lo que el usuario está viendo.

Problema: Si la vista detallada ya está poblada porque la lectura de la base de datos local ya se hizo cuando se devuelve la solicitud remota, ¿cómo puedo actualizar la vista? No creo que sólo la sustitución de los datos actuales por el más fresco es aceptable, el usuario vería un cambio de la nada.

La respuesta de Satish es absolutamente correcta en términos de lo que necesita su servidor para hacer. La esencia es que necesita para apoyar ETags y 304 códigos de respuesta en caso de que el contenido no ha cambiado desde la última vez que lo recibió desde el servidor. En el lado del cliente ahora, hay esencialmente tres estrategias que puedes seguir (cada una con sus propios pros y sus contras):

Sólo utilice la caché si el contenido no ha cambiado. Esto significa que siempre hará una solicitud y mostrará una barra de progreso al usuario. Si el servidor devuelve 304, entonces su contenido no ha cambiado y la solicitud será bastante rápida (en el momento en que vea, muestra el contenido en caché). Si el servidor realmente devuelve nuevo contenido, sigue mostrando la barra de progreso y cuando se carga el contenido se muestra el nuevo contenido. Lo bueno de esto es que el usuario sólo verá contenido válido, evitando así muchos dolores de cabeza de su parte. Lo malo es que la aplicación no aparece tan rápido (especialmente si el contenido ha cambiado y usted está en una conexión muy lenta).
Utilice sólo la memoria caché durante un período predefinido y luego vuelva al primer caso. Hay un par de cabecera de caché para definir ese período ('max-edad' y 'caduca'). Antes de ese período siempre se utiliza la caché (sin hacer una solicitud), y después de hacer una solicitud y ver si el contenido ha cambiado. Lo bueno de este método es que durante el período mencionado anteriormente, la aplicación es muy rápido. Lo malo es que existe la posibilidad de que el usuario esté buscando contenido incorrecto.
Utilice el caché y la red durante un período predefinido y, a continuación, vuelva al primer caso. Puede utilizar los encabezados de caché mencionados anteriormente de una manera diferente. En lugar de mostrar sólo el contenido en caché, puede mostrar el contenido en caché Y hacer una solicitud en segundo plano. Si esa petición vuelve con un 304, bien, de lo contrario tendrá que actualizar la interfaz de usuario con los nuevos datos (esperar dos respuestas, una con los datos en caché y otra con los datos recuperados recientemente). El positivo con esto es que usted consigue una experiencia rápida y datos válidos (la mayor parte del tiempo). Lo negativo es que agregas mucha complejidad a tu aplicación (lo que sucede si el usuario interactúa con los datos obsoletos, y luego aparece una segunda respuesta, etc.).

En conjunto, cada estrategia es válida dependiendo del caso de uso. Por ejemplo, si el usuario no puede interactuar con la pantalla que muestra los datos (como un programa de televisión), la tercera opción es bastante buena. Si es crucial que el usuario ve los datos correctos (una aplicación financiera, digamos), entonces la primera opción es la mejor. Si la velocidad es más importante que tener los últimos datos (un juego o algo), entonces la segunda opción es su mejor opción.

La eficacia del cliente para realizar el almacenamiento en caché depende únicamente de la cantidad de apoyo que recibe de la API REST a la que accede su cliente.

Utilizar ETag es el estándar de la industria para hacer que el almacenamiento en caché en el lado del cliente sea más eficiente y también el servidor sirva la solicitud más rápidamente. En breve ETag es COMO un hash MD5 del contenido devuelto. Más sobre ETag aquí: http://en.wikipedia.org/wiki/HTTP_ETag

Si se trata de una API popular como Google, Facebook, etc, que inherentemente soporte ETags. Por favor, mira los siguientes enlaces:

El uso de ETag se explica mejor aquí: https://developers.facebook.com/docs/reference/ads-api/etags-reference

Cuando el cliente hace un GET en un recurso en particular, el servidor al responder con el contenido debe incluir un ETag.
El cliente debe almacenar el ETag para ese recurso contra los datos almacenados en caché.
Cada vez que el cliente está utilizando la información de caché, debe verificar la caché utilizando el ETag. Puede trabajar de múltiples maneras dependiendo de la implementación del servicio de nuevo
- Hacer un GET habitual en el recurso e incluir el ETag como parte de la solicitud. Si el contenido no cambia el servicio idealmente no devolverá ningún dato, sino que le dará un código específico como (304 – Not Modified). El cliente sabe que la caché sigue siendo válida y continúa usándola
- Hacer una llamada HEAD en el recurso y el ETag se devuelve. Es parte de la Especificación HTTP estándar. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html (Consultar 9.4). En este caso, el Cliente verificará el ETag y decidirá si realizar o no la llamada GET.

Ejemplo de un recurso en la explicación anterior es como a continuación

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

La actualización de la pantalla podría ser manejada con bastante gracia por Javascript, reescribiendo elementos específicos en el DOM – opcionalmente aplicando el formato CSS para llamar la atención sobre el cambio en la interfaz de usuario – si cada datum en la interfaz de usuario tiene un ID / Ser blanco de JS.

Una manera simple / istic para derrotar un caching es anexar una cadena de consulta al recurso que desea. Por ejemplo, un archivo denominado testfile.csv se puede acceder fácilmente a testfile.csv? 12345 – y la próxima vez que desee omitir la caché, sólo actualizar la cadena de consulta, por ejemplo, testfile.csv? 23456. Si actualizar manualmente una cadena de consulta es ardua en su contexto, obtenga un poco más inteligente a costa de un golpe modesto en rendimiento a través de PHP: llame al recurso como testfile.csv para que la cadena de consulta se actualice automáticamente en cada consulta después El recurso se modifica; La versión actualizada se sirve en lugar de la en caché.