Arbeitsanfragen definieren

Im Startleitfaden wurde erläutert, wie Sie ein einfaches WorkRequest erstellen und in die Warteschlange stellen.

In diesem Leitfaden erfahren Sie, wie Sie WorkRequest-Objekte für häufige Anwendungsfälle definieren und anpassen, z. B. für:

• 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 der Arbeit garantieren
• Wiederholungs- und Backoff-Strategien festlegen
• Eingabedaten übergeben
• Zusammengehörige Arbeiten mithilfe von Tags gruppieren

Übersicht

Die Arbeit wird im WorkManager über ein WorkRequest definiert. Wenn Sie Arbeiten mit WorkManager planen möchten, müssen Sie zuerst ein WorkRequest-Objekt erstellen und es dann in die Warteschlange stellen.

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. Dazu gehören Einschränkungen, die erfüllt sein müssen, damit Ihre Arbeit ausgeführt werden kann, Planungsinformationen wie Verzögerungen oder Wiederholungsintervalle, Wiederholungskonfigurationen und kann Eingabedaten enthalten, wenn Ihre Arbeit davon abhängt.

WorkRequest selbst ist eine abstrakte Basisklasse. Es gibt zwei abgeleitete Implementierungen dieser Klasse, die Sie zum Erstellen der Anfrage verwenden können: OneTimeWorkRequest und PeriodicWorkRequest. Wie die Namen andeuten, ist OneTimeWorkRequest nützlich für die Planung von sich nicht wiederholenden Arbeiten, während PeriodicWorkRequest eher für die Planung von Arbeiten geeignet ist, die sich in bestimmten Intervallen wiederholen.

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. Auf diese Weise kann WorkManager wichtige Arbeiten ausführen und gleichzeitig dem System eine bessere Kontrolle über den Zugriff auf Ressourcen geben.

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 das beschleunigte Arbeiten aus.
• Latenz: Das System führt sofort beschleunigte Arbeiten aus, sofern die aktuelle Arbeitslast des Systems dies ermöglicht. Das bedeutet, dass sie latenzempfindlich sind und nicht für eine spätere Ausführung geplant werden können.

Ein möglicher Anwendungsfall für beschleunigte Arbeiten könnte in einer Chat-App sein, wenn der Nutzer eine Nachricht oder ein angehängtes Bild senden möchte. Ebenso kann eine App, die einen Zahlungs- oder Abovorgang abwickelt, möglicherweise auch beschleunigte Arbeiten verwenden. Dies liegt daran, dass diese Aufgaben für den Nutzer wichtig sind, schnell im Hintergrund ausgeführt werden, sofort beginnen müssen und auch dann weiter ausgeführt 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. Vielmehr erhält jede Anwendung ein Kontingent für die Ausführungszeit. Wenn die Ausführungszeit Ihrer Anwendung verbraucht ist und das zugewiesene Kontingent erreicht ist, können Sie erst nach der Aktualisierung des Kontingents beschleunigte Arbeiten ausführen. Dadurch kann Android Ressourcen effektiver zwischen Anwendungen verteilen.

Die für eine Anwendung verfügbare Ausführungszeit hängt vom Stand-by-Bucket und der Prozesswichtigkeit ab.

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

Hinweis: Während die Anwendung im Vordergrund ausgeführt wird, beschränken Kontingente die Ausführung von beschleunigten Aufgaben nicht. Ein Ausführungszeitkontingent gilt nur, wenn Ihre Anwendung im Hintergrund ausgeführt 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 zu deklarieren, dass ein WorkRequest so schnell wie möglich mit einem Express-Job 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 ausgeschöpft ist, gibt der Parameter OutOfQuotaPolicy an, dass die Anfrage als normale, nicht beschleunigte Arbeit ausgeführt werden soll.

Abwärtskompatibilität und Dienste im Vordergrund

Um die Abwärtskompatibilität für beschleunigte Jobs aufrechtzuerhalten, kann WorkManager einen Dienst im Vordergrund auf Plattformversionen ausführen, die älter als Android 12 sind. Dienste im Vordergrund können dem Nutzer eine Benachrichtigung anzeigen.

Mit den Methoden getForegroundInfoAsync() und getForegroundInfo() in Ihrem Worker kann WorkManager eine Benachrichtigung anzeigen, wenn Sie setExpedited() vor Android 12 aufrufen.

