Нажмите против опроса, когда большая задержка (часы) является приемлемым

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

Все крупные мобильные магазины предоставляют свою версию службы push-уведомлений:

• Служба Apple Push Notification
• Google Cloud Messaging для Android
• Служба push-уведомлений Microsoft

Однако мне интересно, насколько это предположение верно. Я имею в виду, что если у меня есть приложение, которое опрашивает удаленный сервер только пару раз в день и на которое «уведомления» не нужно доставлять мгновенно (допустима большая задержка), тогда это будет хорошим решением опросить данные вместо того, чтобы толкать его?

Заранее спасибо!

Опрос всегда приемлем, когда в реальном времени нет необходимости. Вы должны спросить себя, почему вы используете один вместо другого?

Цель услуги push - пара вещей; для вас может быть значительно меньше трафика, если ваши пуски являются широковещательными, а сторонний провайдер выполняет широковещательную рассылку - это позволяет вам отправлять одно сообщение и получать его тысячи. Но, как вы заметили, самым большим преимуществом push-сервисов является характер в реальном времени, который позволяет немедленно получать обновления для ваших потребителей. Однако при выполнении push-уведомлений вы действительно никогда не захотите отправлять большие наборы данных, если вещаете, и вы также зависите от сторонней push-службы, которую вы используете (если используете).

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

Таким образом, из этого видно, что если у вас есть проблемы с сетевым трафиком или обслуживанием службы (что означает, возможно, аутентификацию / авторизацию запросов, запись их в журнал, занимающую дисковое пространство, все обычные требования для обслуживания службы), то вы не ' Не хочу заставлять клиентов опрашивать. Однако, если в случае использования требуется передача особенно большого набора данных, или вы не можете быть привязаны к API стороннего производителя, который может изменяться во времени, а также к их SLA или платам, тогда может применяться домашняя система опросов, хотя обслуживание накладных расходов может быть значительно больше. В качестве альтернативы вы, возможно, уже работаете с сервисом и сохраняете данные так, что опрос является легким дополнением к уже имеющейся инфраструктуре, что делает опрос более желательным.

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

Голосование должно быть хорошо в вашем случае. И вам не придется интегрироваться с еще одной системой (или несколькими системами для нескольких платформ).

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

Конечно. Это также проще (просто остерегайтесь пиковых нагрузок, если все тянут по одному и тому же графику).

Тем не менее, я бы оспорил предположение, что «большая задержка приемлема», учитывая ожидания мобильных пользователей. («Карты не обновляются в режиме реального времени! Недопустимо!» Или - «Я знаю, что это служба погоды, но я буду продолжать нажимать эту кнопку обновления каждые пять секунд, пока прогноз на завтра не станет солнечным!»)