Ответ 1
Позвольте мне дать ответ на ваш вопрос на основе моего опыта, связанного с частью синхронизации, поскольку у меня нет достаточного опыта работы с PhoneGap, поэтому пропустим вопрос о локальном хранилище PhoneGap v SQLite.
Мне было интересно, можете ли вы указать мне на некоторые хорошие ресурсы для такого типа синхронизации. Некоторые рекомендуемые библиотеки?
Существует ряд проектов с открытым исходным кодом для синхронизации приложения PhoneGap с удаленным сервером. Но вам, вероятно, придется настраивать их для своих нужд или реализовать свои собственные функции синхронизации. Ниже перечислены некоторые из проектов с открытым исходным кодом. Вы должны знать о них, если вы ищете сеть.
- плагин синхронизации по телефону
- Простая синхронизация автономных данных для мобильных приложений Web и PhoneGap
- Синхронизировать локальный WebSQL Db с сервером
- Плагин Couchbase Lite PhoneGap
Кроме того, вы можете рассмотреть другие параметры, но это зависит от вашей серверной части:
- Microsoft Sync Framework Toolkit (доступен образец Html5)
- OpenSync Framework - независимый от платформы, механизм синхронизации общего назначения.
Кроме того, мое намерение сначала создать интернет-зависимость, а затем добавить синхронизацию... Это хорошая идея, или я стреляю себе в ногу? Нужно ли мне синхронизировать его с самого начала?
Я считаю, что функция синхронизации больше похожа на дополнительный модуль и не должна быть тесно связана с остальной частью вашей бизнес-логики. После того, как вы начнете думать о стратегии тестирования своей синхронизации, вы поймете, что будет легче протестировать это, если ваше средство синхронизации отключено от основного кода.
Я думаю, вы можете как можно скорее запустить приложение с минимально необходимой функциональностью без синхронизации. Но лучше подумать о своей архитектуре и о том, как вы добавляете средство синхронизации заранее.
Для начала я подумываю использовать UUID, а не последовательные целые первичные ключи. Я также думал о назначении каждому устройству идентификатора, который имеет префикс на любых генерируемых им ключах, но это кажется деликатным. Кто-нибудь использовал любую технику? Мысли?
Это зависит от ваших спецификаций проекта и, в частности, от вашей серверной части. Например, мобильные сервисы Azure позволяют использовать только целые типы для первичных ключей. Хотя уникальные идентификаторы в качестве первичных ключей довольно удобны в распределенных системах (есть и некоторые недостатки).
Связано с назначением идентификатора устройства - я не уверен, что понимаю этот вопрос, хотя я не знаю особенностей вашего проекта. Посмотрите на алгоритм синхронизации, который используется в нашей системе (двунаправленная синхронизация с использованием REST между несколькими клиентами Android и центральным SQL Server).
Как насчет записей, отредактированных в нескольких местах? Если два клиента редактируют, а затем хотят синхронизировать, у вас есть некоторая двусмысленность в отношении слияния, например, при объединении ветвей в git или других системах управления версиями. Как вы справляетесь с этим? Я предполагаю, что git делает это, сохраняя разности каждого коммита. Думаю, вы могли бы хранить отличия? Чем больше я думаю об этом, тем сложнее это звучит. Я передумал это или не думал об этом?
Здесь вам нужно подумать о том, как обрабатывать разрешение конфликтов в вашей системе.
Если вероятность конфликтов в вашей системе будет высокой, например, пользователи будут часто менять одни и те же записи. Затем youd лучше отслеживать, какие поля (столбцы) записей были изменены в вашей синхронизации, а затем после обнаружения конфликта:
- Итерации через каждое измененное поле записи на стороне сервера в конфликте
- Сравните каждое измененное поле записи сервера с соответствующим полем клиента.
- Если поле клиента не было изменено, конфликт отсутствует, поэтому просто перепишите его на серверный.
- Иначе возникает конфликт, поэтому сохраните содержимое обоих полей во временное место для отчета
- В конце синхронизации создайте отчет о конфликтах.