Arbeitsanfragen definieren

Im Einstiegsleitfaden haben wir beschrieben, wie du eine einfache WorkRequest erstellst und in die Warteschlange einfügst.

In diesem Leitfaden erfahren Sie, wie Sie WorkRequest-Objekte für gängige Anwendungsfälle definieren und anpassen. Dazu gehören:

• Einmalige und wiederkehrende Aufgaben planen
• Arbeitsbeschränkungen festlegen, z. B. dass eine WLAN- oder Ladestation erforderlich ist
• Eine minimale Verzögerung bei der Ausführung von Aufgaben gewährleisten
• Strategien für Wiederholungen und Backoffs festlegen
• Eingabedaten an Workflow übergeben
• Ähnliche Aufgaben mithilfe von Tags gruppieren

Übersicht

Arbeit wird in WorkManager über eine WorkRequest definiert. Wenn Sie eine Aufgabe mit WorkManager planen möchten, müssen Sie zuerst ein WorkRequest-Objekt erstellen und dann in die Warteschlange einfügen.

Kotlin

val myWorkRequest = ...
WorkManager.getInstance(myContext).enqueue(myWorkRequest)

Java

WorkRequest myWorkRequest = ...
WorkManager.getInstance(myContext).enqueue(myWorkRequest);

Das WorkRequest-Objekt enthält alle Informationen, die WorkManager zum Planen und Ausführen Ihrer Arbeit benötigt. Es enthält Einschränkungen, die erfüllt werden müssen, damit Ihre Arbeit ausgeführt werden kann, Planungsinformationen wie Verzögerungen oder wiederkehrende Intervalle, die Konfiguration für Wiederholungen und möglicherweise Eingabedaten, wenn diese für Ihre Arbeit erforderlich sind.

WorkRequest ist selbst eine abstrakte Basisklasse. Es gibt zwei abgeleitete Implementierungen dieser Klasse, mit denen Sie die Anfrage erstellen können: OneTimeWorkRequest und PeriodicWorkRequest. Wie die Namen andeuten, ist OneTimeWorkRequest nützlich für die Planung nicht wiederkehrender Aufgaben, während PeriodicWorkRequest besser für die Planung von Aufgaben geeignet ist, die in einem bestimmten Intervall wiederholt werden.

Einmalige Arbeiten planen

Für eine einfache Arbeit, die keine zusätzliche Konfiguration erfordert, verwenden Sie die statische Methode from:

Kotlin

val myWorkRequest = OneTimeWorkRequest.from(MyWork::class.java)

Java

WorkRequest myWorkRequest = OneTimeWorkRequest.from(MyWork.class);

Für komplexere Aufgaben können Sie einen Builder verwenden:

Kotlin

val uploadWorkRequest: WorkRequest =
   OneTimeWorkRequestBuilder<MyWork>()
       // Additional configuration
       .build()

Java

WorkRequest uploadWorkRequest =
   new OneTimeWorkRequest.Builder(MyWork.class)
       // Additional configuration
       .build();

Schnelle Arbeiten planen

Mit WorkManager 2.7.0 wurde das Konzept der beschleunigten Arbeit eingeführt. So kann WorkManager wichtige Aufgaben ausführen und das System hat eine bessere Kontrolle über den Zugriff auf Ressourcen.

Schnelle Arbeiten zeichnen sich durch folgende Merkmale aus:

• Wichtigkeit: Beschleunigte Arbeit eignet sich für Aufgaben, die für den Nutzer wichtig sind oder vom Nutzer initiiert werden.
• Geschwindigkeit: Die beschleunigte Bearbeitung eignet sich am besten für kurze Aufgaben, die sofort beginnen und innerhalb weniger Minuten abgeschlossen werden.
• Kontingente: Ein Kontingent auf Systemebene, das die Ausführungszeit im Vordergrund begrenzt, bestimmt, ob ein beschleunigter Job gestartet werden kann.
• Energiesparmodus: Einschränkungen der Energieverwaltung wie der Energiesparmodus und der Stromsparmodus wirken sich weniger wahrscheinlich auf die beschleunigte Arbeit aus.
• Latenz: Das System führt die beschleunigte Arbeit sofort aus, sofern die aktuelle Arbeitslast des Systems dies zulässt. Das bedeutet, dass sie latenzempfindlich sind und nicht für eine spätere Ausführung geplant werden können.