Jeder 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 und eine Ausnahme auslösen, wenn der Start eingeschränkt war.

Mitarbeiter

Beschäftigte wissen nicht, ob ihre Arbeit beschleunigt wird oder nicht. Worker können unter einigen Android-Versionen jedoch eine Benachrichtigung anzeigen, wenn ein 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-Objekts für dich anzeigen kann.

Mitarbeiter

Wenn Sie CoroutineWorker verwenden, müssen Sie getForegroundInfo() implementieren. Sie übergeben sie dann an setForeground() innerhalb von doWork(). Dadurch wird die Benachrichtigung in älteren Android-Versionen als 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 einen try/catch-Block umschließen, um einen potenziellen IllegalStateException abzufangen. Das kann passieren, wenn deine 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 steuern, was mit beschleunigten Abläufen geschieht, wenn Ihre Anwendung das Ausführungskontingent erreicht hat. Um fortzufahren, müssen Sie setExpedited() übergeben:

• OutOfQuotaPolicy.RUN_AS_NON_EXPEDITED_WORK_REQUEST: Legt fest, dass der Job als normale Arbeitsanfrage ausgeführt wird. Das oben gezeigte 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.

Aufgeschobene Schnellarbeiten

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. Dies kann auftreten, wenn bereits zu viele Jobs ausgeführt werden oder das System nicht über genügend Arbeitsspeicher verfügt.
• Kontingent: Das Limit für das beschleunigte Jobkontingent wurde überschritten. Für die beschleunigte Arbeit 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 Arbeit sind strenger als die für andere Arten von Hintergrundjobs.

Regelmäßige Arbeiten 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 werden die Arbeiten mit einem Intervall von einer Stunde geplant.

Der Intervallzeitraum ist definiert als die minimale Zeit zwischen den Wiederholungen. Die genaue Zeit für die Ausführung des Workers hängt von den Einschränkungen ab, die Sie in Ihrem WorkRequest-Objekt verwenden, und von den vom System durchgeführten Optimierungen.

Hinweis: Das Mindestwiederholungsintervall, das definiert werden kann, beträgt 15 Minuten (wie bei der JobScheduler API).

Flexible Ausführungsintervalle

Wenn es aufgrund der Art Ihrer Arbeit schwierig ist, den Zeitplan für die Ausführung festzulegen, können Sie die PeriodicWorkRequest so konfigurieren, dass sie innerhalb jedes Intervallzeitraums innerhalb eines flexiblen Zeitraums 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.

Um regelmäßige Arbeit mit einem flexiblen Zeitraum zu definieren, übergeben Sie beim Erstellen von PeriodicWorkRequest ein flexInterval zusammen mit dem repeatInterval. Der flexible Zeitraum beginnt um repeatInterval - flexInterval und endet am Ende des Intervalls.

Im Folgenden finden Sie ein Beispiel für regelmäßige Arbeit, 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 periodische Arbeiten anwenden. Sie können Ihre Arbeitsanfrage beispielsweise so einschränken, dass die Arbeit nur dann ausgeführt wird, wenn das Gerät des Nutzers aufgeladen wird. Selbst wenn das festgelegte Wiederholungsintervall erfolgreich ist, wird PeriodicWorkRequest in diesem Fall erst ausgeführt, wenn diese Bedingung erfüllt ist. Dies kann dazu führen, dass eine bestimmte Ausführung Ihrer Arbeit verzögert wird oder sogar übersprungen wird, wenn die Bedingungen innerhalb des Ausführungsintervalls nicht erfüllt werden.

Arbeitsbeschränkungen

Einschränkungen stellen sicher, dass die Arbeit verzögert wird, bis optimale Bedingungen erfüllt sind. Die folgenden Einschränkungen sind für WorkManager verfügbar.

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 nicht ausgeführt, wenn der Akku des Geräts schwach ist.
Erfordert Aufladen	Ist sie auf „true“ gesetzt, wird die Arbeit nur dann ausgeführt, wenn das Gerät geladen wird.
DeviceIdle	Ist sie auf „true“ gesetzt, muss das Gerät des Nutzers inaktiv sein, damit die Arbeit ausgeführt werden kann. Dies kann nützlich sein, wenn Sie Batch-Vorgänge ausführen, die sich andernfalls negativ auf die Leistung anderer Apps auswirken könnten, die auf dem Gerät des Nutzers ausgeführt werden.
Speicher nicht niedrig	Ist sie auf „true“ gesetzt, 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 Arbeit verknüpfen möchten, erstellen Sie mit Contraints.Builder() eine Constraints-Instanz und weisen Sie sie der WorkRequest.Builder() zu.

