Проблема совместного использования данных клиент-сервером - PullRequest
0 голосов
/ 25 сентября 2011

У меня есть веб-сервис с мобильным приложением. Пользователь с приложением совместно использует данные на сервере - имеет ограничение в БД, что имя общего объекта уникально для каждого пользователя. Кроме того, приложение хранит локально все созданные данные (пользователем - это тоже общий доступ).

У меня есть следующий сценарий:

  1. Пользователь создает данные с именем-именем X.
  2. Пользователь делится этими данными.
  3. Сервер имеет в этом БД data-name X для этого пользователя
  4. У пользователя новый телефон и установите приложение.
  5. НЕТ ИНТЕРНЕТ-СВЯЗИ
  6. пользователь снова создает данные с именем-именем X.
  7. он хранится только локально - поскольку нет подключения к Интернету.
  8. Интернет-соединение восстановлено.
  9. Теперь служба BG запускается и начинает делиться всеми вашими общими данными - в BG.
  10. Проблема обнаружена из-за ограничения.

Что нужно сделать, чтобы решить проблему? Я могу открыть новое окно с сообщением о том, что оно уже доступно, и попросить пользователя переименовать / перезаписать его, дать возможность D / L эти данные в свою локальную БД и т. Д. Но так как это сделано в BG - это удобно для пользователя? показать это всплывающее окно?

Есть еще идеи?

Вероятно, есть общий способ сделать это.

Я действительно могу использовать некоторую помощь для решения этой проблемы.

Ответы [ 2 ]

0 голосов
/ 25 сентября 2011

Вот как недавнее приложение, которое я сделал, обрабатывает это:

  1. Пользователь создает новую запись на мобильном устройстве. Новой записи присваивается отрицательный первичный ключ _id номер.
  2. Приложение проверяет подключение к Интернету и, если подключение существует, приложение отправляет HTTP-сообщение на сервер, создавая запись на стороне сервера. Затем сервер отправляет ответ, создавая новый PK _id, который обновляется в приложении.
  3. Если нет подключения к Интернету, приложение создает в моей таблице db_changes запись, содержащую имя таблицы и PK _id новой записи.
  4. Служба запускается с шагом 5 минут, которая получает обновления от сервера и отправляет новые данные на сервер. Таблица db_changes опрашивается каждый раз для любых существующих вставок или обновлений, которые еще предстоит опубликовать на сервере.
  5. При успешном завершении запись из таблицы db_changes удаляется.

В моей ситуации это работает отлично.

0 голосов
/ 25 сентября 2011

для этого вы обычно не используете имя или что-то в этом роде, а UUID - то есть случайные строки длиной от 32 до 64 символов, которые однозначно идентифицируют объект.Когда вы создаете объект, просто создайте UUID на устройстве и синхронизируйте его с сервером.Вот документация класса UUID в android.

Хотя теоретически возможно иметь одинаковые UUID, это то, о чем вы обычно не слишком беспокоитесь, как указано здесь: http://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates

Для iOS вы можете использовать класс CFUUID для генерации UUID

Другое имя для UUID - это GUID, уникальные идентификаторы Globaly.Следовательно, вы удаляете любые ограничения уникальности.

...