Concatenamento dei lavori

WorkManager consente di creare e accodare una catena di lavoro che specifica più attività dipendenti e definisce l'ordine in cui devono essere eseguite. Questo è particolarmente utile quando devi eseguire diverse attività in un in un determinato ordine.

Per creare una catena di lavoro, puoi utilizzare WorkManager.beginWith(OneTimeWorkRequest) o WorkManager.beginWith(List<OneTimeWorkRequest>) , ognuno dei quali restituisce un'istanza WorkContinuation

È quindi possibile utilizzare un WorkContinuation per aggiungere un OneTimeWorkRequest dipendente di Compute Engine utilizzando then(OneTimeWorkRequest): o then(List<OneTimeWorkRequest>) di Google.

Ogni chiamata di WorkContinuation.then(...) restituisce una nuova istanza di WorkContinuation. Se aggiungi List di OneTimeWorkRequest istanze, queste richieste possono potenzialmente essere eseguite in parallelo.

Infine, puoi utilizzare WorkContinuation.enqueue() per enqueue() la tua catena di WorkContinuation.

Vediamo un esempio. In questo esempio, tre diversi job worker sono configurate per l'esecuzione (potenzialmente in parallelo). I risultati di questi worker sono quindi si è unito e passato a un job worker di memorizzazione nella cache. Infine, l'output il job viene passato a un worker di caricamento, che carica i risultati su o server web.

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

Fusioni di input

Quando concateni OneTimeWorkRequest istanze, l'output del lavoro padre inviate come input ai publisher secondari. Nell'esempio precedente, gli output di plantName1, plantName2 e plantName3 vengono passati come alla richiesta cache.

Per gestire gli input da più richieste di lavoro del genitore, WorkManager utilizza InputMerger

WorkManager offre due diversi tipi di InputMerger:

  • OverwritingInputMerger tenta di aggiungere all'output tutte le chiavi di tutti gli input. In caso di conflitti, sovrascriverà le chiavi impostate in precedenza.

  • ArrayCreatingInputMerger tenta di unire gli input, creando array quando necessario.

Se hai un caso d'uso più specifico, puoi scriverlo creando sottoclassi InputMerger.

SovrascritturaInputMerger

OverwritingInputMerger è il metodo di unione predefinito. Se sono presenti chiavi conflitti durante la fusione, l'ultimo valore di una chiave sovrascriverà qualsiasi precedenti nei dati di output risultanti.

Ad esempio, se gli input delle piante hanno ciascuno una chiave corrispondente ai rispettivi i nomi delle variabili ("plantName1", "plantName2" e "plantName3"), il parametro I dati passati al worker cache avranno tre coppie chiave-valore.

Diagramma che mostra tre job che passano diversi output al job successivo nella catena. Poiché i tre output hanno chiavi diverse, il job successivo riceve tre coppie chiave/valore.

Se c'è un conflitto, l'ultimo worker che completa "vince" e il suo valore viene passato a cache.

Diagramma che mostra tre job che passano gli output al job successivo nella catena. In questo caso, due di questi job producono output con la stessa chiave. Di conseguenza, il job successivo riceve due coppie chiave/valore, con uno degli output in conflitto eliminato.

Poiché le tue richieste di lavoro vengono eseguite in parallelo, non hai alcuna garanzia nell'ordine di esecuzione. Nell'esempio precedente, plantName1 potrebbe contenere un di "tulip" o "elm", a seconda di quale valore viene scritto per ultimo. Se esiste la possibilità che si verifichi un conflitto di chiavi e devi conservare tutti gli output in una fusione, ArrayCreatingInputMerger potrebbe essere un'opzione migliore.

ArrayCreazionediinput

Per l'esempio precedente, dato che vogliamo preservare i risultati di tutte le piante del nome worker, dovremmo usare un ArrayCreatingInputMerger.

Kotlin

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

Java

OneTimeWorkRequest cache = new OneTimeWorkRequest.Builder(PlantWorker.class)
       .setInputMerger(ArrayCreatingInputMerger.class)
       .setConstraints(constraints)
       .build();

ArrayCreatingInputMerger accoppia ogni chiave a un array. Se ogni chiave è univoco, il risultato sarà una serie di array con un solo elemento.

