WorkManager: как обрабатываются сетевые ограничения при использовании AlarmManager?
Похоже, что WorkManager использует AlarmManager под капотом для версий Android старше 21, потому что JobScheduler недоступен. См., Например, здесь.
Но при установке сетевого ограничения с помощью WorkManager в следующих строках:
Constraints.Builder constraintsBuilder = new Constraints.Builder();
constraintsBuilder.setRequiredNetworkType(NetworkType.CONNECTED);
Constraints constraints = constraintsBuilder.build();
OneTimeWorkRequest.Builder workRequestBuilder = new OneTimeWorkRequest.Builder(MyWorker.class);
workRequestBuilder.setInitialDelay(5000, TimeUnit.MILLISECONDS);
workRequestBuilder.setConstraints(constraints);
С JobScheduler поведение, похоже, таково, что запланированное задание просто будет оставаться там, пока сеть не будет восстановлена, а затем оно немедленно сработает, потому что ограничения теперь соблюдены.
Но будильники немного отличаются и, естественно, не имеют связанных ограничений. Итак, как же на самом деле обрабатываются сетевые ограничения для Android <21, когда он полагается на AlarmManager? Что произойдет, если сигнал тревоги сработает при отсутствии сети? Мой ограниченный опыт показывает, что это не обрабатывается должным образом (или вообще), и мне интересно, нужно ли обрабатывать сетевые ограничения вручную, прослушивая CONNECTIVITY_CHANGE?
@GabeSechan, но перенести на какое время? Допустим, я планирую работу (будильник) на 6 часов, а через шесть часов срабатывает будильник (при отсутствии сети), какое разумное решение может принять WorkManager относительно того, когда перенести будильник? Еще шесть часов? Произвольные 5 минут, 1 минута или что?
Вам придется погрузиться в код ОС, чтобы понять это, и я ожидаю, что со временем он изменится как деталь реализации. Однако я ожидал, что JobScheduler работает не лучше - оба они являются слоями, написанными поверх AlarmManager, они не являются настоящей заменой снизу вверх.
WorkManager уже прослушивает CONNECTIVITY_CHANGE. Больше ничего делать не нужно.
Ответы 1
WorkManager уже прослушивает CONNECTIVITY_CHANGE - то, что он использует сигналы тревоги, не означает, что это единственный сигнал, который он использует. Вам ничего не нужно делать вручную; WorkManager выполняет все отслеживание ограничений за вас.
Это то, что я ожидал, хотя на практике, похоже, это не сработало. Основываясь на некоторых наблюдениях с эмулятором, работающим под управлением 4.3, похоже, что этого не происходило ... т.е. я мог видеть, что работа была запланирована для запуска (для обновления виджета), когда подключение было отключено, но при восстановлении подключения работа, похоже, не сработала. Я снова переключился на свой устаревший код для просмотра CONNECTIVITY_CHANGE в моем AppWidgetProvider (и без устанавливает сетевое ограничение для работы), и он снова ведет себя так, как я ожидал ... виджет обновляется немедленно при восстановлении сети.
Мой AppWidgetProvider все еще был зарегистрирован для получения CONNECTIVITY_CHANGE при тестировании WorkManager с сетевым ограничением ... это не испортит ситуацию? В onReceive() я вызываю super.onReceive(), и WorkManager должен сам по себе иметь возможность использовать триггеры изменения подключения для управления работой с ограничениями по сети до 21 года? Просто со мной этого не происходило.
Я вернусь и проверю, есть ли что-то еще в игре. Ваш ответ действительно дает мне уверенность в том, что WorkManager должен делает то, что я ожидаю от него ... и, если окажется, что он предоставляет единый интерфейс для планирования заданий / работы, который эффективен для всех версий Android ... это было бы для меня Святым Граалем ... было бы потрясающе.
Сигнал тревоги может просто проверить наличие Интернета и, если он не найдет его, перенести.