Подтвердить что ты не робот

Периодическая резервная копия базы данных SQLite для iCloud

Позвольте мне убрать это в сторону прямо сейчас: да, было почти наверняка ошибкой не использовать Core Data. Тем не менее, я был новичком в развитии iOS, когда принимал эти решения, и я понятия не имел, что буду так проворствовать. Кроме того, приложение предназначено также для запуска на Android (в конечном итоге), поэтому, когда это возможно, я избегал API-интерфейсов платформы.

У меня есть приложение iOS, которое хранит данные в локальном файле базы данных SQLite. Данные, хранящиеся в файле, предоставляются пользователем, поэтому важно сохранять его в безопасности. У меня были планы "сделать это позже", а позже сейчас. Я быстро прихожу к осознанию того, что это будет не так просто, как я надеялся...

Теперь я понимаю, что невозможно будет легко синхронизировать данные между устройствами, и я готов принять это ограничение до тех пор, пока не смогу перейти на Core Data. Тем не менее, в то же время мне бы хотелось как минимум резервировать базу данных SQLite, чтобы пользователи могли чувствовать себя в безопасности с помощью приложения на одном устройстве. Я думал, что сделаю это:

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

Самая большая проблема с этим подходом заключается в том, что пользователь может запускать приложение на нескольких устройствах, поэтому данные, хранящиеся в iCloud, могут быть с любого из этих устройств, но только с одним. Чтобы бороться с этим, я подумал, что могу просто использовать уникальное имя для каждого устройства в облачном хранилище. Я бы сгенерировал это с помощью UIDevice.identifierForVendor.

Итак, моя логика запуска:

  • Определите уникальное имя для облачного файла.
  • Локальный файл отсутствует или поврежден, и если да, существует ли файл облаков?

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

    2,2. Если они скажут "да", скопируйте файл облака в локальное хранилище файлов.

  • Откройте файл локальной базы данных.

И работая в фоновом режиме, я иногда копировал файл базы данных из локального в облачное хранилище.

Я хотел бы знать, является ли это разумным подходом до тех пор, пока я не интегрирую Core Data. Кроме того, есть ли скрытые "gotchas", которых я, возможно, не хватает?

UPDATE:, как отметил @TomHarrington в комментарии, выясняется, что мой файл базы данных уже сидит в /Documents, который поддерживается в iTunes и любой учетной записи iCloud. Итак, мой вопрос превращается в это:

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

4b9b3361

Ответ 1

Я собираюсь ответить на мой вопрос, так как я закончил этот путь и нашел MASSIVE-блокатор. В API UIDevice.identifierForVendor есть ошибка, которая заставляет его восстанавливать каждый раз, когда установлена ​​новая версия приложения! См. здесь. Это, конечно, исключает использование его в качестве идентификатора устройства. Вздох

Я думаю, что я СОЛ с этим подходом. Вместо этого я могу сгенерировать GUID при первом выполнении и использовать его как свой идентификатор. Проблема в том, что мне нужно сохранить это где-то, что не подкреплено iCloud.

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

UPDATE. Я закончил создание идентификатора при первом запуске и сохранил его в цепочке ключей (в качестве локальной записи, так что она не была скопирована в iCloud).