Обработка синхронизации данных между Android-сервисом и сервером через REST API

Question

Я пытаюсь спроектировать, как лучше всего обрабатывать синхронизацию данных между приложением Android и удаленным сервером через API REST.

Сейчас это все еще ранняя стадия, но мой сервер отдыха в основном работает (в любом случае, достаточно для тестирования).

У меня есть 3 таблицы для синхронизации (связаны, как показано ниже).

ПОКАЗАТЬ> ----- СЕЗОН> ----- ЭПИЗОД

И сервер, и устройство имеют одинаковую версию этих таблиц, и мне нужно синхронизировать их ОТ устройства к СЕРВЕРУ (на данный момент и в конечном итоге 2 способа). Синхронизация будет осуществляться через службу Android, выполняющую асинхронные вызовы API REST (вставка / обновление и удаление) в фоновом режиме.

Теперь моя главная проблема заключается в логике, которая обеспечит обновление обеих сторон соответственно.

вставка / обновление с устройства на сервер будет выполняться с помощью запроса POST, поэтому я подумал о наличии флага состояния для всех трех таблиц, который заполняется с помощью ON INSERT / ON UPDATE TRIGGERS (SQlite), позволяющего службе синхронизации обрабатывать строки что нужно на сервер зайти. Это правильный подход?

Это будет выглядеть примерно так:

CREATE TRIGGER sync_update_show AFTER UPDATE ON show
BEGIN
    UPDATE show SET sync_flag = 'TO_SYNC' WHERE _id = new._id
END

Теперь для удаления, поскольку служба независима от основного приложения, я использовал BEFORE DELETE SQlite TRIGGERS для заполнения таблицы «TODELETE», которую служба может просматривать и инициировать вызовы api delete на сервер. Это правильный подход?

Это будет выглядеть примерно так:

CREATE TRIGGER sync_delete_show BEFORE DELETE ON show
BEGIN
    INSERT INTO todelete_show
    SELECT * FROM show WHERE _id = old._id
END

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

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

Answer 1

Ваш подход к управлению журналом изменений с использованием триггеров базы данных определенно сработает.Если вам нужен более объектно-ориентированный подход, вы можете представить API-интерфейс CRUD для своего бизнес-объекта, а затем в API-интерфейсе обновить таблицу журнала изменений с помощью маркеров обновления / вставки / удаления и не использовать триггеры базы данных.

В случае, если вызаинтересован в использовании Sync Framework. Я хотел бы обратить ваше внимание на службу синхронизации OpenMobster.

Вы можете выполнять следующие операции синхронизации

• двусторонняя
• одна-way клиент
• одностороннее устройство
• bootup

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

Он также поддерживает синхронизацию между несколькими устройствами, как это делает iCloud.

В облаке вы простонаписать Java-канал, который является CRUD-интерфейсом для ваших данных, и открыть канал для Sync Engine.На стороне устройства эти данные затем доступны через API синхронизации на основе CRUD.Все остальные детали синхронизации, такие как управление журналом изменений, управление конфликтами, репликация на несколько устройств и т. Д., Автоматически обрабатываются модулем синхронизации.

В вашем случае

, ChangeLog автоматически управляется и интегрируется сСинхронизаторОн использует объектно-ориентированный подход, о котором я упоминал, и синхронизация обрабатывается через CRUD API Sync на основе.

Вот ссылка на проект с открытым исходным кодом: http://openmobster.googlecode.com

Вот учебник для пониманиянекоторые из его работ: http://code.google.com/p/openmobster/wiki/AndroidSyncApp

Answer 2

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

Я настоятельно рекомендую вам реализовать ContentProvider для хранения ваших таблиц, поскольку вам будет проще использовать множество API-интерфейсов Android в вашихдействия / фрагменты, особенно CursorLoaders и CursorAdapters.

Взгляните на contentProviders: http://developer.android.com/guide/topics/providers/content-provider-creating.html

А также посмотрите на SyncAdapter: http://developer.android.com/reference/android/content/AbstractThreadedSyncAdapter.html

Также проверьтеЭтот разговор о создании успокаивающих приложений на Android, немного устарел, но я думаю, что он все еще очень актуален http://www.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html