WorkManager pozwala utworzyć i umieścić w kolejce łańcuch pracy, który określa wiele zależnych zadań i określa, w jakiej kolejności należy je uruchomić. Ten jest szczególnie przydatna, gdy należy uruchomić kilka zadań w określonym zamówieniu.
Aby utworzyć łańcuch zadań, możesz użyć funkcji WorkManager.beginWith(OneTimeWorkRequest)
lub WorkManager.beginWith(List<OneTimeWorkRequest>)
, które zwracają instancję WorkContinuation
.
Następnie za pomocą WorkContinuation
można dodawać zależne wystąpienia OneTimeWorkRequest
za pomocą then(OneTimeWorkRequest)
lub then(List<OneTimeWorkRequest>)
.
Każde wywołanie funkcji WorkContinuation.then(...)
zwraca nowy egzemplarz funkcji WorkContinuation
. Jeśli dodasz List
z OneTimeWorkRequest
instancji, te żądania mogą być uruchamiane równolegle.
Na koniec możesz użyć funkcji
WorkContinuation.enqueue()
do enqueue()
Twojego łańcucha WorkContinuation
.
Przeanalizujmy przykład. W tym przykładzie 3 różne zadania instancji roboczej to skonfigurowane do działania (potencjalnie równolegle). Wyniki tych zadań są następnie łączone i przekazywane do zadania Workera obsługującego buforowanie. W końcu dane wyjściowe tego zadania są przekazywane do roboczego przesyłania, który przesyła wyniki na zdalny serwer.
Kotlin
WorkManager.getInstance(myContext) // Candidates to run in parallel .beginWith(listOf(plantName1, plantName2, plantName3)) // Dependent work (only runs after all previous work in chain) .then(cache) .then(upload) // Call enqueue to kick things off .enqueue()
Java
WorkManager.getInstance(myContext) // Candidates to run in parallel .beginWith(Arrays.asList(plantName1, plantName2, plantName3)) // Dependent work (only runs after all previous work in chain) .then(cache) .then(upload) // Call enqueue to kick things off .enqueue();
Złączenia danych wejściowych
Gdy połączysz tyle instancji: OneTimeWorkRequest
, dane wyjściowe instancji nadrzędnej będą działać
są przekazywane do elementów podrzędnych jako dane wejściowe. W tym przykładzie dane wyjściowe plantName1
, plantName2
i plantName3
są przekazywane jako dane wejściowe do żądania cache
.
Aby zarządzać danymi wejściowymi pochodzącymi z wielu nadrzędnych żądań roboczych, WorkManager używa
InputMerger
WorkManager udostępnia 2 różne typy znaczników InputMerger
:
OverwritingInputMerger
próbuje dodać wszystkie klucze ze wszystkich danych wejściowych do danych wyjściowych. W przypadku konfliktów zastąpi on wcześniej ustawione klucze.ArrayCreatingInputMerger
próbuje scalić dane wejściowe, w razie potrzeby tworząc tablice.
Jeśli masz bardziej szczegółowy przypadek użycia, możesz utworzyć własny, stosując klasyfikację podklasyczną.
InputMerger
Nadpisanie danych wejściowych
Domyślną metodą scalania jest OverwritingInputMerger
. Jeśli podczas scalania wystąpią konflikty kluczy, najnowsza wartość klucza zastąpi wszystkie poprzednie wersje w wynikających danych wyjściowych.
Jeśli np. każdy z wejść plant ma klucz pasujący do nazwy odpowiedniej zmiennej ("plantName1"
, "plantName2"
i "plantName3"
), dane przekazywane instancji roboczej cache
będą zawierać 3 pary klucz-wartość.
W przypadku konfliktu to ostatni robot, który uzupełni „wygrane” i jego wartość.
jest przekazywana do funkcji cache
.
Żądania służbowe są uruchamiane równolegle, więc nie masz gwarancji dla
w kolejności ich wyświetlania. W powyższym przykładzie zmienna plantName1
może zawierać wartość "tulip"
lub "elm"
, w zależności od tego, która wartość została zapisana jako ostatnia. Jeśli istnieje ryzyko konfliktu kluczy i musisz zachować wszystkie dane wyjściowe podczas scalania, ArrayCreatingInputMerger
może być lepszą opcją.
dzielenie danych tablica.
W przypadku powyższego przykładu, ponieważ chcemy zachować dane wyjściowe z wszystkich pracowników fabryki o nazwie Workers, powinniśmy użyć ArrayCreatingInputMerger
.
Kotlin
val cache: OneTimeWorkRequest = OneTimeWorkRequestBuilder<PlantWorker>() .setInputMerger(ArrayCreatingInputMerger::class) .setConstraints(constraints) .build()
Java
OneTimeWorkRequest cache = new OneTimeWorkRequest.Builder(PlantWorker.class) .setInputMerger(ArrayCreatingInputMerger.class) .setConstraints(constraints) .build();
ArrayCreatingInputMerger
paruje każdy klucz z tablicą. Jeśli każdy z kluczy
jest unikalny, wynik to seria jednoelementowych tablic.
Jeśli wystąpią kolizje kluczy, wszystkie odpowiadające im wartości zostaną zgrupowane razem w tablicy.
Łańcuchowanie i stany pracy
Łańcuchy OneTimeWorkRequest
są wykonywane sekwencyjnie, dopóki ich wykonanie się powiedzie (czyli zwrócą wartość Result.success()
). Żądania o wykonanie pracy mogą się nie udać lub zostać anulowane podczas wykonywania, co ma wpływ na zależne żądania o wykonanie pracy.
Gdy pierwsze OneTimeWorkRequest
zostanie umieszczone w kolejce w łańcuchu żądań pracy, wszystkie kolejne żądania pracy są blokowane do czasu zakończenia pracy związanej z pierwszym żądaniem.
Po dodaniu do kolejki i spełnieniu wszystkich ograniczeń roboczych pierwsze żądanie robocze
rozpocznie się bieg. Jeśli praca zostanie ukończona w katalogu głównym
OneTimeWorkRequest
lub List<OneTimeWorkRequest>
(tzn. zwraca błąd
Result.success()
), następny zestaw zależnych żądań roboczych będzie
dodano do kolejki.
Dopóki każde żądanie służbowe zostanie zrealizowane, ten sam wzorzec jest rozpowszechniana przez pozostałą część łańcucha żądań, aż cała praca w łańcuch jest gotowy. Chociaż jest to najprostszy i najczęściej preferowany przypadek, stany błędów są równie ważne.
Jeśli podczas przetwarzania Twojego żądania pracy wystąpi błąd, możesz ponownie przesłać to żądanie zgodnie z zdefiniowanymi przez Ciebie zasadami wycofywania. Ponowne próby wykonania żądania, które jest częścią łańcucha, oznaczają, że zostanie ono powtórnie wykonane z podawanymi danymi wejściowymi. Równoległa praca będzie co się nie zmienia.
Więcej informacji na temat definiowania niestandardowych strategii ponownych prób znajdziesz w artykule Ponawianie próby i czas do ponowienia Zasady.
Jeśli zasada ponownego próbowania jest niezdefiniowana lub wyczerpana albo jeśli w jakimś stanie OneTimeWorkRequest
zwraca wartość Result.failure()
, to żądanie pracy i wszystkie zależne żądania pracy są oznaczane jako FAILED.
.
Ta sama zasada obowiązuje, gdy anulujesz OneTimeWorkRequest
. Dowolne zależne
Żądania robocze są również oznaczane jako CANCELLED
, a ich zadania nie będą wykonywane.
Jeśli dodasz więcej próśb o przeniesienie do łańcucha, który nie został zakończony lub został anulowany, nowo dodana prośba zostanie odpowiednio oznaczona jako FAILED
lub CANCELLED
. Jeśli chcesz przedłużyć pracę
istniejącej sieci, wyświetl APPEND_OR_REPLACE
w
Istniejące zasady pracy.
Podczas tworzenia łańcuchów żądań pracy żądania zależne powinny definiować zasady ponownych prób, aby zapewnić terminowe wykonywanie pracy. Nieudane żądania pracy mogą spowodować niekompletne łańcuchy lub nieoczekiwany stan.
Więcej informacji znajdziesz w sekcji Anulowanie i zatrzymywanie Praca.