Базовая облачная синхронизация Данных - нуждается в помощи с логикой

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

Сторона сервера

Поставщик услуг по хранению данных

Как со всеми облачными синхронизирующими системами, устройство хранения данных является главной частью загадки. Существует много способов обработать это. Я мог настроить свой собственный сервер для устройства хранения данных или использовать сервис как Amazon S3, но потому что я начинаю с капиталом за 0$, в данный момент, заплаченным решением для устройства хранения данных не является жизнеспособный вариант. После некоторого размышления я решил обосноваться с Dropbox (уже хорошо установленное облачное синхронизирующее приложение и поставщик услуг по хранению данных). Профессионалы использования Dropbox:

• Это свободно (для ограниченной суммы пространства)
• В дополнение к тому, чтобы быть сервисом устройства хранения данных это также обрабатывает облачную синхронизацию
• Они недавно выпустили Objective C SDK, который делает намного легче взаимодействовать через интерфейс с ним в Mac и приложениях для iPhone

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

Структура устройства хранения данных

Это - действительно трудная часть для выяснения, таким образом, я должен так очень ввести, как я могу здесь. Я думал о структуре как это:

CloudSyncFramework
======> [app name]
==========> devices
=============> (device id)
================> deviceinfo
================> changeset
==========> entities
=============> (entity name)
================> (object id)

Быстрое объяснение этой структуры:

• Основной "CloudSyncFramework" (называют нерешенными) папка будет содержать отдельные папки для каждого приложения, которое использует платформу
• Каждая папка приложения содержит папку устройств и папку объектов
• Папка устройств будет содержать папку для каждого устройства, которое регистрируется в учетной записи. Папку устройства назовут согласно идентификатору устройства, получил использование чего-то как [[UIDevice currentDevice] uniqueIdentifier] (на iOS) или порядковый номер (на Mac OS).
• Каждая папка устройства содержит два файла: deviceinfo и changeset. deviceinfo содержат информацию об устройстве (например, версия ОС, последняя синхронизирующая дата, модель, и т.д.), и changeset файл содержит информацию об объектах, которые изменились начиная с устройства, в последний раз синхронизируемого. Оба файла просто будут простым NSDictionaries, заархивированным в использование файлов NSKeyedArchiver.
• Каждый Базовый объект Данных имеет подпапку под папкой объектов
• Под каждой папкой объекта каждый объект, который принадлежит тому объекту, будет иметь отдельный файл. Этот файл будет содержать словарь JSON с парами "ключ-значение".

Одновременная синхронизация

Это - одна из областей, где я почти абсолютно невежествен. Как я обработал бы 2 соединения устройств и синхронизацию с облаком одновременно? Кажется, существует высокий риск вещей, выходящих из синхронизации здесь или даже повреждения данных.

Обработка миграций

Еще раз, другая невежественная область здесь. Как я обработал бы миграции Базовой модели управляемого объекта Данных? Самая легкая вещь сделать здесь, кажется, только для стирания облачного хранилища данных, чистят и загружают новую копию данных из устройства, которое подверглось процессу миграции, но это кажется несколько опасным, и может быть лучший путь.

Сторона клиента

Преобразование NSManagedObjects в JSON

Преобразование атрибутов в JSON не является очень трудной задачей (тройки много кода для него плавающий вокруг сети). Отношения являются ключевой проблемой здесь. В этом сообщении stackoverflow Marcus Zarra отправляет код, в котором сами объекты связей добавляются к словарю JSON. Однако он упоминает, что это может вызвать бесконечный цикл в зависимости от структуры модели, и я не уверен, работало ли это с моим методом, потому что я храню каждый объект как отдельный файл.

Я пытался найти способ получить идентификатор как строку для NSManagedObject. Затем я мог сохранить отношения в JSON как массив идентификаторов. Самая близкая вещь, которую я нашел, была [[managedObject objectID] URIRepresentation], но это не действительно идентификатор для объекта, его больше местоположения для объекта в персистентном хранилище, и я не знаю если его достаточно бетон использовать в качестве ссылки для объекта.

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

Синхронизация изменений в облаке

Первое (и все еще лучше всего) решение, которое появилось в мою голову для этого, должно было прислушаться NSManagedObjectContextObjectsDidChangeNotification для получения списка измененных объектов затем обновите/удалите/вставьте те объекты в облачном хранилище данных. После того, как изменения были сохранены, я должен буду обновить changeset файл для любого зарегистрированного устройства для отражения недавно измененных объектов.

Одна проблема, которая подходит здесь, как я обработал бы неудавшуюся или прерванную синхронизацию?. Одна идея, которую я имею, состоит в том, чтобы сначала продвинуть изменения во временном каталоге на облаке, затем после того как это было подтверждено как успешное, для слияния его с основными данными на облаке так, чтобы прерывание посреди синхронизации не повреждало данные. Затем я сохранил бы записи объектов, которые должны быть обновлены в облаке в plist файл или что-то, чтобы быть продвинутыми в течение следующего раза, когда приложение подключено к Интернету.

Получение измененных объектов

Это довольно просто, устройство загружает свой changeset файл, выясняет, какие объекты должны быть обновлены/вставлены/удалены, затем действуют соответственно.

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

ОБНОВЛЕНИЕ

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

Самое большое изменение, которое я продумал, состоит в том, чтобы заставить каждое устройство иметь отдельное хранилище данных в облаке. В основном каждый раз контекст управляемого объекта сохраняет (благодарит TechZen), он загрузит изменения в хранилище данных того устройства. После того, как те изменения обновляются, это создаст "changeset" файл с деталями изменения и сохранит его в changeset папки ДРУГИХ устройств, которые используют приложение. Когда другие устройства соединятся с синхронизацией, они пройдут changeset папку и применят каждый changeset к локальному хранилищу данных, затем обновят их соответствующие хранилища данных в облаке также.

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

Существуют некоторые очевидные конфликтные ситуации для контакта с, главным образом относительно удаления объектов. Если changeset загружает то, чтобы давать команду приложению удалить объект, который в настоящее время редактируется, и т.д. должны быть способы иметь дело с этим.