Dans les articles suivants de notre série Jetpack DataStore , nous aborderons plusieurs concepts supplémentaires pour comprendre comment DataStore interagit avec d'autres API, afin que vous ayez tout à votre disposition pour l'utiliser dans un environnement de production . Dans cet article en particulier, nous nous concentrerons sur le travail synchrone avec DataStore . Nous ferons référence au Preferences codelab , pour des exemples de code.

Faire un travail synchrone

Tout au long de cette série, nous avons mentionné l' API entièrement asynchrone de DataStore , issue de son utilisation interne des coroutines Kotlin et de Flow . Pour éviter que des ANR et des blocages d'interface utilisateur potentiels ne se produisent lorsque des opérations d'E/S plus lourdes sont effectuées sur le thread d'interface utilisateur, DataStore n'offre pas de prise en charge synchrone prête à l'emploi . DataStore enregistre son ensemble de données dans un fichier et, sous le capot, exécute toutes les opérations de données sur Dispatchers.IO, sauf indication contraire, en gardant votre thread d'interface utilisateur débloqué. Cette structure d'API est l'un des principaux avantages de DataStore par rapport à son prédécesseur SharedPreferenceset la façon dont vous utiliseriez DataStore dans la majorité des cas.

Cependant, si vous constatez que votre code vous oblige à travailler de manière synchrone avec DataStore, que ce soit en raison d'une dépendance à une autre API s'exécutant sur le thread principal ou parce que votre configuration actuelle nécessite que vous récupériez des valeurs persistantes pour votre configuration d'interface utilisateur, vous pouvez utiliser runBlocking()coroutine builder pour lire DataStore de manière synchrone . Cela bloquera le thread appelant jusqu'à ce que DataStore renvoie :

Si vous vous trouvez dans une situation où vous devez utiliser cette approche, passez un peu de temps à déterminer s'il est absolument nécessaire de bloquer le thread principal . Réfléchissez à la manière dont vous pourriez utiliser les alternatives asynchrones DataStore fournies ou refactorisez votre code actuel pour éviter runBlocking(), par exemple en préchargeant les données de manière asynchrone :

Si cela n'est pas possible, assurez-vous de couvrir tous les scénarios potentiels de jank de l'interface utilisateur avec la gestion des erreurs, l' annulation et les délais d'attente ou de jolis visuels pour rendre l'expérience utilisateur aussi fluide que possible.

À suivre

Nous avons expliqué comment effectuer un travail synchrone avec DataStore. Bien que ce ne soit pas l'approche recommandée pour DataStore, si votre configuration actuelle nécessite que vous lui fassiez des appels synchrones, vous pouvez utiliser use .runBlocking()combiné avec .first()operator.

Rejoignez-nous pour le prochain article de la série où nous examinerons comment effectuer des migrations DataStore à DataStore .

Vous pouvez trouver tous les articles de notre série Jetpack DataStore ici :
Introduction à Jetpack DataStore
Tout sur les préférences DataStore
Tout sur Proto DataStore
DataStore et injection de dépendances
DataStore et sérialisation Kotlin
DataStore et travail synchrone
DataStore et migration de données
DataStore et tests