¿Up-sync y down-sync en Android?

synchronization background-process (6)

Estoy trabajando en una aplicación de Punto de Venta que debe ser un mecanismo de sincronización muy bueno. Tenemos Magento Database. El dispositivo Android tiene SQLite Db local. Ahora necesitamos sincronizar de la siguiente manera:

Local ------ Sync To ---------------> Server (Up Sync)

Servidor ------ Sincronizar con ---------------> Locales (Down Sync)

Hay 2 cosas:

1) escribir en (¿Cómo cuidar?)

Por cada cambio que haga en local, sincronizará directamente mi local con el servidor

2) reescritura (¿Cómo cuidar?)

Siempre que haya un cambio en el servidor, necesitamos sincronizar todos nuestros locales con el servidor.

Entonces, la tarea es: identificar una actualización del servidor.

Y sincronizar nuestros locales. Al igual que hay 4 dispositivos que se ejecutan en una tienda y hemos agregado un nuevo cliente a través de un dispositivo. Ahora quiero que los otros tres dispositivos de la base de datos local también se actualicen con la información sobre ese cliente y el servidor también actualizados.

Escuché acerca de los subprocesos de fondo y ejecuté subprocesos después de un intervalo de tiempo. Pero cuál es la mejor manera de hacer eso que no afecta a la aplicación. También todas las grandes tiendas minoristas utilizan el proceso de sincronización. ¿Qué usaron para eso?

Cualquier ayuda es apreciada.

¿Ha considerado utilizar una solución comercial?

http://www.mobeelizer.com/ parece ser lo que quieres lograr. Probablemente hay muchos otros.

Nota: no hay afiliación con esa empresa.

Depende totalmente de su estructura de base de datos ...

tienes DATABASE en LOCAL (device) y en SERVER

AHORA

TIMESTAMP fieLd tener TIMESTAMP fieLd agregado a las TABLES que realmente desea mantener en SYNC.

Cada vez que realice cambios en el servidor, TIMESTAMP se actualizará allí y lo mismo ocurrirá con la base de datos local; también lo que debe hacer ahora es.

Ejecute un servicio en segundo plano que seguirá comparando los TIMESTAMPS de LOCAL con el de SERVER .

Ahora tiene que poner la condición de que si TIMESTAMP de SERVER es más nuevo que LOCAL entonces traiga cambios de SERVER a LOCAL ,

and vice versa will be the condition to take changes from LOCAL to SERVER.

Además, debe decidir con qué frecuencia desea ejecutar este SERVICIO.

ALTERNATIVAMENTE:

Puede hacer la tabla allí en el SERVER que almacenará la fecha de LAST_SYNCHED para un dispositivo en particular

Cada vez que inicie sesión en su dispositivo (o en cualquier otro evento en particular en el que desee que realice esto) el servidor verificará:

cuando este dispositivo fue LAST_SYNCHED
entonces lo comparará con la fecha de hoy
y verificará qué actualizaciones realmente ocurrieron entre estas fechas y enviará los cambios a LOCAL (dispositivo)

y viceversa para LOCAL (dispositivo) a SERVIDOR

Tienes que jugar con TIMESTAMPS . Puedes tener tu propia lógica para estructurar la base de datos.

Les conté lo que he observado cuando formé parte de un proyecto similar.

EDITAR

El proceso anterior define cómo sincronizar los dispositivos con el servidor. Me refiero a la estrategia.

Si desea que sus dispositivos reciban una notificación del servidor cuando se sincronice en lugar de golpear el SERVICIO WEB de forma recurrente ...

Puedes usar PUSH NOtification , GCM es uno de ellos que envía notificaciones push a dispositivos, puedes integrarlo a tu proyecto

Para sincronizar necesitas manejar las siguientes dos situaciones.

Cómo y cuándo recibir actualizaciones del servidor.
Cómo identificar datos locales no sincronizados

Cómo y cuándo recibir actualizaciones del servidor:

