Я просто играю с JobScheduler, и у меня есть пара мелочей.
Один из них заключается в том, что, хотя вы можете отложить задание, используя setMinimumLatency(), вы не можете использовать это в сочетании с setPeriodic(), так как возникает исключение.
Я действительно не могу понять, почему это так... кажется разумным отложить запуск периодического задания, так же как разумно отложить запуск одноразового задания.
Учитывая, что вы не можете, как лучше всего запланировать периодическое задание, которое запускается в будущем (даже после перезагрузки), используя JobScheduler?
AlarmManager, чтобы получить контроль в то время, когда вы хотите, чтобы задания запускались . - person CommonsWare schedule 03.09.2016AlarmManager, но я подумал, чтоJobScheduler— это рекомендуемый путь вперед. Основная причина, по которой я рассматриваю возможность перехода к использованиюJobScheduler, заключается в том, что прослушиваниеCONNECTIVITY_CHANGEв моемAppWidgetProviderбольше невозможно в Android N. Поэтому я перехожу от решенияAlarmManagerс прослушиванием подключения кJobScheduler(подключение -слушаю) решение с...AlarmManagerболтом. Хей-хо. - person drmrbrewer schedule 03.09.2016AlarmManagerдля планирования периодического обновления виджета (с большей гибкостью, чем позволяют стандартные методыAppWidgetProvider, включая обновление после восстановления подключения, когда обновление было пропущено). Все это прекрасно работает... но теперь они убралиCONNECTIVITY_CHANGE:-( Может быть, мне нужно сохранить неповрежденнойAlarmManagerструктуру и просто запланироватьJobService(чтобы прослушивать соединение) при каждом обновлении тревоги, а не сразу запускатьService, как в настоящее время. - person drmrbrewer schedule 03.09.2016