Up-Sync и Down-Sync в Android?

Я работаю над приложением Point of Sale, которое должно быть очень хорошим механизмом синхронизации. У нас есть Magento Database. У Android-устройства есть SQLite local Db. Теперь нам нужно выполнить синхронизацию следующим образом:

Локальный ------ Синхронизация с --------------- > Сервером (Up Sync)

Сервер ------ Синхронизация с --------------- > Локали (синхронная синхронизация)

Есть 2 вещи:

1) write-to (Как позаботиться??)

Для каждого изменения, которое я делаю на локальном, оно будет напрямую синхронизировать мой локальный сервер

2) write-back (Как позаботиться???)

Всякий раз, когда происходит смена сервера, нам необходимо синхронизировать всех наших локальных серверов с сервером.

Итак, задача: определить обновление сервера

И синхронизируй наших локальных жителей. Как и в магазине есть 4 устройства, и мы добавили одного нового клиента через одно устройство. Теперь я хочу, чтобы три других локальных db устройства также обновлялись с информацией о том, что клиент и сервер также обновлены.

Я слышал о потоках фона и запускает потоки после временного интервала. Но лучший способ сделать то, что не влияет на приложение. Кроме того, все магазины Big Retail используют процесс синхронизации. что они использовали для этого?

Любая помощь приветствуется.

Ответ 1

Это полностью зависит от структуры вашей базы данных...

у вас есть DATABASE в LOCAL (device) и на SERVER

NOW

Вам нужно добавить TIMESTAMP fieLd в TABLES, который вы хотите сохранить в SYNC.

Когда вы сделаете какие-либо изменения на сервере, там будет обновлен TIMESTAMP, и то же самое будет и для локальной базы данных, и теперь вам нужно сделать то, что вам нужно сделать.

Запустите службу в фоновом режиме, которая будет продолжать сравнивать TIMESTAMPS LOCAL с SERVER.

Теперь вам нужно поставить условие, что если TIMESTAMP of SERVER является более новым по сравнению с LOCAL, то приведите изменения от SERVER до LOCAL,

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

Далее вам нужно решить, как часто вы хотите запустить эту службу.

АЛЬТЕРНАТИВЫ:

Вы можете сделать таблицу там на SERVER, которая сохранит дату LAST_SYNCHED для определенного устройства

Всякий раз, когда вы войдете в свое устройство (или любое другое конкретное событие, на которое вы хотите его выполнить), сервер проверит

когда это устройство LAST_SYNCHED
то он будет сравнивать его с ДЕНЬЮ СЕГОДНЯ
и проверит, что произошло с этими датами и отправит изменения в LOCAL (устройство)

и наоборот для LOCAL (устройство) для SERVER

вам нужно играть с отдыхом TIMESTAMPS, у вас может быть своя логика, как структурировать базу данных.

Я рассказал вам, что я наблюдал, когда я был частью подобного проекта

ИЗМЕНИТЬ

Вышеописанный процесс определяет, как синхронизировать устройства с сервером, я имею в виду стратегию.

Если вы хотите, чтобы ваши устройства получали уведомление от сервера, когда синхронизировать, а не нажимать WEB-SERVICE повторно..

Вы можете использовать PUSH NOtification, GCM - это один из них, который отправляет push-уведомления на устройства, вы можете интегрировать его в свой проект

Ответ 2

Для синхронизации вам необходимо обработать следующие две ситуации.

Как и когда получать обновления сервера
Как определить локальные несинхронизированные данные

Как и когда получать обновления сервера:

Для получения обновлений мы можем использовать GCM (Google Cloud Messaging). Если какие-либо обновления, сделанные на сервере, сервер отправляет push-сообщение всем устройствам. Устройства получат этот push и на основе сообщения, устройства будут загружать данные с сервера. (Я думаю, что это лучший подход, чем непрерывная работа по удалению для некоторых определенных интервалов, таких как опрос).

Для получения только обновленных данных с сервера сервер поддерживает колонку modified_timestamp для всех таблиц. Первые устройства будут отправлять пустую временную метку, чтобы сервер отправил все данные на устройство с меткой времени сервера. Устройство получает новые данные и обновляет локальную базу данных и сохраняет последнюю метку времени сервера. В следующий раз, чтобы получить обновления сервера, устройство отправит сохраненную временную метку сервера, после чего сервер отправит только измененные данные после этой отметки времени. Для каждого сервера ответов отправляет отметку времени сервера, устройства должны хранить эту метку времени и должны использовать ее при вызове службы.

Как определить локальные несинхронизированные данные:

Для отправки локальных обновлений local db необходимо поддерживать один столбец "isSynced" в таблицах. Если любая строка, измененная в local isSynced, будет ложной, после успешной синхронизации локальных данных на сервере isSynced будет true. так что мы можем обрабатывать локальные данные в актуальном состоянии с сервера.

Обновлено:

Дополнительную информацию об этом ссылку разработчика

Ответ 3

Рассматривали ли вы использование коммерческого решения?

http://www.mobeelizer.com/ кажется тем, чего вы хотите достичь. Есть, вероятно, много других.

Примечание: нет связи с этой компанией.

Ответ 4

Я бы сказал, что постановка задачи неполна. В описанной выше настройке отсутствует то, что вы собираетесь синхронизировать.

Обычный случай в POS заключается в том, что существует несколько индексов (id, value,...), которые должны быть распределены с центрального сервера на клиентские устройства. В большинстве случаев это прейскурант, список акций и т.д. Эти таблицы редко должны быть изменены на клиентских устройствах (на самом деле это может быть затем перераспределено с центрального сервера и подтверждено клиентскими устройствами).

Другое направление, как правило, также довольно просто на клиентском устройстве, которое вы создаете счета или счета-фактуры. Это снова локальные материалы, которые должны распространяться на сервер. Таким образом, вы фактически храните их локально и в точке синхронизации отправляете их на сервер. Позже вы можете получить свои собственные элементы с сервера в качестве подтверждения.

РЕДАКТИРОВАТЬ: для обнаружения изменений метки времени записи, как указано выше, являются обязательными.

До сих пор описанный выше поток данных.

Затем вам нужно перейти в область решений и реализовать эти правила. Существует несколько подходов синхронизации (т.е. SyncML). С другой стороны, это простое правило. Таким образом, основная проблема должна заключаться в том, что блокировка и очередность делают ее надежной.

Он также может использовать клиент на основе агента, в этом случае у каждого устройства есть собственный агент (может быть реплика последнего известного состояния устройства db), но я бы рассматривал это как дополнительную функцию, которая может появиться в будущей версии: -)

Ответ 5

Я также работаю над торговым приложением, в котором у меня есть свои локальные цели для целей сервера и сервера для моих локальных целей.

Мой процесс заключается в том, что когда мое приложение запускается, я получаю последние данные с моего сервера моего моего члена и обновляю свою локальную базу данных этими данными и когда когда-либо меняю данные в своей локальной базе данных, также обновляю на сервере сторона

также я использовал кнопку синхронизации, которая будет извлекать последние данные с сервера, если мой член команды изменяет свою цель или профиль

Ответ 6

ЕСЛИ вы хотите обновлять данные на всех устройствах, почему бы вам не использовать только удаленные базы данных, почему вы вводите для этого локальную базу данных.

В вашем случае я предлагаю вам работать только с удаленной базой данных, поэтому все может быть выполнено в реальном времени.