Pagination Firestore avec mises à jour en direct

Imaginez regarder des centaines de lignes de données où de nouveaux enregistrements peuvent être ajoutés, supprimés ou mis à jour à tout moment et montrer ces données en temps réel dans une RecyclerView directement à l’utilisateur. La récupération de toutes les données consomme du temps et de la bande passante. Pour réduire cette charge, vous avez décidé de paginer les données. Mais les choses se sont encore aggravées, n’est-ce pas ? Vous venez de découvrir qu’il n’y a pas de solution toute faite pour cela. Et faire ces choses efficacement est un autre défi. Analysons le problème un peu plus en profondeur.

Je développe un module de messagerie où n’importe quel nombre d’utilisateurs peut discuter entre eux dans un seul canal, similaire aux canaux Slack ou à un groupe WhatsApp.

Parce que je avoir besoin Les mises à jour en temps réel sont dues aux exigences suivantes :

1. Les nouveaux messages devraient apparaître instantanément.
2. Les utilisateurs peuvent réagir et répondre aux messages d’autres utilisateurs.
3. Les utilisateurs peuvent également supprimer le message, il est donc important de le faire au cas où l’utilisateur aurait accidentellement envoyé quelque chose.

La documentation officielle pour les requêtes de pagination suggère d’utiliser le get() méthode dans Query . Cela signifie que vous n’obtenez les dernières données qu’une seule fois. Essentiellement, vous manquez les mises à jour en temps réel qui ne sont pas négociables pour mon cas et pour vous aussi si vous êtes ici !

Même le FirebasePagingAdapter de la bibliothèque FirebaseUI ne fournit pas de mises à jour en temps réel car il utilise Paging3 en dessous et n’est pas conçu pour les données dynamiques.

Les deux manières « officielles » ne conviennent pas à notre cas, et nous perdons également la possibilité de recevoir de nouveaux messages. :RÉ

Que devrions-nous faire alors?

Après avoir essayé de nombreux cas, je n’ai pas trouvé un tir solution pour supprimer tous les compromis. Parfois, j’ai perdu la possibilité d’ajouter de nouveaux messages ou j’ai raté des mises à jour sur d’anciens messages. MAIS il existe une solution qui peut nécessiter la condition préalable suivante et un travail supplémentaire.

Vous avez besoin d’au moins un champ/colonne prévisible dans votre base de données.

Par prévisible, je veux dire dont vous appréciez la valeur il doit savoir quand récupérer des données. Par exemple, dans mes données, chaque message a un horodatage. Et le nom de la colonne est created_at .

Maintenant, je peux récupérer les données dans beaucoup.

1. Nouveaux journaux — Ajoutez un écouteur d’instantané pour obtenir les messages dont created_at commence après heure système actuelle.
2. Anciens enregistrements N — Un autre écouteur instantané pour recevoir les messages dont created_at commence avant de heure système actuelle.
3. Paging — Égal à 2, ajouter plus d’écouteur d’instantané à la demande, mais basé sur created_at à partir de l’enregistrement le plus ancien que nous avons obtenu de la requête 2.

Ici, Non correspond à la taille d’une seule page ou au nombre d’éléments que vous souhaitez consulter en même temps.

La requête pour cela sera la suivante –

Récupérer une liste de DocumentChange de ces requêtes dans vos méthodes de référentiel. Nous utilisons DocumentChange car il ne contiendra que les enregistrements ajoutés/supprimés/mis à jour. L’implémentation dépend de vous, mais puisque j’utilise Kotlin Flows, voici à quoi ressemble la méthode de référentiel –

Maintenant, nos doutes sont résolus. Nous avons maintenant besoin d’une structure de données pour stocker toutes les données provenant de ces requêtes. Rappelez-vous qu’il s’agit d’un SnapsotListener donc tout rappel peut déclencher à toute heure avec de nouvelles mises à jour.

Lister? — Vous pouvez utiliser des listes MAIS faire des opérations surtout dans le cas où la suppression d’un élément ou la mise à jour d’un élément coûte cher.

HashMap ou LinkedHashMap(pour conserver l’ordre d’insertion) nous aidera dans ce cas.

C’est ça! Reconvertissez-le dans la liste pour l’exposer dans la couche de vue et utilisez-le dans votre adaptateur. Pour l’efficacité de l’interface utilisateur, assurez-vous d’utiliser DiffUtil avec votre adaptateur RecyclerView.

Que pensez-vous de cette solution ? Je serais heureux d’améliorer cette solution, alors faites-moi part de vos idées et commentaires. Aussi, n’hésitez pas à me contacter.