Aufgaben verwalten

Sobald Sie Ihre Worker und Ihr WorkRequest, besteht der letzte Schritt darin, Ihre Arbeit in die Warteschlange zu stellen. Die einfachste Möglichkeit, Arbeit in die Warteschlange zu stellen Rufen Sie die WorkManager-Methode enqueue() auf und übergeben Sie die WorkRequest, die Sie ausführen möchten.

val myWork: WorkRequest = // ... OneTime or PeriodicWork
WorkManager.getInstance(requireContext()).enqueue(myWork)

WorkRequest myWork = // ... OneTime or PeriodicWork
WorkManager.getInstance(requireContext()).enqueue(myWork);

Seien Sie vorsichtig, wenn Sie Aufgaben in die Warteschlange stellen, um Duplikate zu vermeiden. Eine App könnte z. B. versuchen, ihre Logs alle 24 Stunden an einen Back-End-Dienst gesendet. Wenn Sie nicht vorsichtig sind, dieselbe Aufgabe mehrmals in eine Warteschlange stellen, obwohl der Job nur einmal ausführen. Um dieses Ziel zu erreichen, können Sie die Arbeiten als Einzelarbeit planen.

Einzigartige Arbeit

Einzigartige Arbeit ist ein leistungsstarkes Konzept, das garantiert, Arbeitsinstanz mit einem bestimmten name gleichzeitig. Im Gegensatz zu IDs können eindeutige Namen sind visuell lesbar und werden nicht automatisch generiert, sondern vom Entwickler festgelegt. von WorkManager. „Mag ich“-Bewertung entfernen tags, eindeutig Namen nur mit einer einzigen Arbeitsinstanz verknüpft sind.

Einzigartige Arbeit kann sowohl auf einmalige als auch auf regelmäßige Arbeit angewendet werden. Sie können ein durch Aufrufen einer dieser Methoden, je nachdem, Sie wiederkehrende oder einmalige Arbeiten planen.

• WorkManager.enqueueUniqueWork() für einmalige Aufgaben
• WorkManager.enqueueUniquePeriodicWork() für regelmäßige Aufgaben

Beide Methoden akzeptieren drei Argumente:

• uniqueWorkName: Ein String, das zur eindeutigen Identifizierung des Werks verwendet wird.
• existingWorkPolicy: Ein enum, das WorkManager mitteilt, was zu tun ist. wenn es bereits eine unvollendete Verkettung mit diesem eindeutigen Namen gibt. Weitere Informationen finden Sie unter Richtlinie zur Konfliktlösung.
• work: die zu planenden WorkRequest.

Mithilfe von besonderer Arbeit können wir das zuvor erwähnte Problem mit der doppelten Planung beheben.

val sendLogsWorkRequest =
       PeriodicWorkRequestBuilderS<endLogsWorker(>24, TimeUnit.HOURS)
           .setConstraints(Constraints.Builder()
               .setRequiresCharging(true)
               .build()
            )
           .build()
WorkManager.getInstance(this).enqueueUniquePeriodicWork(
           "sendLogs",
           ExistingPeriodicWorkPolicy.KEEP,
           sendLogsWorkRequest
)

PeriodicWorkRequest sendLogsWorkRequest = new
      PeriodicWorkRequest.Builder(SendLogsWorker.class, 24, TimeUnit.HOURS)
              .setConstraints(new Constraints.Builder()
              .setRequiresCharging(true)
          .build()
      )
     .build();
WorkManager.getInstance(this).enqueueUniquePeriodicWork(
     "sendLogs",
     ExistingPeriodicWorkPolicy.KEEP,
     sendLogsWorkRequest);

Wenn der Code ausgeführt wird, während sich ein sendLogs-Job bereits in der Warteschlange befindet, werden die vorhandenen beibehalten und es wird kein neuer Job hinzugefügt.

Individuelle Arbeitsabläufe können auch nützlich sein, wenn Sie nach und nach eine einer langen Aufgabenkette. Beispielsweise können Nutzer mit einer App zur Fotobearbeitung einer langen Handlungskette. Jeder dieser rückgängig gemachten Vorgänge kann eine Weile dauern, in der richtigen Reihenfolge durchgeführt werden müssen. In diesem Fall könnte die App "Rückgängig machen" erstellen und fügen Sie jeden Rückgängig-Vorgang nach Bedarf an die Kette an. Siehe Kettenarbeit .

Richtlinie zur Konfliktlösung