Mit dem folgenden Code wird beispielsweise eine Arbeitsanfrage erstellt, die nur ausgeführt wird, wenn das Gerät des Nutzers sowohl geladen wird als auch mit 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 sind, wird Ihre Arbeit nur ausgeführt, wenn alle Einschränkungen erfüllt sind.

Falls eine Einschränkung nicht erfüllt wird, während Ihre Arbeit ausgeführt wird, stoppt WorkManager Ihren Worker. Die Arbeit wird noch einmal ausgeführt, 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 Sie nicht möchten, dass die Arbeit sofort ausgeführt wird, können Sie festlegen, dass die Arbeit nach einer minimalen anfänglichen Verzögerung gestartet wird.

Im Folgenden finden Sie ein Beispiel dafür, wie Sie Ihre Arbeit so einstellen können, dass sie mindestens 10 Minuten nach der Einreihung 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 eine OneTimeWorkRequest festgelegt wird. Sie können aber auch eine anfängliche Verzögerung für eine PeriodicWorkRequest festlegen. In diesem Fall würde nur die erste Ausführung Ihrer regelmäßigen Arbeit verzögert werden.

Hinweis: Die genaue Zeit, zu der der Worker ausgeführt wird, hängt auch von den Einschränkungen ab, die in Ihrer Arbeitsanfrage und von Systemoptimierungen verwendet werden. WorkManager ist darauf ausgelegt, unter diesen Einschränkungen das bestmögliche Verhalten zu erzielen.

Wiederholungs- und Backoff-Richtlinie

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 kann nicht kleiner als 10 Sekunden (oder MIN_BACKOFF_MILLIS) sein.

• Die Backoff-Richtlinie definiert, wie die Backoff-Verzögerung für nachfolgende Wiederholungsversuche im Laufe der Zeit erhöht werden soll. WorkManager unterstützt die beiden 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 minimal zulässigen Wert von 10 Sekunden festgelegt. Da die Richtlinie auf LINEAR gesetzt ist, verlängert sich das Wiederholungsintervall bei jedem neuen Versuch um ca. 10 Sekunden. Beispielsweise wird nach 10 Sekunden der erste Ausführungsversuch mit Result.retry() noch einmal versucht, gefolgt von 20, 30, 40 usw., wenn nach weiteren Versuchen weiterhin Result.retry() zurückgegeben wird. 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 den Wiederholungen um einige Sekunden variieren. Sie sind jedoch niemals kleiner als die in Ihrer Konfiguration angegebene anfängliche Backoff-Verzögerung.

Tag-Arbeit

Jede Arbeitsanfrage hat eine eindeutige Kennung, mit der sich die jeweilige Arbeit später identifizieren lässt. So können sie abgebrochen oder den Fortschritt beobachtet werden.

Wenn Sie eine Gruppe logisch zusammenhängender Arbeiten haben, kann es auch hilfreich sein, diese Arbeitselemente zu taggen. Mit Tag-Kennzeichnung können Sie eine Gruppe von Arbeitsanfragen gemeinsam bearbeiten.

Beispielsweise bricht WorkManager.cancelAllWorkByTag(String) 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();

Schließlich können einer einzelnen Arbeitsanfrage mehrere Tags hinzugefügt werden. Intern werden diese Tags als eine Reihe von 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

Möglicherweise sind für Ihre Arbeit Eingabedaten erforderlich. Beispielsweise kann es für Arbeit, die das Hochladen eines Bildes verarbeitet, den URI des Bildes als Eingabe hochladen müssen.

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 durch Aufrufen von Worker.getInputData() auf die Eingabeargumente zugreifen. Der folgende Code zeigt, wie Sie eine Worker-Instanz erstellen, für die Eingabedaten erforderlich sind, und wie Sie diese 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. Eingabe- 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.