Ein potenzieller Anwendungsfall für beschleunigte Arbeit könnte in einer Chat-App auftreten, wenn der Nutzer eine Nachricht oder ein angehängtes Bild senden möchte. Ähnlich kann bei einer App, die einen Zahlungs- oder Abovorgang verarbeitet, die beschleunigte Ausführung verwendet werden. Das liegt daran, dass diese Aufgaben für den Nutzer wichtig sind, schnell im Hintergrund ausgeführt werden, sofort beginnen und auch dann fortgesetzt werden sollten, wenn der Nutzer die App schließt.

Kontingente

Das System muss einem beschleunigten Job die Ausführungszeit zuweisen, bevor er ausgeführt werden kann. Die Ausführungszeit ist nicht unbegrenzt. Stattdessen erhält jede App ein Kontingent an Ausführungszeit. Wenn Ihre App die Ausführungszeit aufgebraucht hat und das zugewiesene Kontingent erreicht, können Sie erst wieder beschleunigte Aufgaben ausführen, wenn das Kontingent aktualisiert wurde. So kann Android die Ressourcen effektiver zwischen den Anwendungen verteilen.

Die für eine App verfügbare Ausführungszeit hängt vom Standby-Bucket und der Prozessbedeutung ab.

Sie können festlegen, was passiert, wenn aufgrund des Ausführungsquotats ein beschleunigter Job nicht sofort ausgeführt werden kann. Weitere Informationen finden Sie in den Snippets unten.

Hinweis: Wenn sich Ihre App im Vordergrund befindet, werden die beschleunigten Aufgaben nicht durch Kontingente begrenzt. Ein Kontingent für die Ausführungszeit gilt nur, wenn sich Ihre App im Hintergrund befindet oder in den Hintergrund verschoben wird. Daher sollten Sie die Arbeit beschleunigen, die Sie im Hintergrund fortsetzen möchten. Sie können setForeground() weiterhin verwenden, während die App im Vordergrund ausgeführt wird.

Beschleunigte Bearbeitung von Aufgaben

Ab WorkManager 2.7 kann Ihre App setExpedited() aufrufen, um anzugeben, dass eine WorkRequest mit einem beschleunigten Job so schnell wie möglich ausgeführt werden soll. Das folgende Code-Snippet zeigt ein Beispiel für die Verwendung von setExpedited():

Kotlin

val request = OneTimeWorkRequestBuilder<SyncWorker>()
    .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
    .build()

WorkManager.getInstance(context)
    .enqueue(request)

Java

OneTimeWorkRequest request = new OneTimeWorkRequestBuilder<T>()
    .setInputData(inputData)
    .setExpedited(OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST)
    .build();

In diesem Beispiel initialisieren wir eine Instanz von OneTimeWorkRequest und rufen setExpedited() dafür auf. Diese Anfrage wird dann beschleunigt. Wenn das Kontingent dies zulässt, wird es sofort im Hintergrund ausgeführt. Wenn das Kontingent aufgebraucht ist, gibt der Parameter OutOfQuotaPolicy an, dass die Anfrage wie eine normale, nicht beschleunigte Anfrage ausgeführt werden soll.

Abwärtskompatibilität und Dienste im Vordergrund

Zur Aufrechterhaltung der Abwärtskompatibilität für beschleunigte Jobs führt WorkManager unter Plattformversionen älter als Android 12 möglicherweise einen Dienst im Vordergrund aus. Dienste im Vordergrund können dem Nutzer eine Benachrichtigung anzeigen.

