Логика обновления сетевых запросов с помощью Диспетчера работ

У меня есть приложение, которое извлекает данные из API. В общем, прямо сейчас приложение работает как таковое:

  • При подключении к Интернету извлеките данные и используйте Android Room для хранения данных в автономном режиме.
  • Если нет подключения к Интернету, проверьте, существуют ли данные в комнате. Если существует, отобразите его. Если его нет, отобразите сообщение об ошибке.

Я провел небольшое исследование в Интернете о том, как реализовать эффективную политику автономного хранения, и Google предлагает использовать Work Manager для постановки запросов в очередь, а затем отправки их при подключении.

Я действительно хочу знать, как это реализовать? (не код, а логика, то есть должен ли я планировать запросы к API каждый день или каждый раз, когда он подключается к Интернету?)

Было бы здорово, если бы кто-то с опытом работы с офлайн-приложениями мог помочь.

Мои сетевые запросы выполняются через Retrofit, и я уже создаю класс, который выполняет вызовы API.


person Mervin Hemaraju    schedule 23.02.2021    source источник
comment
Планирование один раз в день будет удобным для данных за счет использования всех ограничений. В моем приложении повторяющаяся работа происходит один раз в день, когда пользователь - ›подключен к Wi-Fi, в настоящее время не пользуется мобильным телефоном, подключен аккумулятор и т. Д. Запросы планирования каждый раз, когда пользователь подключается к Интернету, разряжает батарею, что явно не является хорошей практикой.   -  person Rajasekhar    schedule 23.02.2021


Ответы (1)


Имейте в виду, что WM (диспетчер работ) предназначен для выполнения операций при соблюдении определенных условий (например: у пользователя достаточно батареи, дисплей выключен и т. Д.). Таким образом, это может привести к тому, что ваши данные не будут обновляться, когда вам это нужно. WM хорош для операций, которые вы хотите выполнить, но не являются критичными для выполнения прямо сейчас. Я бы сказал, что всегда используйте Room DB как единственный источник истины. Если данные в комнате, покажите их, если нет, принесите, если не можете, ну, вы пробовали. Отправьте сообщение пользователю. Вы можете использовать NetworkConnectivityListener для мониторинга подключения и проверки наличия ожидающего запроса (вы можете сохранить параметры этого запроса в своей базе данных Room в другой таблице для простоты использования). Таким образом, вы должны запросить БД, получить ожидающие запросы (если есть) и выполнить их, обновить данные и позволить ViewModel / Repository решить, есть ли контекст для отображения этих данных (UI).

Я чувствую, что вы очень близки к достижению того, что вам нужно.

Другими словами:

UI: наблюдает за своим viewModel для некоторого sealed class xxx состояния, чтобы сообщить ему, что делать (показать пустой список, показать ошибку, передать данные адаптеру recyclerview и т. Д.).

ViewModel: использование viewModelScope.launch { ... } вызовет repository.fetch(...) или аналогичный. Ваш viewModel будет извлекать эти данные, когда фрагмент сообщает ему об этом (например, пользователь нажал кнопку) или при каком-либо событии жизненного цикла (например, onStart).

Репозиторий в этом случае обычно предоставляет flow (если вы можете использовать экспериментальный api) или функцию приостановки, которая может выполнять следующие действия (которые могут варьироваться в зависимости от ваших бизнес-правил)

  1. Если данные доступны в базе данных, немедленно верните их.
  2. Если данные старые (или мы все еще хотим их обновить), выполните сетевой API (если для этого есть возможность подключения). Если нет подключения, вы можете сохранить этот ожидающий запрос в базе данных на будущее. Вы также можете проверить, есть ли у вас ожидающий запрос, прежде чем делать что-либо, возможно, он устарел или, возможно, вам нужно его выполнить.
  3. В любом случае после выполнения запроса вы вставляете результаты в базу данных и вызываете тот же метод, который использовали на шаге 1.
  4. Не забудьте обновить ожидающий запрос, если он у вас был (или если вы его используете).

С помощью WorkManager вы можете запланировать получение данных из части API в какой-то момент (так что ваши данные будут обновляться), но все действительно зависит от ваших вариантов использования.

person Martin Marconcini    schedule 23.02.2021
comment
@MartinMarconcini Я пытаюсь сделать что-то похожее на Мервина, только в обратном направлении, я думаю. Я пытаюсь взять введенные пользователем данные, кэшировать их, а затем отправить на сервер, когда сеть будет доступна. Не могли бы вы взглянуть на мой вопрос? stackoverflow.com/questions/66335097/ - person AndroidDev123; 23.02.2021
comment
@ AndroidDev123 Процесс аналогичен, вы сохраняете данные в базе данных (которая вообще не требует подключения). Затем вы можете сохранить параметры данных, которые вы собираетесь загрузить, в ожидающем запросе (объект / таблица, созданная вами), а затем вы можете запустить задание на выполнение ожидающего запроса (сейчас или позже через WM). Это в основном проверяет наличие ожидающих заданий, выполняет их и удаляет их из списка ожидающих. Как очередь сообщений. В любом случае это действительно то же самое. - person Martin Marconcini; 23.02.2021