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

Do utworzenia łańcucha zadań możesz użyć WorkManager.beginWith(OneTimeWorkRequest) lub WorkManager.beginWith(List<OneTimeWorkRequest>) , z których każdy zwraca wystąpienie WorkContinuation.

Za pomocą funkcji WorkContinuation można następnie dodać zależne elementy OneTimeWorkRequest instancji korzystających z funkcji then(OneTimeWorkRequest). lub then(List<OneTimeWorkRequest>). ,

Każde wywołanie funkcji WorkContinuation.then(...) zwraca nowe wystąpienie 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 procesów roboczych są a następnie został dołączony i przekazany do zadania instancji roboczej buforowania. Dane wyjściowe tego narzędzia jest przekazywane do instancji roboczej przesyłania, która przesyła wyniki do modułu zdalnego serwera.

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()

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();

Fuzje 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 powyższym przykładzie dane wyjściowe plantName1, plantName2 i plantName3 byłyby przekazywane jako danych wejściowych 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ć do danych wyjściowych wszystkie klawisze ze wszystkich wejść. W przypadku konfliktów zastąpią one 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 napisać własny, stosując klasyfikację podklasyczną. InputMerger

Nadpisanie danych wejściowych

Domyślną metodą scalania jest OverwritingInputMerger. Jeśli klucz podczas scalania konflikty, najnowsza wartość klucza zastąpi wszystkie starsze wersje w wynikowych danych wyjściowych.

Jeśli na przykład dane wejściowe rośliny mają klucz pasujący do nazw zmiennych ("plantName1", "plantName2" i "plantName3"), a następnie dane przekazywane do instancji roboczej cache będą miały 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 plantName1 może zawierać element wartość "tulip" lub "elm", w zależności od tego, która wartość jest zapisana. na końcu. Jeśli istnieje możliwość wystąpienia kluczowego konfliktu i musisz zachować wszystkie dane wyjściowe danych w ramach fuzji, lepszym rozwiązaniem będzie ArrayCreatingInputMerger.

Scalanie_tablic

W powyższym przykładzie, ponieważ chcemy zachować wyniki uzyskane ze wszystkich zakładów nazwa Workers, powinniśmy użyć ArrayCreatingInputMerger.

val cache: OneTimeWorkRequest = OneTimeWorkRequestBuilderP<lantWorker(>)
   .setInputMerger(ArrayCreatingInputMerger::class)
   .setConstraints(constraints)
   .build()

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ńcuch i stany pracy

Łańcuchy OneTimeWorkRequest są realizowane sekwencyjnie tak długo, jak długo działają kończy się poprawnie (tzn. zwraca Result.success()). Służbowy mogą nie zostać zrealizowane lub mogą zostać anulowane podczas wykonywania, co ma wpływ na dalszy ciąg zależnych od pracy.

Gdy pierwszy element (OneTimeWorkRequest) zostanie umieszczony w kolejce w łańcuchu żądań, wszystkie kolejne żądania dotyczące pracy są blokowane do czasu wykonania tego pierwszego zadania. .

Po dodaniu do kolejki i spełnieniu wszystkich ograniczeń roboczych pierwsze żądanie robocze zaczyna biegać. 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 zakończony. Choć jest to najprostszy i najczęściej preferowany przypadek, błąd są równie ważne.

Jeśli błąd wystąpi podczas przetwarzania Twojego żądania służbowego przez pracownika, możesz ponów żądanie zgodnie z zasadami ponownych prób definicjami. Ponowienie żądania, które jest częścią łańcucha, oznacza, że tylko to żądanie ponowiona, korzystając z dostarczonych danych wejściowych. 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 te zasady są niezdefiniowane lub wyczerpane albo jeśli w inny sposób osiągniesz stan, w którym OneTimeWorkRequest zwraca Result.failure(), a następnie to żądanie robocze i wszystkie zależne żądania pracy są oznaczone jako FAILED.

Te same zasady obowiązują w przypadku anulowania polecenia OneTimeWorkRequest. Dowolne zależne Żądania robocze są również oznaczane jako CANCELLED, a ich zadania nie będą wykonywane.

Pamiętaj, że w przypadku dołączenia większej liczby żądań roboczych do łańcucha, który zakończył się niepowodzeniem lub Użytkownik anulował zlecenia robocze, Twoje nowo dołączone zlecenie pracy również zostanie oznaczony odpowiednio FAILED lub CANCELLED. Jeśli chcesz przedłużyć pracę istniejącej sieci, wyświetl APPEND_OR_REPLACE w Istniejące zasady pracy.

Przy tworzeniu łańcuchów żądań służbowych zależne żądania powinny określać ponawiaj próby, aby zapewnić szybkie zakończenie pracy. Nieudane żądania robocze mogą skutkować niepełnymi łańcuchami lub nieoczekiwanym stanem.

Więcej informacji znajdziesz w sekcji Anulowanie i zatrzymywanie Praca.