I have used the RececlerView with the ViewHolder pattern for a while now.
Im am implementing a custom Adapter.
Im am not searching for a specific bug help in my code.
I was just wondering, if it's normal, that the onBindViewHolder method is called multiple times (for the same item) while scrolling to the end of the list and scrolling back up. In this case onBindViewHolder is called again for item 0 and 1 (the list contains 7 items in total)
Is there any possibility for this method to get called AGAIN without notifying that the datasat has changed?
Im a bit confused.
Kind Regards,
Palm
Yes it is perfectly normal for a RecyclerView to call onBindViewHolder() multiple times.
A RecyclerView only creates minimum number of Views needed to fill the screen. And it works by reusing the old/created Views. So that when you are scrolling down the View that hid during the scrolling to the top is removed and brought next to the last visible View and added there. But since the View is currently bound with old data onBindViewHolder() is called again to ensure that the View is bound with only the correct data before it is rendered.
Similarly you'll notice that onCreateViewHolder() is only called the exact minimum number of Views it needs.
For a better understanding of how the RecyclerView works I suggest you read up on Recycler, LayoutManager and Recycler.Adapter the three core parts of a RecyclerView.
Related
This question already has answers here:
Android Recyclerview vs ListView with Viewholder
(7 answers)
Closed 3 years ago.
I was reading about the difference b/w recyclerview and listview and found out that recyclerview is faster than listview.
I tried to search online but not found any satisfactory answer I know it is used ViewHolder pattern and Notifying adapter but what does it does intearlly so it is faster?
Recycler View you could say is an efficient way to create list of views.
If you have 1000 items like ur contact list , and If ur visible screen can show only 10 items at once, it will Create only 10+1 (or +2) Views and as u scroll , items/views that left will be reused (not create) to show new data.
Recycler View by default does this, where as List View by default doesn't do.
There are some differences between these two views.
ListView is a bit heavy and 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.
A lot of bad things 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 some crucial differences between ListView and RecyclerView:
1 ViewHolder
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 — onCreateViewHolder() and onBindViewHolder().
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.
2 LayoutManager
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.
3 ItemDecoration
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.
4 ItemAnimator
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. Again, we had to figure out how we want to handle them.
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 notifyItemInserted(), 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.
Because of ViewHolder Pattern.
Thats was the simplest answer. Now for some details.
What recycler view does is what it's name indicates "Recycle", yes it recycles items, and it does it with the help of ViewHolder Pattern.
By Using ViewHolder we do-not need to call findViewByID() every time we go through getView()method. The reference for all rows are stored in-memory. This increases the performance significantly, as findViewByID()is a heavy process.
Hope this clears your confusion.
I have a vertical RecyclerView with LinearLayoutManager with three item types and three different ViewHolders. It is a screen with comments, where first row is a post, rest are the comments and last one is an "infinity scrolling" loading row.
The first row with a post has a countdown, which I update every second via notifyItemChanged(0, "countdown"). The post is correctly updated, the bind is called with the correct payload. Below the post a one comment is visible only.
The problem is that this notifyItemChanged(0, "countdown") calls bind also for the invisible rows 2 and 3. If I update the layout of the post so two comments are visible, then only update for the invisible row 3 is called (plus bind with payload on the post). These binds are called without the payload, obviously. So it does full reload of the rows' data, which I do not want, it is a waste.
Now the funny thing, if I scroll the RecyclerView a tiny bit (even 1 px) this behaviour stops and just the first row, the post, is receiving the bind call. And when I scroll back to top the bind is not called for the invisible cells. So after a tiny scroll all this is fixed.
Other screen with posts only + infinity scrolling row does not behave like this and works as it should.
This is happening with RecyclerView from support library 27.0.2.
EDIT:
This is happening with prefetch on and off, and with different values e.g. 2, 4.
I'm displaying a variable number of ViewHolders in a RecyclerView, each with a unique CountDownTimer in it, displayed in a TextView.
If I don't have a large number of ViewHolders in the RecyclerView then the CountDownTimers tick down as expected, second by second.
However, my issue arises when I have a large number (> 10 or so) of items in the RecyclerView. When I open the Activity with the RecyclerView, I see the CountDownTimers displayed to me functioning properly, however as I scroll up and down the entire RecyclerView, the CountDownTimers begin to malfunction.
By malfunction I mean that they fluctuate. For instance, one CountDownTimer will display 20:15 then jump to 30:16 then back to 20:14 then back to 30:15. It's very odd.
This is what I believe the issue is: as I scroll down the RecyclerView, ViewHolders with CountDownTimers disappear but their CountDownTimers are not destroyed, and when I scroll back to those ViewHolders there are multiple CountDownTimers being assigned to the TextViews which display their respective countdowns.
My question is this: Assuming what I described is indeed the issue, how do I cancel CountDownTimers in RecyclerView ViewHolders as they're scrolled past?
From My understanding about RecyclerView :
RecyclerView creates viewHolders as many as it needs to display plus one or more extra for smooth scrolling. When it needs to show new item it checks that any unused viewHolder existed. If existed then it reused the existing one otherwise creates new.
In your condition when you scroll very long then it tries to use existing viewHolder which might be started count down. Now when new item binds it starts another count down. Thats why it shows malfunction.
So, You can add a check & stop count down before starting a countdown. Hope it will help you.
Thanks in advance.
Is is possible to have race conditions between the notify* methods of a RecyclerView.Adapter and scrollToPosition (and smoothScrollToPosition) of the RecyclerView itself? If so, how can I force the scroll to happen strictly after the notify has been applied?
In a bit more detail: I have a RecyclerView with an adapter that frequently is updated with new items (which may or may not overlap with the previous items). Also, whenever I set new items I also want to set the scroll position to a specific item. To that end, I first update the items inside my Adapter and then scroll the RecyclerView.
However, more often than not the scroll position will be wrong after this process. Also, if I then issue another smoothScrollToPosition command without changing the data, the scrolling is weird: It sometimes goes in the wrong direction, etc. After this second scrolling, the position is always correct however. So, it seems that something goes wrong the first time and the RecyclerView catches and corrects that error on the second scroll.
Also, the errors are slightly different when I use notifyDataSetChanged from when I use DiffUtil.
Now I've read in this response by Yigit that notify* is basically asynchronous, so I suppose there can be a race condition between them and the subseqent scrollToPosition - is that correct?
Finally what can I do to establish a strict ordering, so that the scroll is only called when all ViewHolder updates triggered by notify are done?
I have a ListView which onItemClick selected item changes its layout, pops different buttons. If any other item is selected, the previous selected one returns to normal. My ListView adapter works fine but refreshing the whole list with notifyDataSetChanged() in my adapter takes too much time.
My problem is to refresh only the changed items in the ListView.
And also I would like to have suggestions for better scrolling performance.
try to implement View Holder Pattern it increases the performance of loading and scrolling of ListViews
Making ListView Scrolling Smooth | Android Developers
Using lists in Android (ListView) - Tutorial - Vogella
from the docs:
Your code might call findViewById() frequently during the scrolling of ListView, which can slow down performance. Even when the Adapter returns an inflated view for recycling, you still need to look up the elements and update them. A way around repeated use of findViewById() is to use the "view holder" design pattern.
you can define one method in adapter class which will return current item view. in onitemclick use this method to make changes in clicked item. You can define class view type class variable in activity and store previous view there...
ListView scrolling performance slows down when widgests like textviews, images are at the bottom of the layout hierarchy.
So for improving list performance one should design item xmls with minimum layout tree levels.