Modèles et vues : fonctionnalité « Fetch More » utilisant un thread de travail

Cet exemple montre comment utiliser ` QAbstractItemModel::fetchMore()` avec un objet déplacé vers un ` QThread ` afin que la récupération des données ne bloque pas l’interface utilisateur. À chaque appel, le ` FetchWorker ` met en attente pendant 2 secondes, pour simuler un service backend lent, avant d’envoyer davantage de données au thread de l’interface utilisateur.

Fonctionnalité de base

Pendant que les données sont récupérées dans le thread de travail, le modèle ajoute une BusyIndicator à la fin de la liste. Une fois les données récupérées avec succès, l’ BusyIndicator est supprimé et les nouveaux éléments sont ajoutés à la liste. L’ ListView est utilisé de manière classique et ne nécessite aucune adaptation pour gérer la lenteur du modèle.

Responsabilités

Les modifications apportées au modèle d’éléments (dans ce cas, l’insertion et la suppression de lignes) doivent s’effectuer dans le thread de l’interface utilisateur. L’objet du thread de travail construit progressivement les structures DataBlock et émet le signal « dataFetched » avec un « QList » de blocs de données comme charge utile ; le signal est envoyé via un « Qt::QueuedConnection » vers le slot ThreadedFetchMoreModel::dataReceived(), qui les ajoute à la liste de données dans le thread de l’interface utilisateur. Le thread de l’interface utilisateur ajoute un élément de remplacement à la fin de la liste avant d’envoyer le signal `fetchDataBlock()` à l’objet de travail pour lancer le processus de récupération, puis supprime cet élément de remplacement avant d’ajouter de nouveaux éléments à la liste.

Une fois toutes les données disponibles récupérées, l’objet du thread de travail envoie le signal ` noMoreToFetch ` au modèle ; à partir de ce moment-là, la méthode `canFetchMore()` renvoie toujours ` false`.

Exemple de projet @ code.qt.io