Up-Sync и Down-Sync в Android?

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

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

СЕЙЧАС

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

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

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

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

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

Кроме того, вы должны решить, как часто вы хотите запускать эту СЛУЖБУ.

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

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

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

• когда это устройство было LAST_SYNCHED
• затем он сравнит его с TODAYS DATE
• и проверит какие упадеты на самом деле произошли между этими датами и отправит изменения на ЛОКАЛЬНОЕ (устройство)

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

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

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

ИЗМЕНИТЬ

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

Если вы хотите, чтобы ваши устройства получали уведомления с сервера о синхронизации, а не периодически обращались к ВЕБ-СЛУЖБЕ..

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

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

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

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

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

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

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

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

Обновлено:

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

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

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

Примечание: никакого отношения к этой компании.

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

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

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

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

Пока выше описан поток данных.

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

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

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

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

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

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

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