Devrions-nous utiliser RecyclerView pour remplacer ListView?

Si ListView fonctionne pour vous, il n’y a aucune raison de migrer. Si vous écrivez une nouvelle interface utilisateur, vous pourriez être mieux avec RecyclerView.

RecyclerView est puissant lorsque vous avez besoin de personnaliser votre liste ou que vous souhaitez de meilleures animations. Ces méthodes de commodité dans ListView ont causé beaucoup de problèmes aux utilisateurs. C’est pourquoi RecyclerView leur offre une solution plus flexible.

Le principal changement à effectuer pour la migration réside dans votre adaptateur. Si vous souhaitez continuer à appeler notifyDataSetChanged , vous perdez la plupart des avantages de l’animation et de la liaison. Mais si vous pouvez changer votre adaptateur pour envoyer des événements de notification détaillés (ajoutés / supprimés / déplacés / mis à jour), vous obtiendrez de bien meilleures animations et performances. Ces événements permettent à RecyclerView de choisir des animations correctes et évitent onBind appels inutiles. Vous obtiendrez un avantage énorme si les vues de vos articles sont complexes. De plus, RecyclerView contiendra davantage de composants.

Selon moi, si ListView répond à tous les besoins actuels de votre application et satisfait à tous les cas d’utilisation, il n’est pas nécessaire de le remplacer par RecyclerView.

Le RecyclerView donne un énorme pouvoir à ses développeurs au prix d’une complexité accrue pour les développeurs. Il y a certaines choses qui peuvent être faites facilement dans un ListView et qui demandent maintenant beaucoup d’efforts inutiles.

Mais oui, il y a beaucoup de choses qu’un ListView ne peut jamais faire, comme l’incroyable fonctionnalité LayoutManager qui peut vous permettre de changer de manière dynamic la mise en page horizontalement, verticalement, en grid ou en quadrillage de manière transparente.

J’ai écrit une réponse détaillée sur ce sujet ici .

1 Vous pouvez utiliser une interface pour fournir un écouteur de clic. J’utilise également cette technique avec ListViews.
2 Aucun diviseur: Ajoutez simplement dans votre ligne un View avec une largeur de match_parent et une hauteur de 1dp et donnez-lui une couleur de fond .
3 Utilisez simplement un sélecteur StateList pour l’arrière-plan de la ligne.
4 addHeaderView peut également être évité dans ListViews: placez simplement l’en-tête en dehors de la vue.

Donc, si l’efficacité est votre préoccupation, alors oui , c’est une bonne idée de remplacer un ListView par un RecyclerView.

Le seul cas où il est toujours possible d’utiliser ListView est lorsque la liste n’est pas dynamic ou affectée par des événements réseau. Par exemple: navigation.

Pour toute autre utilisation, RecyclerView éclipse ListView. Étant donné que RecyclerView se soucie uniquement de recycler, il sera plus facile de faire des choses visuellement étroitement liées dans ListView, comme le changement de position / réarrangement, l’animation (en fait, RecyclerView.ItemAnimator), le StaggeredGrid en plus de l’ancienne liste ou le style de grid, mais il y a aussi cette bibliothèque qui l’étend encore plus).

Aussi, si vous voulez utiliser CardView, je crois que c’est le seul moyen d’y parvenir (quelques bonnes lectures pour utiliser une carte ou une liste).

Une excellente alternative consiste à utiliser le BaseAdapter. Il prend en charge l’utilisation du modèle Viewholder et le mien contient plus de 100 lignes avec des bitmaps et des boutons et il fonctionne très bien.

J’avais jusqu’à récemment utilisé ListView pour des listes très simples. Par exemple, si je veux afficher une simple liste d’options de texte …

J’ai basé cette décision sur les «facteurs humains», à savoir que la création d’un ListView simple avec moins de code est préférable si les performances sont sans importance. Je pense souvent à un professeur au collège qui aimait dire: “Mon professeur, le grand Niclaus Wirth, l’inventeur de Pascal, avait l’habitude de dire que si un programme contient plus de 50 lignes de code, il se trompe …”

Mais ce qui m’a convaincu de ne plus utiliser ListView, c’est qu’il a récemment été déplacé dans la catégorie “Legacy” de l’outil de conception Android Studio avec RelativeLayout.

Je pense que c’est une forme de «dépréciation» «douce». Il serait trop perturbateur s’il était réellement obsolète et que tous les développeurs consciencieux ont déplacé leur code dans RecyclerView.

De plus, l’intro de ListView avertit tout en haut que RecyclerView est une meilleure option: “Pour une approche plus moderne, flexible et performante de l’affichage des listes, utilisez RecyclerView.”
https://developer.android.com/reference/android/widget/ListView

En outre, le guide de ListView parle toujours des chargeurs de curseur, mais getSupportCursorLoader () lui-même vient d’être obsolète dans l’API 28.
https://developer.android.com/guide/topics/ui/layout/listview

Améliorations récentes apscopes à Android Studio:

Fichier -> Nouveau -> Fragment -> Fragment (Liste)

Cela nous donne un RecylerView entièrement fonctionnel rempli de texte de base. Cela élimine ma dernière raison réelle d’utiliser ListView, car il est désormais tout aussi simple de configurer un RecylerView de base.

En résumé, je n’ai pas l’intention d’utiliser ListView pour un nouveau développement, car l’étiquetage «hérité» est loin d’être obsolète.