2013-11-02 5 views
31

Я начинаю свой первый проект PhoneGap, используя AngularJS. Это приложение, основанное на базе данных, с использованием REST API в качестве бэкэнд. Начнем с того, что я не собираюсь хранить данные локально вообще, поэтому он не будет делать многое без Интернета.Стратегии синхронизации данных с сервером в PhoneGap

Однако, в конечном итоге, я хотел бы, чтобы он хранил данные локально и синхронизировался, когда доступен Интернет, так как я знаю, что я лично отключаю интернет-соединения на своем телефоне (авиационные самолеты, разряженные батареи) или не имеет баров , Мне было интересно, можете ли вы указать мне на некоторые хорошие ресурсы для такого типа синхронизации. Некоторые рекомендуемые библиотеки? Или, возможно, некоторые дискуссии о подводных камнях и о том, как их крутить вокруг. Я немного поработал, но думаю, что сейчас я не знаю вопросов, которые нужно задать.

Кроме того, мое намерение сначала создать его в Интернете, а затем добавить синхронизацию .... Это хорошая идея, или я стреляю себе в ногу? Нужно ли мне синхронизировать его с самого начала?

У кого-то предлагалось создать приложение как локально только сначала, а только для части, доступной только для Интернета, которая имеет определенную логику. Удаленное хранилище очень важно для меня. Я знаю, что решение имеет много общего с моими задачами для приложения, но с точки зрения построения этого, с конечной целью является локальное хранилище + интернет-хранилище и двухсторонняя синхронизация, что будет проще? Или это даже имеет значение?

Для начала я собираюсь использовать UUID, а не последовательные целые первичные ключи. Я также думал о назначении каждому устройству идентификатора, который имеет префикс на любых генерируемых им ключах, но это кажется деликатным. Кто-нибудь использовал любую технику? Мысли?

Наверное, мне нужна хорошая система, чтобы рассказать, какие данные были синхронизированы. На стороне клиента, я думаю, любые записи, которые создаются/редактируются, могут быть помечены для синхронизации. Но на стороне сервера у вас несколько клиентов, поэтому это не сработает. Я предполагаю, что вы могли бы иметь last_updated timestamp и синхронизировать все обновленные синхронизации последней успешной синхронизации.

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

А как насчет хранения на стороне клиента? Я думал о SQLite или о локальном хранилище PhoneGap (http://docs.phonegap.com/en/1.2.0/phonegap_storage_storage.md.html). Рекомендации? Синхронизация будет проходить через REST API, обмениваясь JSON, поэтому я думал о том, что на самом деле хранит данные как JSON, или что-то похожее на JSON, которое легко конвертировать, было бы неплохо. С другой стороны, если мне нужно будет обменять какой-то формат данных, возможно, это то, что мне нужно хранить?

+0

Кто-нибудь использовал это? http://pouchdb.com/ Кажется, что это касается многих моих проблем, но хотелось бы услышать ваши мысли, если вы были на этом пути? – eimajenthat

ответ

26

Позвольте мне дать ответ на ваш вопрос, исходя из моего опыта, связанного с частью синхронизации, поскольку у меня недостаточно опыта работы с PhoneGap, поэтому пропустим вопрос о локальном хранилище PhoneGap v SQLite.

Мне было интересно, можете ли вы указать мне на некоторые хорошие ресурсы для такого типа синхронизации. Некоторые рекомендуемые библиотеки?

Существует множество проектов с открытым исходным кодом для синхронизации приложения PhoneGap с удаленным сервером. Но вам, вероятно, придется настраивать их для своих нужд или реализовать свои собственные функции синхронизации. Ниже перечислены некоторые из проектов с открытым исходным кодом. Вы, должно быть, уже знали о них, если бы искали сеть.

Кроме того, вы могли бы рассмотреть другие варианты, но это зависит от вашей стороне сервера:

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

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

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

Для начала я хотел бы использовать UUID, а не последовательные целые первичные ключи. Я также думал о назначении каждому устройству идентификатора, который имеет префикс на любых генерируемых им ключах, но это кажется деликатным. Кто-нибудь использовал любую технику? Мысли?

Это зависит от ваших спецификаций проекта и, в частности, от вашей серверной части. Например, мобильные сервисы Azure позволяют использовать только целые типы для первичных ключей. Хотя уникальные идентификаторы в качестве первичных ключей довольно удобны в распределенных системах (есть и некоторые недостатки).

Связано с присвоением идентификатора устройства - я не уверен, что понимаю этот вопрос, хотя я не знаю особенностей вашего проекта. Посмотрите на алгоритм синхронизации, который используется в нашей системе (bidirectional sync using REST between multiple Android clients and central SQL Server).

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

Здесь вы должны подумать о том, как справиться с разрешением конфликта в вашей системе.

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

  1. перебирать каждое модифицированное поле на стороне сервера записи в конфликте
  2. Сравнить каждое модифицированное поле записи сервера с соответствующим полем клиента.
  3. Если поле клиента не было изменено, конфликт отсутствует, поэтому просто перепишите его на серверный.
  4. Еще есть конфликт, поэтому сохраните содержимое обоих полей во временное место для отчета
  5. В конце синхронизации создайте отчет о конфликтах.
+0

Идея идентификаторов устройств будет заключаться в том, чтобы каждое устройство использовало свои собственные последовательные идентификаторы, но с префиксом уникального идентификатора устройства. Так, например, мое устройство получит идентификатор 1, а ваш получит 2. Затем вы создаете, я создаю запись с идентификатором 1, но если вы предпочитаете, это будет что-то вроде 2-1 или 2-00001. И тогда, когда я создам свою первую запись, это будет 1-1 или 1-00001. Таким образом, каждое устройство сохраняет свою собственную последовательность и создает идентификаторы по порядку, но их можно объединить, поскольку префикс их отличает. Мне не нравится это решение, хотя я не могу сказать, почему. – eimajenthat

+0

Много интересной информации @ Хаврл. Благодаря! – eimajenthat

+0

Я склоняюсь к UUID. Моя серверная сторона будет указана мной. Сначала я думал о PostgreSQL или MySQL, но, как я читал о CouchDB, это звучит убедительно. – eimajenthat

Смежные вопросы