Bei der Planung einzelner Arbeiten müssen Sie WorkManager mitteilen, welche Aktion wann ausgeführt werden soll. gibt es einen Konflikt. Dazu übergeben Sie eine Aufzählung, wenn Sie die Arbeit in die Warteschlange stellen.

Für einmalige Arbeiten geben Sie eine ExistingWorkPolicy, die unterstützt vier Optionen zur Behebung des Konflikts.

• REPLACE vorhanden mit dem neuen Werk arbeiten. Mit dieser Option werden vorhandene Änderungen abgebrochen.
• KEEP bestehende Arbeit und die neue Arbeit ignorieren.
• APPEND die neue Arbeit das Ende der bestehenden Arbeit. Durch diese Richtlinie wird Ihr neues Werk verkettet mit dem vorhandener Arbeit, die ausgeführt wird, nachdem die vorhandene Arbeit abgeschlossen ist.

Das vorhandene Werk wird zur Voraussetzung für das neue Werk. Wenn die bestehenden Arbeiten zu CANCELLED oder FAILED wird, ist das neue Werk auch CANCELLED oder FAILED. Wenn Sie die neue Arbeit unabhängig vom Status der vorhandenen Arbeit ausführen möchten, Verwende stattdessen APPEND_OR_REPLACE.

• APPEND_OR_REPLACE funktioniert ähnlich wie APPEND, mit dem Unterschied, dass sie nicht von Voraussetzung des Arbeitsstatus. Wenn die vorhandene Arbeit CANCELLED oder FAILED, die neue Arbeit wird noch ausgeführt.

Bei Periodenarbeiten müssen Sie ExistingPeriodicWorkPolicy, die zwei Optionen unterstützt: REPLACE und KEEP. Diese Optionen funktionieren gleich wie ihre vorhandenen WorkPolicy-Entsprechungen.

Ihre Arbeit beobachten

Nachdem Sie Aufgaben in die Warteschlange eingereiht haben, können Sie deren Status jederzeit prüfen, indem Sie WorkManager durch name, id oder eine mit ihm verknüpfte tag.

// by id
workManager.getWorkInfoById(syncWorker.id) // ListenableFutureW<orkInfo<>/span>

// by name
workManager.getWorkInfosForUniqueWork("sync") // ListenableFutureL<istW<orkInfo<>/span>
>
// by tag
workManager.getWorkInfosByTag("syncTag") // ListenableFutureL<istW<orkInfo<>/span>
>

// by id
workManager.getWorkInfoById(syncWorker.id); // ListenableFutureW<orkInfo<>/span>

// by name
workManager.getWorkInfosForUniqueWork("sync"); // ListenableFutureL<istW<orkInfo<>/span>
>
// by tag
workManager.getWorkInfosByTag("syncTag"); // ListenableFutureL<istW<orkInfo<>/span>
>

Die Abfrage gibt eine ListenableFuture eines WorkInfo-Objekts, das den id des Werks, seiner Tags, seiner aktuelle State und Ausgabedaten festlegen über Result.success(outputData).

Eine LiveData-Variante von jedem der können Sie Änderungen am WorkInfo beobachten, indem Sie zu hören. Wenn Sie z. B. eine Nachricht für den Nutzer anzeigen möchten, wenn er abgeschlossen wurden, können Sie das Programm folgendermaßen einrichten:

workManager.getWorkInfoByIdLiveData(syncWorker.id)
               .observe(viewLifecycleOwner) { workInfo -
>   if(workInfo?.state == WorkInfo.State.SUCCEEDED) {
       Snackbar.make(requireView(), 
      R.string.work_completed, Snackbar.LENGTH_SHORT)
           .show()
   }
}

workManager.getWorkInfoByIdLiveData(syncWorker.id)
        .observe(getViewLifecycleOwner(), workInfo - >{
    if (workInfo.getState() != null 
&&            workInfo.getState() == WorkInfo.State.SUCCEEDED) {
        Snackbar.make(requireView(),
                    R.string.work_completed, Snackbar.LENGTH_SHORT)
                .show();
   }
});

Komplexe Arbeitsabfragen

WorkManager 2.4.0 und höher unterstützt komplexe Abfragen für Jobs in der Warteschlange mit WorkQuery-Objekte. WorkQuery unterstützt Abfragen nach Arbeit durch eine Kombination der Tags, des Status und des eindeutigen Arbeitsnamens

Das folgende Beispiel zeigt, wie Sie alle Arbeiten mit dem Tag “syncTag” finden, mit dem Status FAILED oder CANCELLED und dem eindeutigen Arbeitsnamen: entweder preProcess oder sync.