Mit den Methoden getForegroundInfoAsync() und getForegroundInfo() in Ihrem Worker können Sie WorkManager dazu veranlassen, vor Android 12 eine Benachrichtigung anzuzeigen, wenn Sie setExpedited() aufrufen.

Jede ListenableWorker muss die Methode getForegroundInfo implementieren, wenn Sie anfordern möchten, dass die Aufgabe als beschleunigter Job ausgeführt wird.

Achtung :Wenn die entsprechende getForegroundInfo-Methode nicht implementiert wird, kann es beim Aufrufen von setExpedited auf älteren Plattformversionen zu Laufzeitabstürzen führen.

Bei einer Ausrichtung auf Android 12 oder höher bleiben Dienste im Vordergrund über die entsprechende setForeground-Methode für Sie verfügbar.

Achtung: setForeground() kann unter Android 12 Laufzeitausnahmen auslösen. Das ist auch möglich, wenn der Start eingeschränkt wurde.

Mitarbeiter

Die Mitarbeiter wissen nicht, ob die von ihnen ausgeführte Arbeit beschleunigt wird oder nicht. Bei einigen Android-Versionen können Kundenservicemitarbeiter jedoch eine Benachrichtigung anzeigen, wenn eine WorkRequest beschleunigt wurde.

Dafür stellt WorkManager die Methode getForegroundInfoAsync() bereit, die du implementieren musst, damit WorkManager bei Bedarf eine Benachrichtigung zum Starten eines ForegroundService für dich anzeigen kann.

CoroutineWorker

Wenn Sie eine CoroutineWorker verwenden, müssen Sie getForegroundInfo() implementieren. Sie übergeben sie dann an setForeground() in doWork(). Dadurch wird die Benachrichtigung in Android-Versionen vor 12 erstellt.

Betrachten Sie das folgende Beispiel:

  class ExpeditedWorker(appContext: Context, workerParams: WorkerParameters):
   CoroutineWorker(appContext, workerParams) {

   override suspend fun getForegroundInfo(): ForegroundInfo {
       return ForegroundInfo(
           NOTIFICATION_ID, createNotification()
       )
   }

   override suspend fun doWork(): Result {
       TODO()
   }

    private fun createNotification() : Notification {
       TODO()
    }

}

Hinweis: Sie sollten setForeground() in einem try/catch-Block einschließen, um einen potenziellen IllegalStateException zu erkennen. Diese können auftreten, wenn Ihre App zu diesem Zeitpunkt nicht im Vordergrund ausgeführt werden kann. Ab Android 12 können Sie die detailliertere ForegroundServiceStartNotAllowedException verwenden.

Kontingentrichtlinien

Sie können festlegen, was mit beschleunigten Aufgaben passiert, wenn Ihre App das Ausführungslimit erreicht. Sie haben folgende Möglichkeiten, um setExpedited() weiterzugeben:

• OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST, wodurch der Job als normale Arbeitsanfrage ausgeführt wird. Das obige Snippet veranschaulicht dies.
• OutOfQuotaPolicy.DROP_WORK_REQUEST: Damit wird die Anfrage abgebrochen, wenn das Kontingent nicht ausreicht.

Beispiel-App

Ein vollständiges Beispiel dafür, wie WorkManager 2.7.0 beschleunigte Arbeit nutzt, finden Sie im WorkManagerSample auf GitHub.

Verschobene Express-Aufträge

Das System versucht, einen bestimmten Express-Job so schnell wie möglich nach dem Aufruf des Jobs auszuführen. Wie bei anderen Arten von Jobs kann das System den Start neuer beschleunigter Arbeiten jedoch verschieben, z. B. in den folgenden Fällen:

