Дизайн для синхронизации данных в Android


23

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

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

Что из вышеперечисленного вы бы порекомендовали иметь в своем приложении и почему?

Ответы:


12

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

В основном, если вам требуется передача в реальном времени, используйте IntentService (первый вариант), иначе SyncAdapter. Я предпочитаю IntentService, хотя, потому что он чувствует себя более настраиваемым, но более тривиальным подходом будет использование SyncAdapter.


18

Это сильно зависит от того, какой тип синхронизации вам нужен.

периодический

Если ваше приложение является новостным приложением, которое публикует сообщения в определенное время каждый день (скажем, в 7:45 каждый день), то вы выполняете периодическое задание в фоновом режиме, скажем, в 8:00.

например : Drippler. Они уведомляют меня один раз каждый день (около 18:30). Я считаю, что они используют периодическое задание.

Событие вызвано

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

например : DropBox / Evernote. Они синхронизируются, когда я взаимодействую с приложением.

моментальный

Если ваше приложение запускает мгновенные сообщения / почту / непериодические важные обновления, вам нужны push-уведомления, потому что вы хотите немедленно предупредить пользователя. Используйте GCM или Parse для этого случая. Например: WhatsApp / Google чат. Поскольку вы прямо упомянули, что не хотите использовать GCM, я расскажу, почему вы должны использовать стандартный поставщик push-уведомлений вместо того, чтобы писать свой собственный:

Push-уведомления работают мгновенно - задержка очень мала (порядка секунд, редко минут). Если бы вы реализовали свое собственное решение / библиотеку для этого - в наивной модели вы бы пинговали сервер каждую секунду, или 5 секунд, или минуту, чтобы проверить состояние. Это очень неэффективно, так как потребляет процессор (и, следовательно, батарею), пропускную способность мобильного телефона и нагрузку на ваш сервер. Однако в GCM / Parse они всегда оставляют порт открытым для сервера (см. Здесь ). Это стандартный и самый эффективный способ. Кроме того, если 10 приложений используют GCM, вам не нужно 10 открытых подключений, вам нужно только одно для каждого устройства. И вы действительно не хотите разрабатывать свое собственное решение, если у вас нет уважительной причины / средств / времени для этого.

Примечание по адаптеру синхронизации : адаптер синхронизации хорошо работает во всех трех вышеупомянутых случаях. Установите флажок Запуск адаптера синхронизации, и вы увидите, что это зависит либо от GCM, либо от вашего собственного механизма (триггер события или пользовательское решение), либо от доступности сети (триггер события), либо от периодического события. В общем, это хороший удобный класс для синхронизации данных без необходимости каждый раз выполнять длинный список инициализаций или реализовывать все вышеописанные случаи в одном месте.


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

@AkashRamani Я не вижу причины, по которой вам не следует использовать GCM / Parse для этого случая. Тем не менее, GCM является бесплатным, в то время как Parse выставляет вам счет за определенный период. Если ваши обновления находятся в пределах 4096 байт, вы можете отправить обновление напрямую. Если ваши оценки обновляются очень часто, то вместо GCM может быть полезен опрос (скажем, для оценки по крикету). Я бы посоветовал протестировать / профилировать как опрос, так и GCM на время ожидания и потребление ресурсов процессора / батареи.
Sundeep

AWS также имеет решение для уведомлений, которое является кросс-платформенным и кросс-рыночным. См .: docs.aws.amazon.com/sns/latest/dg/SNSMobilePush.html
Брилл Паппин,

3

Есть один аспект SyncAdapter, который не был упомянут другими ответами.

SyncAdapterМодель требует , чтобы у вас есть конкретный ContentProvider орган , который вы синхронизировать и тип конкретной учетной записи (см Authenticator ) , который собирается быть синхронизирован. Поэтому, если у вас уже нет этих компонентов в вашей архитектуре (например, потому что вы предоставляете другим приложениям доступ к вашим данным или вам требуется поддержка учетных записей), это SyncAdapterприведет к значительным накладным расходам на реализацию.


2

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

Это также выглядит так, если вы посмотрите руководство по настройке Android: создание адаптера синхронизации

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


2

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

Для мгновенных задач мы можем использовать,

AsyncTask для задачи, которая является короткой, может составлять 3-4 секунды.

IntentService для длительных задач.


Отличная разбивка для выбора большого пальца.
Брилл Паппин

0

Поскольку мы говорим о дизайне, мы должны упомянуть управление SyncAdapters, объект SyncResult и то, что происходит после.

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

Один из подходов, который я сейчас использую, состоит в том, чтобы полностью отказаться от объекта SyncResult и просто использовать сервис для регистрации результатов каждой отдельной «Синхронизации».

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.