val workQuery = WorkQuery.Builder
       .fromTags(listOf("syncTag"))
       .addStates(listOf(WorkInfo.State.FAILED, WorkInfo.State.CANCELLED))
       .addUniqueWorkNames(listOf("preProcess", "sync")
    )
   .build()

val workInfos: ListenableFutureL<istW<orkInfo >>= workManager.getWorkInfos(workQuery)

WorkQuery workQuery = WorkQuery.Builder
       .fromTags(Arrays.asList("syncTag"))
       .addStates(Arrays.asList(WorkInfo.State.FAILED, WorkInfo.State.CANCELLED))
       .addUniqueWorkNames(Arrays.asList("preProcess", "sync")
     )
    .build();

ListenableFutureL<istW<orkInfo >>workInfos = workManager.getWorkInfos(workQuery);

Jede Komponente (Tag, Status oder Name) in einer WorkQuery ist mit dem Parameter AND andere. Jeder Wert in einer Komponente ist mit OR verknüpft. Beispiel: (name1 OR name2 OR ...) AND (tag1 OR tag2 OR ...) AND (state1 OR state2 OR ...).

WorkQuery funktioniert auch mit dem LiveData-Äquivalent, getWorkInfosLiveData()

Arbeit abbrechen und beenden

Wenn Sie Ihre zuvor in die Warteschlange eingereihten Arbeiten nicht mehr benötigen, können Sie sie anfordern. storniert werden. Arbeiten können über die name, die id oder die tag storniert werden die damit verknüpft sind.

// by id
workManager.cancelWorkById(syncWorker.id)

// by name
workManager.cancelUniqueWork("sync")

// by tag
workManager.cancelAllWorkByTag("syncTag")

// by id
workManager.cancelWorkById(syncWorker.id);

// by name
workManager.cancelUniqueWork("sync");

// by tag
workManager.cancelAllWorkByTag("syncTag");

Im Hintergrund prüft WorkManager die State der Arbeit. Wenn die Arbeit bereits abgeschlossen haben, passiert nichts. Andernfalls ändert sich der Status des Werks in CANCELLED und die Arbeit wird künftig nicht mehr ausgeführt. Beliebig WorkRequest Jobs, die abhängig sind auch CANCELLED sein.

Derzeit arbeiten RUNNING erhält einen Anruf bei ListenableWorker.onStopped() Überschreiben Sie diese Methode, um potenzielle Bereinigungen abzuwickeln. Weitere Informationen finden Sie unter Ausführen von Workern finden Sie weitere Informationen.

Laufenden Worker beenden

Es gibt verschiedene Gründe, warum Worker von WorkManager beendet werden kann:

• Sie haben die Stornierung ausdrücklich angefordert, indem Sie WorkManager.cancelWorkById(UUID).
• Bei eindeutigen Arbeiten: Sie haben explizit eine neue WorkRequest mit einem ExistingWorkPolicy von REPLACE Die alte WorkRequest gilt sofort als storniert.
• Die Beschränkungen für Ihre Arbeit werden nicht mehr erfüllt.
• Das System hat deine App angewiesen, die Arbeit aus irgendeinem Grund einzustellen. Dies kann wenn Sie die Frist von 10 Minuten überschreiten. Die Arbeit ist zu einem späteren Zeitpunkt erneut zu versuchen.

Unter diesen Bedingungen wird Ihr Worker beendet.

Sie sollten alle laufenden Arbeiten gemeinsam abbrechen und Ressourcen, die Ihr Worker gespeichert hat. Sie sollten beispielsweise offene Handles an Datenbanken und Dateien. Es gibt zwei Mechanismen auf Ihrer um zu erfahren, wann Ihr Worker beendet wird.

onStopped()-Callback

WorkManager-Aufrufe ListenableWorker.onStopped() sobald Ihr Worker beendet wurde. Zum Schließen diese Methode überschreiben auf alle Ressourcen, die Sie zur Hand haben.

Eigenschaft isStopped()

Sie können die Methode Methode ListenableWorker.isStopped(), um zu prüfen, ob der Worker bereits beendet wurde. Wenn Sie lang andauernde oder sich wiederholende Vorgänge in Ihrem Worker ausführen, Überprüfen Sie diese Eigenschaft regelmäßig und verwenden Sie sie als Signal dafür, dass die Arbeit so schnell wie möglich eingestellt werden kann. wie möglich.

Hinweis:WorkManager ignoriert den Parameter Result wird von einem Worker festgelegt das das onStop-Signal erhalten hat, da der Worker bereits angehalten.