• Last: Die Systemlast ist zu hoch. Sie kann auftreten, wenn bereits zu viele Jobs ausgeführt werden oder das System nicht über genügend Arbeitsspeicher verfügt.
• Kontingent: Das Kontingent für beschleunigte Jobs wurde überschritten. Für die beschleunigte Verarbeitung wird ein Kontingentsystem verwendet, das auf den App-Standby-Buckets basiert und die maximale Ausführungszeit innerhalb eines rollierenden Zeitfensters begrenzt. Die Kontingente für beschleunigte Arbeiten sind strenger als die für andere Arten von Hintergrundjobs.

Regelmäßige Aufgaben planen

Ihre App kann gelegentlich erfordern, dass bestimmte Arbeiten regelmäßig ausgeführt werden. Beispielsweise können Sie Ihre Daten regelmäßig sichern, neue Inhalte in Ihrer Anwendung herunterladen oder Protokolle auf einen Server hochladen.

So erstellen Sie mit PeriodicWorkRequest ein WorkRequest-Objekt, das regelmäßig ausgeführt wird:

Kotlin

val saveRequest =
       PeriodicWorkRequestBuilder<SaveImageToFileWorker>(1, TimeUnit.HOURS)
    // Additional configuration
           .build()

Java

PeriodicWorkRequest saveRequest =
       new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class, 1, TimeUnit.HOURS)
           // Constraints
           .build();

In diesem Beispiel ist die Arbeit mit einem Intervall von einer Stunde geplant.

Das Intervall ist die Mindestzeit zwischen den Wiederholungen. Der genaue Zeitpunkt, zu dem der Worker ausgeführt wird, hängt von den Einschränkungen ab, die Sie in Ihrem WorkRequest-Objekt verwenden, und von den Optimierungen, die vom System durchgeführt werden.

Hinweis :Das Mindestwiederholintervall beträgt 15 Minuten (wie bei der JobScheduler API).

Flexible Ausführungsintervalle

Wenn die Art Ihrer Arbeit ein genaues Ausführen erfordert, können Sie PeriodicWorkRequest so konfigurieren, dass es innerhalb eines Flex-Zeitraums in jedem Intervall ausgeführt wird, wie in Abbildung 1 dargestellt.

Abbildung 1. Das Diagramm zeigt Wiederholungsintervalle mit dem flexiblen Zeitraum, in dem die Arbeit ausgeführt werden kann.

Wenn Sie eine wiederkehrende Arbeit mit einem flexiblen Zeitraum definieren möchten, übergeben Sie beim Erstellen der PeriodicWorkRequest eine flexInterval zusammen mit der repeatInterval. Der flexible Zeitraum beginnt um repeatInterval - flexInterval und endet am Ende des Intervalls.

Im folgenden Beispiel wird eine wiederkehrende Aufgabe beschrieben, die in den letzten 15 Minuten jeder Stunde ausgeführt werden kann.

Kotlin

val myUploadWork = PeriodicWorkRequestBuilder<SaveImageToFileWorker>(
       1, TimeUnit.HOURS, // repeatInterval (the period cycle)
       15, TimeUnit.MINUTES) // flexInterval
    .build()

Java

WorkRequest saveRequest =
       new PeriodicWorkRequest.Builder(SaveImageToFileWorker.class,
               1, TimeUnit.HOURS,
               15, TimeUnit.MINUTES)
           .build();

Das Wiederholungsintervall muss größer oder gleich PeriodicWorkRequest.MIN_PERIODIC_INTERVAL_MILLIS und das flexible Intervall muss größer oder gleich PeriodicWorkRequest.MIN_PERIODIC_FLEX_MILLIS sein.

Auswirkungen von Beschränkungen auf regelmäßige Arbeit

Sie können Einschränkungen auf wiederkehrende Aufgaben anwenden. Sie können Ihrer Arbeitsanfrage beispielsweise eine Einschränkung hinzufügen, damit die Arbeit nur ausgeführt wird, wenn sich das Gerät des Nutzers gerade auflädt. In diesem Fall wird PeriodicWorkRequest erst ausgeführt, wenn diese Bedingung erfüllt ist, auch wenn das festgelegte Wiederholungsintervall verstrichen ist. Dies kann dazu führen, dass eine bestimmte Ausführung Ihrer Arbeit verzögert oder sogar übersprungen wird, wenn die Bedingungen nicht innerhalb des Ausführungsintervalls erfüllt werden.

