Lorsque ce type de traitement logique implique la destruction et la reconstruction d'objets, il convient de prêter attention au découplage. Les références d'objet ne doivent pas être mappées, mais les valeurs des données doivent être mappées. Ne placez pas le traitement réseau directement dans Activity ou RecylerView. Pour le téléchargement, il est préférable de démarrer un service en arrière-plan pour gérer votre fil de téléchargement, puis de laisser le service communiquer avec l'activité. De cette façon, vous n'avez pas à vous soucier de savoir si votre objet peut correspondre. sur la progression du téléchargement signalée par le service. Quant à l'interaction entre Service et Activité, il y a trop de tutoriels et de roues sur Internet, je n'entrerai donc pas dans les détails.
Qu'il s'agisse du propre DownloadManager du système ou d'un composant de téléchargement personnalisé, un fichier téléchargé aura un identifiant de téléchargement, ou correspondra à un Uri. Il est à noter que le système DownloadManager est automatiquement transmis à la base de données. pour conserver les informations de téléchargement.
Avec cette prémisse, cela ne suffit toujours pas. Vous devez trouver un moyen d'obtenir la progression du téléchargement de chaque fichier. Ceci est lié à la mise en œuvre spécifique de DownloadManager. il semble qu'il ne fournisse que l'interface de requête. Par conséquent, nous devons créer un fil d'arrière-plan pour interroger la progression du téléchargement en temps réel.
Enfin, nous devons réfléchir à la manière de gérer la correspondance entre l'ID ou l'Uri et le RecyclerView de ItemView.
Les points 1 et 2 ci-dessus peuvent être implémentés en faisant référence à certains frameworks de chargement asynchrone d'images grand public (tels que github : nostra13/Android-Universal-Image-Loader
).
p.s. Si vous pensez que c'est trop compliqué, vous pouvez vous référer à github : erehmi/CountDownTask (je recommande sans vergogne mon propre projet [face cover])
.
p.p.s. Il n'est pas recommandé de notifyDataChanged() directement pour actualiser toute la liste, les performances sont trop faibles.
Lorsque ce type de traitement logique implique la destruction et la reconstruction d'objets, il convient de prêter attention au découplage. Les références d'objet ne doivent pas être mappées, mais les valeurs des données doivent être mappées. Ne placez pas le traitement réseau directement dans Activity ou RecylerView. Pour le téléchargement, il est préférable de démarrer un service en arrière-plan pour gérer votre fil de téléchargement, puis de laisser le service communiquer avec l'activité. De cette façon, vous n'avez pas à vous soucier de savoir si votre objet peut correspondre. sur la progression du téléchargement signalée par le service. Quant à l'interaction entre Service et Activité, il y a trop de tutoriels et de roues sur Internet, je n'entrerai donc pas dans les détails.
Avec cette prémisse, cela ne suffit toujours pas. Vous devez trouver un moyen d'obtenir la progression du téléchargement de chaque fichier. Ceci est lié à la mise en œuvre spécifique de
DownloadManager
. il semble qu'il ne fournisse que l'interface de requête. Par conséquent, nous devons créer un fil d'arrière-plan pour interroger la progression du téléchargement en temps réel.Enfin, nous devons réfléchir à la manière de gérer la correspondance entre l'ID ou l'Uri et le
RecyclerView
deItemView
.Les points 1 et 2 ci-dessus peuvent être implémentés en faisant référence à certains frameworks de chargement asynchrone d'images grand public (tels que github : nostra13/Android-Universal-Image-Loader
).p.s. Si vous pensez que c'est trop compliqué, vous pouvez vous référer à github : erehmi/CountDownTask (je recommande sans vergogne mon propre projet [face cover])
.p.p.s. Il n'est pas recommandé de notifyDataChanged() directement pour actualiser toute la liste, les performances sont trop faibles.
Il est préférable d'utiliser le service pour ce type de tâche de téléchargement