Стратегии Синхронизации Данных Между Приложением для направляющих и приложением для iPhone
Я записал много приложений для iPhone, которые вытянули данные из веб-сервисов, и я работал над синхронизирующимися данными между приложением для iPhone и веб-приложением, но я всегда чувствовал, что существует, вероятно, лучший способ обработать синхронизацию.
Я хотел бы знать, какие стратегии Вы раньше синхронизировали данные между Вашим iPhone (чтение: мобильный) Приложения и Ваши направляющие (чтение: сеть) Приложения.
- Есть ли какие-либо стратегии тот масштаб особенно хорошо?
- Как Вы имели дело с большими объемами данных? (Вы используете разбитые на страницы ответы?)
- Как Вы удостоверяетесь, что данные не перезаписываются?
- Существует ли причина избежать Ruby on Rails?
- если так, можно ли предложить альтернативу? Что лучше об альтернативе?
- Что привели к сбою стратегии?
- Почему Вы полагаете, что те стратегии перестали работать?
Я хотел бы смочь сохранить все модификации данных на сервере, но конкретное приложение, которое я собираюсь запустить, продолжает работать, будет нуждаться в способности работать, в то время как отключено от сети.
Пользователь сможет обновить данные по мобильному устройству и данные обновления через веб-приложение.
Когда подключения мобильного устройства пользователя к серверу любые локальные изменения будут продвинуты к серверу.
2 ответа
Это не ответ на весь ваш вопрос, но кое-что, что я начал делать, что помогает с точки зрения мобильных устройств, - это создание прослойки между логикой, которая отправляет данные синхронизации сервера, и самим веб-сервером.
Я создал объект данных, который является просто общим объектом синхронизации, в котором я храню уникальный ID, полезную нагрузку и дату последней попытки доставки. У меня есть еще одна часть логики, которая получает объекты Sync из данных ядра и отправляет их. Если получен хороший ответ (т.е. ответ действительно пришел и текст ответа соответствует тому, что я ожидал), этот объект Sync удаляется. Это помогает убедиться, что данные синхронизации доходят до места назначения правильно и не просто теряются в море. Это также хорошая модель для работы в автономном режиме. Вы можете просто хранить свои объекты синхронизации в автономном режиме и начать отправлять их по порядку, как только вернетесь в сеть".
С точки зрения веб, Rails Metal звучит так, как будто он может подойти для подобной ситуации. Я никогда не использовал его сам, но, основываясь на некоторых прочитанных материалах, похоже, что Metal предназначен для ситуаций, когда возможен большой трафик и критична быстрая реакция. По сути, он избавляет от накладных расходов на маршрутизатор Rails и тому подобное. Надеюсь, это поможет.
Если вы используете rails, вы можете взглянуть на мой плагин plistifier, который я только что написал: http://github.com/jeena/plistifier