WorkManager — qu'est-ce que c'est, API et planification de tâches

Comment fonctionne WorkManager ?

L'architecture de WorkManager est construite autour de trois classes de base : Worker, WorkRequest et WorkManager. Worker contient la logique de la tâche, WorkRequest décrit les paramètres d'exécution et WorkManager gère la file d'attente et la planification. La bibliothèque utilise une base de données Room interne pour stocker l'état de toutes les tâches.

Worker et WorkRequest

Worker est une classe abstraite avec une seule méthode doWork qui est appelée sur un thread d'arrière-plan. La méthode renvoie ListenableWorker.Result — SUCCESS, FAILURE ou RETRY. WorkRequest lie le Worker avec les paramètres : délai d'attente, tag, délai initial et contraintes.

class SyncWorker(
    context: Context,
    params: WorkerParameters
) : Worker(context, params) {

    override fun doWork(): Result {
        return try {
            val api = RetrofitClient.api
            val response = api.syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

Planification via WorkManager

WorkManager planifie les tâches de manière uniforme, quelle que soit la version d'Android. Lors de l'appel de enqueue, la bibliothèque enregistre la tâche dans Room, évalue les conditions actuelles et sélectionne le moment d'exécution optimal. En interne, il peut utiliser JobScheduler, AlarmManager ou son propre planificateur — le développeur n'a pas à s'en soucier.

val syncRequest = OneTimeWorkRequestBuilder<SyncWorker>()
    .setInitialDelay(15, TimeUnit.MINUTES)
    .addTag("sync")
    .build()

WorkManager.getInstance(context)
    .enqueue(syncRequest)

Types de WorkRequest

WorkManager prend en charge deux types de demandes d'exécution : uniques et périodiques. Le choix du type dépend du scénario : la tâche doit s'exécuter une fois ou se répéter à un intervalle donné.

OneTimeWorkRequest

OneTimeWorkRequest est conçu pour les tâches qui doivent s'exécuter une seule fois. Il peut s'agir de l'envoi d'un journal, de la synchronisation des données après autorisation, du téléchargement de la configuration au premier démarrage. Le délai est défini via setInitialDelay et les contraintes via setConstraints.

PeriodicWorkRequest

PeriodicWorkRequest convient aux tâches répétitives avec un intervalle minimum de 15 minutes. La bibliothèque garantit que l'intervalle entre les exécutions ne sera pas inférieur à celui spécifié, mais peut être plus long en raison des contraintes de l'appareil. Pour les tâches avec une fréquence inférieure à 15 minutes, utilisez Handler ou Timer dans Foreground Service.

Configuration des contraintes et chaînes de tâches

Les contraintes dans WorkManager permettent de définir les conditions dans lesquelles une tâche peut être lancée : connexion réseau (NetworkType), niveau de batterie (batteryNotLow), état du stockage (StorageNotLow) et mode veille (DeviceIdle). La tâche ne démarrera pas tant que toutes les contraintes ne seront pas satisfaites.

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

val request = OneTimeWorkRequestBuilder<ImageUploadWorker>()
    .setConstraints(constraints)
    .build()

Les chaînes permettent d'organiser l'exécution séquentielle ou parallèle des tâches. beginWith démarre une chaîne, puis ajoute le Worker suivant qui s'exécutera après la réussite du précédent. Pour l'exécution parallèle, utilisez workManager.enqueue(listOf(request1, request2)).

WorkManager.getInstance(context)
    .beginWith(compressWorker)
    .then(uploadWorker)
    .then(cleanupWorker)
    .enqueue()
    // compress -> upload -> cleanup séquentiellement

Migration de JobScheduler vers WorkManager

JobScheduler a été introduit dans Android 5 (API 21) en tant que service système pour planifier les tâches en arrière-plan. WorkManager est venu le remplacer, offrant une API multiplateforme avec migration automatique et des capacités supplémentaires : chaînes, garantie d'exécution, tags, observation d'état via LiveData.

Lors de la migration de JobScheduler vers WorkManager, vous devrez convertir JobService en Worker, remplacer JobInfo par WorkRequest et Context.getSystemService par l'API WorkManager. WorkManager gère automatiquement les problèmes de compatibilité et traite le Mode Doze plus correctement qu'une implémentation manuelle de JobScheduler. Étapes de migration : 1) créer une classe Worker, 2) construire un WorkRequest avec les mêmes conditions, 3) supprimer JobService et JobInfo du code et du manifeste.

UniqueWork pour les tâches uniques

WorkManager prend en charge le concept de tâches uniques via ExistingWorkPolicy. Si une tâche avec le nom spécifié existe déjà, la politique détermine le comportement : KEEP (ne pas en créer une nouvelle), REPLACE (remplacer l'existante), APPEND (ajouter à la fin de la chaîne) et APPEND_OR_REPLACE. UniqueWorkRequest est pratique pour les tâches qui ne doivent pas être dupliquées : synchronisation de base de données, téléchargement de configuration, envoi de lot d'analyses.

WorkManager.getInstance(context)
    .enqueueUniqueWork(
        "sync_data",
        ExistingWorkPolicy.KEEP,
        syncRequest
    )

Gestion de la progression et des résultats intermédiaires

CoroutineWorker prend en charge le mécanisme setProgress, permettant de transmettre des résultats d'exécution intermédiaires. Ceci est utile pour les opérations longues : téléchargement de fichier volumineux, traitement par lot d'images, migration de base de données. L'interface utilisateur peut s'abonner aux mises à jour via getWorkInfosByTagLiveData et afficher la progression en temps réel. La méthode ForegroundInfo est également disponible pour exécuter un Worker en tant que Foreground Service avec une notification si la tâche doit être visible pour l'utilisateur.

class ProgressWorker(
    context: Context,
    params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        val total = 100
        for (i in 1..total) {
            setProgress(
                workDataOf("progress" to i)
            )
        }
        return Result.success()
    }
}

InputData et OutputData pour le transfert de données

WorkManager prend en charge le transfert de données entre Workers via InputData et OutputData. InputData est créé lors de la construction de WorkRequest via Data.Builder et est passé au Worker via inputData. Après l'exécution, le Worker crée OutputData via workDataOf ou Data.Builder et le renvoie avec Result.success(outputData). Le Worker suivant dans la chaîne reçoit l'outputData du précédent comme son inputData. Les données sont stockées au format clé-valeur avec prise en charge des types de base : String, Int, Long, Boolean, Double. La taille maximale de Data est de 10 Ko.

Dans la pratique, de nombreux projets utilisent WorkManager comme unique planificateur de tâches en arrière-plan. Google recommande de migrer tous les JobService existants vers WorkManager, en particulier dans les applications prenant en charge Android 4.4 (API 19) et inférieur, où JobScheduler n'est pas disponible et WorkManager utilise un mécanisme de secours via AlarmManager et BroadcastReceiver. Pour les tests, WorkManager fournit TestListenableWorkerBuilder et TestWorkerBuilder, qui permettent de tester les Workers dans des tests JUnit sans planificateur réel.