Лучший подход для доступа к api после прерывания интервала

#android #flutter #dart

#Android #сбой #dart

Вопрос:

В настоящее время работаю над приложением домашней автоматизации, в котором есть events API, который выдает мне события, если они запускаются. Но я хочу постоянно запускать API, чтобы он отслеживал события, которые запускаются во всем приложении. И есть домашняя страница, где я показываю события, в которых когда-либо происходили. Это простой rest APInot, в котором не используются веб-сокеты, своего рода тип ответа на запрос. Любые предложения о том, как я могу реализовать это надлежащим образом. В настоящее время используется таймер на каждой странице.Но это не очень хороший подход.

Ответ №1:

Вам определенно нужно было бы использовать Timer.periodic() для периодических вызовов. Я бы посоветовал вам следовать этому подходу.

  1. Попробуйте сократить это до одного вызова API, отправив необходимые данные в том же API, чтобы вы могли уменьшить нагрузку на сеть.
  2. Создайте общий сервис для получения сведений о событии, создав родительский BLOC или provider в соответствии с вашей реализацией управления состоянием.
  3. Запускайте периодическое задание каждые 10 секунд или в зависимости от ваших требований.
  4. Не вызывайте API, пока не будет получен предыдущий ответ API. Вам нужно отслеживать это.
  5. Ответ может быть отражен в пользовательском интерфейсе после успешного ответа на всех страницах с использованием общего потребителя BLOC or Provider , таким образом, код будет модульным, и вы избежите дублирования кода.
  6. Не забудьте удалить объект timer.

Комментарии:

1. Просто хочу спросить, например, у меня есть API, который возвращает список произошедших событий, но API по умолчанию ожидает 60 секунд, и если между ними произойдет событие, оно извлечет данные. Итак, мой вопрос таков: если я установлю таймер на 60 секунд, а затем он впервые попадет в API, тогда он будет ждать 60 секунд, а затем позже попадет в API после этого. Покупайте, если событие запускается между этим интервалом в 60 секунд. Я бы не получил событие. Любые предложения по этому поводу.

2. Теперь это сбивает с толку. Ваш сервер обращается к другому серверу? Почему время ожидания составляет 60 секунд? Можете ли вы немного объяснить свой API?

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

4. Я не уверен, как вы реализовали это в BE, но это не похоже на асинхронный вызов API. Вы просто не можете поддерживать соединение в течение 60 секунд для вызова синхронизации. Это очень плохая производительность для конечной точки API. При текущей архитектуре (может потребоваться дополнительная информация) вы, вероятно, рассмотрите альтернативу, просто запустив запрос и вернув ответ об успешном завершении после некоторой проверки, и перейдя к другому API через 60 секунд, чтобы получить результат, который должен быть где-то сохранен по предыдущему запросу. Здесь можно использовать какой-нибудь механизм кэширования.

5. Мне нужно больше информации о реализации BE API, чтобы обеспечить более эффективную реализацию вызова.