Extension d’Android WorkManager pour les tâches périodiques dépendantes

Le défi

Étant donné que nous avons résolu d’utiliser une demande de travail périodique, comment pouvons-nous alors garantir une certaine forme d’ordre pour la relation parent-enfant qui existe entre le La personne et Bénéficiaire entités?

Autrement dit, comment pouvons-nous nous assurer que le La personnel’entité (parent) est poussée vers la télécommande avant Bénéficiairel’entité (enfant) est poussée.

Ceci est nécessaire car l’API du backend distant requiert qu’un bénéficiaire soit créé avec le distant id de l’entité Personne.

Ce qui précède représente un défi de taille car les demandes de travail périodiques ne peuvent pas être enchaînées. Pour résoudre ce problème, nous devons disposer d’un moyen pour garantir que l’ordre de priorité tel qu’expliqué dans le paragraphe précédent est respecté.

La solution proposée

Pour résoudre ce problème, nous prendrons les mesures suivantes:

1. Créer un résumé Ouvrier Contrat classe qui s’étend Travailleur Android et définit nos règles personnalisées.
2. Créez des classes de travailleurs pour la personne et le bénéficiaire qui s’étendent à partir de la classe de contrat de travailleur définie à l’étape 1.
3. Créez des demandes de travail périodiques à l’aide des classes de travailleurs créées à l’étape 2.

Plongeons-nous dans les détails de chaque étape.

Étape 1: créer un contrat de travail

Il s’agit d’une classe abstraite qui définit les règles de transmission des données stockées localement vers la source de données distante. Le contrat indique les différentes conditions qui doivent être remplies avant qu’une entité puisse être poussée vers la télécommande. La classe s’étend Android Worker et remplace le doWork() méthode dans laquelle les règles et l’ordre d’exécution des tâches périodiques sont définis comme on peut le voir dans l’extrait de code ci-dessous. Il contient également diverses méthodes, comme expliqué avec les commentaires affichés dans l’extrait de code ci-dessous:

Le WorkerContract est le «moteur» de cette solution, car il rassemble toutes les pièces et garantit que l’ordre de priorité requis est strictement respecté.

Selon votre scénario, vos règles contractuelles peuvent être différentes.

Étape 2: créer des classes de travailleurs

Le contrat de travail étant bien défini, nous devons créer des classes de travailleurs qui fournissent une implémentation concrète du WorkerContract pour les personnes et les entités bénéficiaires.

le PersonWorker s’étend de la WorkerContract et fournit la logique pour pousser Person données au serveur distant. L’extrait de code ci-dessous explique la PersonWorker classe.

Comme le montre le saveCallResult , une fois que les données locales ont été poussées avec succès, les données locales state et la télécommande id sont mis à jour en conséquence.

De même, le BeneficiaryWorker la mise en œuvre est indiquée ci-dessous. Ici le hasParentRelationship est définie pour renvoyer true car c’est l’entité enfant. Une fois la hasParentRelationship retourne la méthode true , nous devons vérifier si le Person entité associée à la Beneficiary via le personLocalId champ a été poussé vers la télécommande. Cela se fait via le checkParentStatus() méthode qui renvoie une valeur booléenne en fonction de l’état de l’entité parent. Ceci est illustré dans l’extrait de code ci-dessous:

Étape 3: créer des demandes de travail périodiques

Dans cette étape, nous créerons des demandes de travail périodiques pour chaque travailleur, car nous avons réussi à définir nos règles via le WorkerContract et a également créé des mises en œuvre concrètes de la WorkerContract.

Tout d’abord, nous devons définir les contraintes de réseau comme indiqué ci-dessous. Autrement dit, nous voulons pousser les données locales une fois la connexion réseau établie.

La demande de travail périodique pour sauver une personne est indiquée ci-dessous.

De même, la demande de travail du bénéficiaire est présentée ci-dessous:

À partir des demandes de travail ci-dessus, notez que nous avons utilisé une demande de travail périodique unique pour garantir qu’un seul PeriodicWorkRequest d’un nom particulier peut être actif à la fois. Dans notre cas, nous voulons qu’une seule opération soit active à la fois; s’il y en a un en attente, nous le laisserons se terminer, sinon, nous insérerons le nouveau travail.

Résultat

Essentiellement, la personne et les travailleurs bénéficiaires commenceraient en même temps et seront exécutés dès que les contraintes définies seront remplies. Cependant, le travailleur bénéficiaire ne serait pas en mesure de transmettre des données à la source de données distante tant que l’entité personne liée n’a pas été poussée comme spécifié par la relation d’entité et le contrat de travail. Par cela, nous pouvons atteindre un sens de l’ordre et de la priorité dans l’exécution des tâches périodiques.

Notez que la solution présentée dans cet article n’est en aucun cas générale. Il n’est spécifique qu’à ce cas d’utilisation. Cependant, il donne une idée générale de la manière dont les problèmes de ce type peuvent être résolus.

Production

Vous pouvez trouver le code source du client Android et du backend Spring-Boot dans le référentiel ci-dessous.

Merci d’avoir lu et n’hésitez pas à laisser vos commentaires et suggestions.