Синхронизируйте автономные основные данные с сервером, когда приложение имеет подключение к Интернету.

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

Сейчас я работаю с Core Data и AFNetworking 2.0, но работаю онлайн. Итак, онлайн-алгоритм следующий:

  1. Создать запрос
  2. Проверьте интернет-соединение
  3. Дождитесь ответа
  4. Создать объект (запись в БД) на основе ответа JSON

Но офлайн-алгоритм немного отличается:

  1. Создать запрос
  2. Проверьте интернет-соединение
  3. Создать прокси-объект (запись в БД)
  4. Слушайте интернет-соединение
  5. Синхронизируйте временные данные с сервером.

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

Мой вопрос: есть ли уже готовое решение, как синхронизировать автономные данные с сервером?

Или, может быть, у вас есть лучший алгоритм, я тоже в порядке)


person Matrosov Alexander    schedule 11.03.2014    source источник


Ответы (1)


Я бы предложил следующий порядок действий:

  1. Реализуйте «менеджер запросов», внутри которого есть контекст «частной очереди».
  2. Когда какому-то модулю нужно выдать запрос, он делает это с помощью менеджера
  3. когда нужен запрос, менеджер ВСЕГДА записывает его в магазин (используя его контекст) с отметкой времени создания
  4. The manager will also listen to online/offline status changes
    1. When online status is detected, the managed query the store for pending requests and issue them one by one to the server
    2. когда требуется новый запрос, менеджер будет действовать, как описано в (4.1), чтобы предотвратить голодание запроса
    3. Вы можете использовать флаг, указывающий, работает ли менеджер в данный момент (обрабатывает запросы), чтобы новый вставленный запрос не вызывал немедленной выборки из хранилища.
    4. запросы, отправленные на сервер, могут иметь свой собственный контекст для записи в хранилище, чтобы они не мешали работе менеджера.
    5. При обнаружении статуса «офлайн» менеджер может отменить все активные запросы (они будут выполнены при следующем обнаружении статуса онлайн).
    6. Когда запрос завершен (зафиксирован на сервере и в локальном хранилище), он удаляется из хранилища.

Перед активацией менеджера вы можете запросить в магазине ожидающие запросы и отменить/удалить те, которые больше не актуальны.

person Dan Shelly    schedule 11.03.2014
comment
спасибо, очень хорошие шаги. Я думаю, что это идеально! ) еще один вопрос это ID. Таким образом, у каждого объекта есть идентификатор, который прямо сейчас создается на стороне сервера. Поэтому я думаю, что будет нормально иметь какой-то offlineID, который я создаю для своего объекта без подключения, а затем, когда запрос будет успешным, мне нужно найти этот объект и переписать его свойства. я прав? - person Matrosov Alexander; 12.03.2014
comment
Когда объекты создаются локально, вы должны предоставить им временный идентификатор. когда запрос на создание элемента передается серверу. Вы должны надеяться, что ответ сервера будет содержать постоянный идентификатор нового объекта, иначе вам придется каким-то образом получить этот идентификатор. в худшем случае (когда сервер не разрешает такие ответы) вы можете удалить локальный объект после успешного создания сервера и позволить серверу уведомить вас о вновь созданном объекте... - person Dan Shelly; 12.03.2014
comment
Можете ли вы предоставить краткое описание менеджера запросов или какую-нибудь демонстрацию? - person Darshan Mothreja; 03.03.2016
comment
Когда я погуглил, я узнал о каком-то новом способе автономного запроса к серверу с использованием AFHTTPSessionManager вместо AFHTTPRequestOperationManager, поэтому, что мне теперь делать, я немного запутался. - person Darshan Mothreja; 03.03.2016