ListView and RecyclerView – a short history
As Android Developers, we are able to implement a scrolling list in a couple of ways, which mostly depends on what we really need to do. The most popular methods are to use a ListView or a Recycler View.
ListView is a good old widget which has been included in the Android SDK since the API 1. Until Android Lollipop’s release, we mostly used this one and it wasn’t that bad – the API is mostly intuitive. Unfortunately, it allows us to create just the vertical-scrolling list of elements and, to make that list scrolling go smoothly, we have to remember to do it in a proper way.
Moreover, the ListView class is a bit too heavy – it has a lot of responsibilities. Whenever we have to handle the list, such as to configure it in some way, the only way to do this is through the ListView object or inside the adapter.
Nowadays we use the RecyclerView. As I’ve mentioned, it was introduced with the Android Lollipop and it proved to be a game changer. A lot of things that we hate in the ListView were fixed or changed in the RecyclerView. It’s more efficient by default, the layout is separated and we have more possibilities over the data set inside the adapter.
These are the crucial differences between ListView and RecyclerView:
The ViewHolder pattern allows us to make our list scrolling act smoothly. It stores list row views references and, thanks to this, calling the
findViewById() method only occurs a couple of times, rather than for the entire dataset and on each bind view.
The RecyclerView’s adapter forces us to use the ViewHolder pattern. The creating part (inflating the layout and finding views) and updating the views is split into two methods —
The ListView, on the other hand, doesn’t give us that kind of protection by default, so without implementing the ViewHolder pattern inside the
getView() method, we’ll end with inefficient scrolling in our list.
NEED A SUCCESSFUL TEAM?
We’re 100% office based team with 7-years’ experience
in mobile & web app development
The LayoutManager takes responsibility for layouting row views. Thanks to this, RecyclerView doesn’t have to think about how to position the row view. This class gives us the opportunity to choose the way that we want to show the row views and how to scroll the list. For example, if we want to scroll our list vertically or horizontally, we can choose LinearLayoutManager. For grids, it is more suitable to choose the GridLayoutManager.
Previously, with the use of the ListView, we were only able to create a vertical-scrolling list, so it wasn’t that flexible. If we wanted grids on our list, we had to choose the other widget for that — GridView.
A duty of the ItemDecoration is simple in theory – add some decorations for the list row views – but in practice, it’s that simple to implement if we want to create a custom one. In this case, we should extend the ItemDecoration class and implement our solution. For example, the RecyclerView list has no dividers between rows by default and it’s consistent with the Material Design guidelines. However, if we want to add a divider for some reason, we can use DividerItemDecoration and add it to the RecyclerView.
In case we use the ListView, we have to figure out rows decorations by ourselves. There is no helper class like ItemDecoration for this widget.
The last but not least component of RecyclerView that I want to mention is ItemAnimator. As we can expect, it’s handling row views animations like list appearance and disappearance, adding or removing particular views and so on. By default, RecyclerView’s list animations are nice and smooth. Of course, we can change that by creating our own ItemAnimator, which is also not that easy. To make it easier, we should extend the SimpleItemAnimator class and implement the methods that we need (just add animations to a ViewHolder’s views).
To be honest, implementing animations on the ListView was a pain in the ass. Again, we had to figure out how we want to handle them. Nothing nice. I’m glad it’s gone.
#5 Notifying adapter
We have a couple of cool notifiers on the RecyclerView’s adapter. We are still able to use
notifyDataSetChanged() but there are also ones for particular list elements, like
notifyItemRemoved() or even
notifyItemChanged() and more. We should use the most appropriate ones for what is actually happening, so the proper animations will fire correctly.
Using ListView, we were able to use just
notifyDataSetChanged() on the adapter and then had to handle the rest ourselves, again.
The ListView served us for a long time. We were able to cover most of the cases. But user’s needs are different now and they are much more challenging. List designs became more and more complex and the ListView wasn’t helping with handling them. Material Design brought other changes, too – it’s beautiful but complex.
Fortunately, the RecyclerView was introduced and a lot of problems were solved. It’s more efficient by default, its animations are simpler, layouting it’s easier to use and the API is much nicer. So, if you ever wonder which one you should choose, your first thought should definitely be the RecyclerView.
The post was written by Mateusz Budzar, Droids On Roids Android Developer. This and other articles of Mateusz you can find also on Medium