Para recibir actualizaciones, podemos utilizar GCM (Google Cloud Messaging) . Si alguna actualización se realiza en el servidor, el servidor envía un mensaje de inserción a todos los dispositivos. Los dispositivos recibirán ese impulso y, según el mensaje, los dispositivos descargarán los datos del servidor. (Creo que este es un mejor enfoque que el servicio de golpeo continuo para algunos intervalos particulares como sondeo)

Para recibir solo datos actualizados del servidor, el servidor mantiene la columna de marca de fecha modificada para todas las tablas. La primera vez que los dispositivos envían una marca de tiempo vacía, el servidor envía todos los datos al dispositivo con la marca de hora del servidor. El dispositivo recibe los nuevos datos y actualiza la base de datos local y guarda la última marca de tiempo del servidor. Para la próxima vez que se obtengan actualizaciones del servidor, el dispositivo enviará la marca de tiempo del servidor almacenado, luego el servidor enviará solo los datos modificados solo después de esa marca de tiempo. Para cada servidor de respuesta que envía la marca de tiempo del servidor, los dispositivos deben almacenar esa marca de tiempo y deben usarlo mientras llaman al servicio.

Cómo identificar datos locales no sincronizados:

Para enviar actualizaciones locales, la base de datos local necesita mantener una columna ''isSynced'' en las tablas. Si alguna fila modificada en isSynced local será falsa, después de sincronizar correctamente los datos locales con el servidor isSynced será verdadera. para que podamos manejar los datos locales actualizados con el servidor.

Actualizado:

Puedes encontrar más información en este enlace de desarrollador.

Si desea datos actualizados en todos los dispositivos, ¿por qué no usa la base de datos remota solamente? ¿Por qué introduce la base de datos local para esto?

En su caso, le sugeriré que trabaje directamente con una base de datos remota, para que las cosas se puedan hacer en tiempo real.

También estoy trabajando en la aplicación de ventas en la que tengo mis objetivos locales para el servidor y los objetivos del servidor para mis objetivos locales

Mi solución es que cada vez que inicie mi aplicación, obtengo los últimos datos de mi servidor de todos mis miembros y actualizo mi base de datos local con estos datos y cuando cambio los datos en mi base de datos local también actualizo en el lado del servidor

También utilicé un botón de sincronización que buscará los últimos datos del servidor si el miembro de mi equipo cambia su objetivo o perfil.

Yo diría que la declaración del problema es incompleta. En la configuración descrita anteriormente, lo que falta es lo que realmente va a sincronizar.

El caso habitual en POS es que existen pocas tablas de índices (id, valor, ...) que se distribuirán desde el servidor central a los dispositivos cliente. En la mayoría de los casos, es la lista de precios, la lista de valores, etc. Esas tablas rara vez deben modificarse en los dispositivos cliente (en realidad podría, pero luego debe redistribuirse desde el servidor central y ser reconocida por los dispositivos cliente).

La otra dirección tiende a ser también bastante sencilla en el dispositivo cliente, ya que genera facturas o facturas. Estos son de nuevo cosas locales que se propagarán hacia el servidor. Por lo tanto, realmente los almacena localmente y en el punto de sincronización los envía al servidor. Más adelante, puede recibir sus propios elementos del servidor como confirmación.

EDITAR: para detectar cambios, las marcas de tiempo de escritura como se mencionaron anteriormente es una necesidad.

Hasta aquí arriba se describe el flujo de datos.

A continuación, debe pasar al dominio de la solución e implementar estas reglas. Hay un par de enfoques de sincronización (ieSyncML). Por otro lado manteniéndolo simple rulez. Por lo tanto, la principal preocupación debe ser algún tipo de bloqueo y puesta en cola que haga que la cosa sea robusta.

También podría usar el cliente basado en el agente, en tal caso, cada dispositivo tiene su propio agente (podría ser una réplica del último estado conocido de la base de datos del dispositivo) pero consideraría esto como una característica avanzada que podría venir en una versión futura :-)