WorkManager

Всю прошлую неделю у меня с коллегой был вялотекущий спор на одну тему. Представьте, что у нас есть WorkManager. Мы решили, что он будет работать каждые 12 часов. По каким-то триггерам и после перезагрузки мы его планируем заново с флагом REPLACE. Но что произойдет, если пользователь будет выключать телефон через 10 часов на ночь (никогда не будет активного промежутка в 12 часов)? Значит ли это, что WorkManager никогда не отработает? У меня и у коллеги были противоположные мнения, но никто не собирался отступать...

Есть несколько способов: — Самый простой способ, который, к сожалению, работает только для API 26+. В самой студии нажимаем на App Inspection — выбираем нужное устройство. Из плюсов: тут даже база отображается и можно посмотреть как внутри библиотеки хранятся воркеры. Информации там очень много, так что точно получится найти нужную. Если переключимся на Background Task Inspector, то увидим все наши воркеры и в каком они сейчас состоянии. Можно кликнуть и посмотреть подробнее. — adb shell dumpsys jobscheduler...

Про плюсы и минусы мы уже поговорили, так что теперь узнаем как создать WorkManager и какой выбрать. Всего есть 4 варианта: Во всех воркерах у нас обязательно переопределяется один метод, где выполняется вся работа. Первые два воркера возвращают Result. RxWorker возвращает Single<Result>. ListenableWorker возвращает ListenableFuture<Result>. Result — это тип с тремя состояниями. Может быть: Воркер может быть одноразовым или многоразовым. И тут для двух вариантов целых три метода запуска: Я советую использовать именно последние два варианта, чтобы можно было указать имя и existingWorkPolicy...

Довольно часто случается, что нам нужно сделать какую-то фоновую работу в приложении. Например, отправить логи или какие-то метрики на сервер, обновить данные в базе или сделать что-то ещё, что не требует присутствия пользователя. В этом случае, если действие будет длиться меньше 10 минут и не требует запуска прям в определенное время с точностью до минут, то нам идеально подойдет WorkManager...