Łączenie łańcuchów

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ść.

Schemat przedstawiający 3 zadania przekazujące różne dane wyjściowe do następnego zadania w łańcuchu. Wszystkie 3 wyjścia mają różne klucze, więc kolejne zadanie otrzymuje 3 pary klucz-wartość.

W przypadku konfliktu to ostatni robot, który uzupełni „wygrane” i jego wartość. jest przekazywana do funkcji cache.

Schemat przedstawiający 3 zadania przekazujące dane wyjściowe do następnego zadania w łańcuchu. W tym przypadku 2 z tych zadań wygenerują dane wyjściowe z tym samym kluczem. W efekcie kolejne zadanie otrzymuje 2 pary klucz-wartość, a jeden z konfliktujących się wyników jest pomijany.

Żą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.

Schemat przedstawiający 3 zadania przekazujące różne dane wyjściowe do następnego zadania w łańcuchu. Kolejne zadanie przekazuje 3 tablice, po 1 dla każdego klucza wyjściowego. Każda tablica ma jednego element.

Jeśli wystąpią kolizje kluczy, wszystkie odpowiadające im wartości zostaną zgrupowane razem w tablicy.

Schemat przedstawiający 3 zadania przekazujące dane wyjściowe do następnego zadania w łańcuchu. W tym przypadku 2 z tych zadań generują dane wyjściowe z tym samym kluczem. Następne zadanie przekazuje 2 tablice, po 1 dla każdego klucza. Jeden z tych tablic ma 2 elementy, ponieważ były 2 wyjścia z tym kluczem.

Ł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.

Diagram przedstawiający łańcuch zadań. Pierwsze zadanie jest umieszczane w kolejce, a wszystkie kolejne są blokowane do czasu jego zakończenia.

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.

Diagram przedstawiający łańcuch zadań. Pierwsze zadanie zostało ukończone, a dwa następne są w kolejce. Pozostałe zadania są blokowane do czasu zakończenia poprzednich zadań.

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.

Diagram przedstawiający łańcuch zadań. Jedno z zadań zakończyło się niepowodzeniem, ale zdefiniowano zasadę ponowienia. To zadanie zostanie ponownie uruchomione po upływie odpowiedniego czasu. Kolejne zadania w łańcuchu będą blokowane, dopóki nie zostaną uruchomione.

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..

Diagram przedstawiający łańcuch zadań. Jedno zadanie nie powiodło się i nie można go powtórzyć. W rezultacie wszystkie kolejne zadania w łańcuchu również kończą się niepowodzeniem.

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.

Diagram przedstawiający łańcuch zadań. 1 zadanie zostało anulowane. W efekcie wszystkie zadania po nim w łańcuchu również zostaną anulowane.

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.