Arbeitseinschränkungen

Mit Einschränkungen wird dafür gesorgt, dass die Arbeit verschoben wird, bis optimale Bedingungen vorliegen. Für WorkManager gelten die folgenden Einschränkungen:

Netzwerktyp	Beschränkt den Netzwerktyp, der für die Ausführung Ihrer Arbeit erforderlich ist. Beispiel: WLAN (UNMETERED).
Akkulaufzeit nicht niedrig	Ist sie auf „true“ gesetzt, wird die Arbeit bei niedrigem Akkustand des Geräts nicht ausgeführt.
RequiresCharging	Wenn diese Option auf „wahr“ gesetzt ist, wird Ihre Arbeit nur ausgeführt, wenn das Gerät geladen wird.
DeviceIdle	Wenn diese Option auf „True“ gesetzt ist, muss das Gerät des Nutzers inaktiv sein, bevor die Arbeit ausgeführt wird. Das kann nützlich sein, um Batch-Vorgänge auszuführen, die andernfalls negative Auswirkungen auf die Leistung anderer Apps haben könnten, die auf dem Gerät des Nutzers aktiv ausgeführt werden.
Speicher nicht niedrig	Wenn die Richtlinie auf „true“ gesetzt ist, wird Ihre Arbeit nicht ausgeführt, wenn der Speicherplatz des Nutzers auf dem Gerät zu gering ist.

Wenn Sie eine Reihe von Einschränkungen erstellen und mit einer Arbeit verknüpfen möchten, erstellen Sie eine Constraints-Instanz mithilfe der Contraints.Builder() und weisen Sie sie Ihrer WorkRequest.Builder() zu.

Mit dem folgenden Code wird beispielsweise eine Arbeitsanfrage erstellt, die nur ausgeführt wird, wenn sich das Gerät des Nutzers sowohl in der Ladestation befindet als auch mit dem WLAN verbunden ist:

Kotlin

val constraints = Constraints.Builder()
   .setRequiredNetworkType(NetworkType.UNMETERED)
   .setRequiresCharging(true)
   .build()

val myWorkRequest: WorkRequest =
   OneTimeWorkRequestBuilder<MyWork>()
       .setConstraints(constraints)
       .build()

Java

Constraints constraints = new Constraints.Builder()
       .setRequiredNetworkType(NetworkType.UNMETERED)
       .setRequiresCharging(true)
       .build();

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
               .setConstraints(constraints)
               .build();

Wenn mehrere Einschränkungen angegeben werden, wird Ihre Arbeit nur ausgeführt, wenn alle Einschränkungen erfüllt sind.

Wenn eine Einschränkung nicht erfüllt wird, während die Arbeit ausgeführt wird, beendet WorkManager den Worker. Die Arbeit wird dann wiederholt, wenn alle Einschränkungen erfüllt sind.

Verzögerte Arbeit

Wenn es für Ihre Arbeit keine Einschränkungen gibt oder wenn alle Einschränkungen erfüllt sind, wenn Ihre Arbeit in die Warteschlange eingereiht wird, kann das System die Arbeit sofort ausführen. Wenn die Arbeit nicht sofort ausgeführt werden soll, können Sie angeben, dass sie nach einer Mindestverzögerung gestartet werden soll.

Im Folgenden finden Sie ein Beispiel dafür, wie Sie Ihre Arbeit so einstellen können, dass sie mindestens 10 Minuten nach der Aufnahme in die Warteschlange ausgeführt wird.

Kotlin

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .setInitialDelay(10, TimeUnit.MINUTES)
   .build()

Java

