WorkManager: Почему неудачная уникальная работа со стратегией «APPEND» ExistingWork не позволяет выполнять дополнительную работу под тем же именем?

Question

Допустим, мы разрабатываем приложение для обмена сообщениями, в котором мы хотим отправлять сообщения в данные разговоры, где порядок этих сообщений важен только в этом разговоре, и если приложение переводится в фоновый режим, мы хотим гарантировать, что сообщениебудет отправлено.

Метод WorkManager#beginUniqueWork кажется идеальным для этого, где uniqueWorkName будет некоторым идентификатором диалога, а ExistingWorkPolicy.APPEND будет использоваться в качестве рабочей политики, чтобы сохранить работу в запланированном порядке.

Пока в моем приложении, пока каждая часть Работы возвращает Result.SUCCESS, любая будущая запланированная работа будет выполняться, как ожидается.Однако, если одно конкретное сообщение не может быть отправлено фатальным способом, и я возвращаю Result.FAILURE, тогда вся дальнейшая работа с тем же идентификатором диалога никогда не достигнет моей реализации Worker#doWork().

После просмотра исходного кода класса EnqueueRunnable это кажется очень осознанным выбором.Что я не могу понять, так это почему?Кажется странным, что если uniqueWorkName терпит неудачу, то это имя становится непригодным для остальной части жизни приложения (это сохраняется при уничтожении приложения).

Кроме того, я хотел бы знать, если кто-нибудьимеет хорошее решение для этого, или знает, изменится ли это в будущих версиях WorkManager.Пока что самое лучшее, что я могу придумать, это вернуть Result.SUCCESS, но закодировать мое собственное состояние отказа в выходных данных Data, чтобы все наблюдатели работы знали, что это не удалось.Это, однако, немного неловко и не очень очевидно для будущих сопровождающих кода (и может быть немного запутанным при просмотре журналов для данного фрагмента Work).

Возможно, мое предполагаемое использование уникальной работы совершенно неверно, и есть лучшее решение там.Любые идеи будут с благодарностью, спасибо!

Answer 1

Так что я нашел ответ на свой вопрос в этом отчете системы отслеживания проблем Google .

По сути, уникальная работа с использованием стратегии APPEND создает WorkContinuation, где каждый новый элементприкован, как если бы мы использовали метод WorkContinuation#then.Сбой или отмена цепочки отменяет всю последующую работу, и поэтому это предполагаемое поведение.

Билет предлагает 2 подхода:

Если вы действительно хотите поведение APPEND, тогда вы могли бы также проверить, есть ли WorkStatuses WorkRequests, и если (все они произошли)быть отмененным) используйте REPLACE вместо APPEND.Имейте в виду, что это по своей сути очень странно, потому что ваши WorkRequests еще не могли быть отменены.Поэтому убедитесь, что у вас есть некоторые примитивы синхронизации для использования API WorkManager.

и

Самый простой способ сделать это - не возвращать Result.FAILED;если вы всегда возвращаете SUCCEEDED и возвращаете фактический бит прохождения / сбоя (если необходимо) в выходных данных, вы можете убедиться, что цепочка всегда продолжает работать.

Это то, что я уже делаю.Надеюсь, это поможет кому-то еще.