Diagramma che mostra tre job che passano diversi output al job successivo nella catena. Al job successivo vengono passati tre array, uno per ciascuna delle chiavi di output. Ogni array ha un singolo membro.

In caso di conflitti di chiavi, tutti i valori corrispondenti vengono raggruppati in un array.

Diagramma che mostra tre job che passano gli output al job successivo nella catena. In questo caso, due di questi job producono output con la stessa chiave. Al job successivo vengono passati due array, uno per ogni chiave. Uno di questi array ha due membri, poiché c&#39;erano due output con quella chiave.

Concatenamento e status di lavoro

Le catene di OneTimeWorkRequest vengono eseguite in sequenza fintanto che il loro lavoro viene completata correttamente (restituisce un Result.success()). Lavoro potrebbero non riuscire o essere annullate durante l'esecuzione, il che ha effetti downstream sulle e richieste di lavoro dipendenti.

Quando il primo OneTimeWorkRequest viene accodato in una catena di richieste di lavoro, tutte le richieste di lavoro successive vengono bloccate finché non viene eseguita la dell'utente.

Diagramma che mostra una catena di job. Il primo job è in coda: tutti i job successivi vengono bloccati fino al termine del primo.

Una volta accodata e soddisfatti tutti i vincoli di lavoro, la prima richiesta di lavoro in esecuzione. Se le operazioni vengono completate correttamente nella OneTimeWorkRequest o List<OneTimeWorkRequest> (ovvero, restituisce un Result.success()), il prossimo insieme di richieste di lavoro dipendenti sarà in coda.

Diagramma che mostra una catena di job. Il primo lavoro è riuscito e i due successori immediati sono accodati. I job rimanenti sono bloccati e il completamento dei job precedenti è bloccato.

Finché ogni richiesta di lavoro viene completata correttamente, lo stesso pattern si propaga al resto della catena di richieste di lavoro finché tutto il lavoro completata correttamente. Sebbene questo sia il caso più semplice e spesso preferito, sono altrettanto importanti.

Quando si verifica un errore mentre un lavoratore elabora la tua richiesta di lavoro, puoi: riprova a eseguire la richiesta in base a un criterio di backoff che hai definire. Un nuovo tentativo di inviare una richiesta che fa parte di una catena significa che ritentare con i dati di input che gli sono stati forniti. Qualsiasi lavoro eseguito in parallelo non sarà interessato.

Diagramma che mostra una catena di job. Uno dei job non è riuscito, ma aveva un criterio di backoff definito. Il job verrà eseguito nuovamente una volta trascorso il periodo di tempo appropriato. I job che seguono nella catena vengono bloccati finché non vengono eseguiti correttamente.

Per ulteriori informazioni sulla definizione di strategie personalizzate per i nuovi tentativi, consulta Ripetere e backoff Norme.

Se il criterio per i nuovi tentativi non è definito o esaurito, oppure raggiungi comunque in cui OneTimeWorkRequest restituisce Result.failure(), richiesta di lavoro e tutte le richieste di lavoro dipendenti sono contrassegnate come FAILED.

Diagramma che mostra una catena di job. Un job non è riuscito e non è possibile ritentare. Di conseguenza, anche tutti i job successivi alla catena hanno esito negativo.

La stessa logica si applica quando un OneTimeWorkRequest viene annullato. Qualsiasi dipendente Anche le richieste di lavoro sono contrassegnate come CANCELLED e il loro lavoro non verrà eseguito.

Diagramma che mostra una catena di job. È stato annullato un job. Di conseguenza, vengono annullati anche tutti i job successivi nella catena.

Tieni presente che se aggiungi altre richieste di lavoro a una catena non riuscita o ha annullato le richieste di lavoro, anche la richiesta di lavoro appena aggiunta verrà contrassegnati rispettivamente con FAILED o CANCELLED. Se vuoi estendere il lavoro di una catena esistente, vedi APPEND_OR_REPLACE in existingWorkPolicy.

Quando si creano catene di richieste di lavoro, le richieste di lavoro dipendenti devono definire nuovi criteri per garantire che il lavoro venga sempre completato in modo tempestivo. Le richieste di lavoro non riuscite potrebbero causare catene incomplete e/o stati imprevisti.

Per ulteriori informazioni, consulta la sezione Annullamento e interruzione. Lavoro.