WorkRequest myWorkRequest =
      new OneTimeWorkRequest.Builder(MyWork.class)
               .setInitialDelay(10, TimeUnit.MINUTES)
               .build();

Das Beispiel veranschaulicht, wie eine anfängliche Verzögerung für ein OneTimeWorkRequest festgelegt wird. Sie können aber auch eine anfängliche Verzögerung für eine PeriodicWorkRequest festlegen. In diesem Fall wird nur die erste Ausführung der regelmäßigen Aufgabe verzögert.

Hinweis :Der genaue Zeitpunkt, zu dem der Worker ausgeführt wird, hängt auch von den Einschränkungen ab, die in Ihrer Arbeitsanfrage verwendet werden, und von Systemoptimierungen. WorkManager wurde entwickelt, um unter diesen Einschränkungen das bestmögliche Verhalten zu erzielen.

Richtlinie für Wiederholungsversuche und Backoff

Wenn WorkManager Ihre Arbeit wiederholen soll, können Sie Result.retry() von Ihrem Worker zurückgeben. Ihre Arbeit wird dann gemäß einer Backoff-Verzögerung und einer Backoff-Richtlinie verschoben.

• Die Backoff-Verzögerung gibt die Mindestwartezeit an, bevor nach dem ersten Versuch ein neuer Versuch gestartet wird. Dieser Wert darf nicht unter 10 Sekunden (oder MIN_BACKOFF_MILLIS) liegen.

• Mit der Backoff-Richtlinie wird festgelegt, wie sich die Backoff-Verzögerung bei nachfolgenden Wiederholungsversuchen im Laufe der Zeit erhöhen soll. WorkManager unterstützt zwei Backoff-Richtlinien: LINEAR und EXPONENTIAL.

Jede Arbeitsanfrage hat eine Backoff-Richtlinie und eine Backoff-Verzögerung. Die Standardrichtlinie ist EXPONENTIAL mit einer Verzögerung von 30 Sekunden. Sie können dies jedoch in der Konfiguration Ihrer Arbeitsanfrage überschreiben.

Hier ist ein Beispiel für die Anpassung der Backoff-Verzögerung und der Richtlinie.

Kotlin

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .setBackoffCriteria(
       BackoffPolicy.LINEAR,
       OneTimeWorkRequest.MIN_BACKOFF_MILLIS,
       TimeUnit.MILLISECONDS)
   .build()

Java

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
               .setBackoffCriteria(
                       BackoffPolicy.LINEAR,
                       OneTimeWorkRequest.MIN_BACKOFF_MILLIS,
                       TimeUnit.MILLISECONDS)
               .build();

In diesem Beispiel ist die minimale Backoff-Verzögerung auf den zulässigen Mindestwert von 10 Sekunden festgelegt. Da die Richtlinie LINEAR ist, erhöht sich das Wiederholungsintervall mit jedem neuen Versuch um etwa 10 Sekunden. Wenn beispielsweise der erste Durchlauf mit Result.retry() endet, wird nach 10 Sekunden ein neuer Versuch unternommen, gefolgt von 20, 30, 40 Sekunden usw., wenn die Arbeit nach den nachfolgenden Versuchen weiterhin Result.retry() zurückgibt. Wenn die Backoff-Richtlinie auf EXPONENTIAL gesetzt wäre, läge die Abfolge der Wiederholungsdauer näher an 20, 40, 80 usw.

Hinweis: Backoff-Verzögerungen sind ungenau und können zwischen Wiederholungen um einige Sekunden variieren. Sie sind jedoch niemals kleiner als die in Ihrer Konfiguration angegebene anfängliche Backoff-Verzögerung.

Arbeit taggen

Jede Arbeitsanfrage hat eine eindeutige Kennung, mit der sie später identifiziert werden kann, um die Arbeit zu stornieren oder den Fortschritt zu beobachten.

Wenn Sie eine Gruppe logisch zusammenhängender Arbeiten haben, kann es auch hilfreich sein, diese Arbeitselemente zu taggen. Mithilfe von Tags können Sie mehrere Arbeitsanfragen gleichzeitig bearbeiten.

WorkManager.cancelAllWorkByTag(String) bricht beispielsweise alle Arbeitsanfragen mit einem bestimmten Tag ab und WorkManager.getWorkInfosByTag(String) gibt eine Liste der WorkInfo-Objekte zurück, mit der der aktuelle Arbeitsstatus ermittelt werden kann.

Der folgende Code zeigt, wie Sie Ihrer Arbeit das Tag „cleanup“ hinzufügen können:

Kotlin

val myWorkRequest = OneTimeWorkRequestBuilder<MyWork>()
   .addTag("cleanup")
   .build()

Java

WorkRequest myWorkRequest =
       new OneTimeWorkRequest.Builder(MyWork.class)
       .addTag("cleanup")
       .build();

Außerdem können einer einzelnen Arbeitsanfrage mehrere Tags hinzugefügt werden. Intern werden diese Tags als Strings gespeichert. Mit WorkInfo.getTags() können Sie die mit WorkRequest verknüpften Tags abrufen.

Aus Ihrer Worker-Klasse können Sie die zugehörigen Tags über ListenableWorker.getTags() abrufen.

Eingabedaten zuweisen

Für Ihre Arbeit sind möglicherweise Eingabedaten erforderlich. Bei der Verarbeitung des Uploads eines Bildes muss beispielsweise der URI des Bildes als Eingabe hochgeladen werden.

Eingabewerte werden als Schlüssel/Wert-Paare in einem Data-Objekt gespeichert und können für die Arbeitsanfrage festgelegt werden. WorkManager liefert die Eingabe-Data an Ihre Arbeit, wenn die Arbeit ausgeführt wird. Die Klasse Worker kann über den Aufruf von Worker.getInputData() auf die Eingabeargumente zugreifen. Im folgenden Code wird gezeigt, wie Sie eine Worker-Instanz erstellen, für die Eingabedaten erforderlich sind, und wie Sie sie in Ihrer Arbeitsanfrage senden.

Kotlin

// Define the Worker requiring input
class UploadWork(appContext: Context, workerParams: WorkerParameters)
   : Worker(appContext, workerParams) {

   override fun doWork(): Result {
       val imageUriInput =
           inputData.getString("IMAGE_URI") ?: return Result.failure()

       uploadFile(imageUriInput)
       return Result.success()
   }
   ...
}

// Create a WorkRequest for your Worker and sending it input
val myUploadWork = OneTimeWorkRequestBuilder<UploadWork>()
   .setInputData(workDataOf(
       "IMAGE_URI" to "http://..."
   ))
   .build()

Java

// Define the Worker requiring input
public class UploadWork extends Worker {

   public UploadWork(Context appContext, WorkerParameters workerParams) {
       super(appContext, workerParams);
   }

   @NonNull
   @Override
   public Result doWork() {
       String imageUriInput = getInputData().getString("IMAGE_URI");
       if(imageUriInput == null) {
           return Result.failure();
       }

       uploadFile(imageUriInput);
       return Result.success();
   }
   ...
}

// Create a WorkRequest for your Worker and sending it input
WorkRequest myUploadWork =
      new OneTimeWorkRequest.Builder(UploadWork.class)
           .setInputData(
               new Data.Builder()
                   .putString("IMAGE_URI", "http://...")
                   .build()
           )
           .build();

Auf ähnliche Weise kann die Klasse Data verwendet werden, um einen Rückgabewert auszugeben. Ein- und Ausgabedaten werden im Abschnitt Eingabeparameter und zurückgegebene Werte ausführlicher behandelt.

Nächste Schritte

Auf der Seite Zustände und Beobachtung erfahren Sie mehr über den Arbeitsstatus und darüber, wie Sie den Fortschritt Ihrer Arbeit überwachen können.