I am running into an issue with the RecyclerView#Adapter regarding notifyItemRangeChanged. It seems that if the Adapter thinks it has a size of 0 from the last call to getItemCount, and then I call Adapter#notifyItemRangeChanged(0, 1), the Adapter will simply ignore the call (it doesn't result in the new item being inserted, for example).
Is this the expected behavior?
Is this the expected behavior?
Short answer: yes.
From the docs on notifyDataSetChanged() (yes, different method, I know, but just referencing it here since it explains the difference between item changes and structural changes):
There are two different classes of data change events, item changes and structural changes. Item changes are when a single item has its data updated but no positional changes have occurred. Structural changes are when items are inserted, removed or moved within the data set.
Now have a read through the documentation on notifyItemRangeChanged() (my emphasis):
This is an item change event, not a structural change event. It indicates that any reflection of the data in the given position range is out of date and should be updated. The items in the given range retain the same identity.
That should answer your question. You're making a structural change (that is, you're adding an item), hence notifyItemRangeChanged() is not the appropriate method to call. Instead, you should call notifyItemRangeInserted() (or its singular equivalent), which does indicate a structural change was made.
Related
I need the functionality to update the data in the item in the recycler view. right now, If we notify the whole item it shows some fluctuation and we want to avoid refreshing the whole item on the UI.
I am using the ListAdapter with diff utils.
There are many ways to achieve your goal.
self-managing items. Adapter doesn't know anything about content of the items, it only puts items into RecyclerView. Content is managed by the item itself, so your problem is already solved.
custom adapter. Adapter has intricate knowledge about every item and can update selected ones accordingly.
AsyncListDiffer You can add differ to your adapter and it will take care of not updating parts that need no update.
Without seeing your code, we can't tell which way would be the most appropriate for you, but I guess adding differ is the simplest on already working code.
You need to create custom Adapter:
https://developer.android.com/develop/ui/views/layout/recyclerview
If you're talking about updating specific list items, and you're not using a DiffUtil (which will handle it for you) then you need to call the appropriate notify* method on your Adapter.
They fall into two categories, item change events (where the item list stays the same, but the displayed data for one or more of those items changes) and structural change events (where the actual list of items changes in some way, e.g. insertion/removal, or reordering).
I'm assuming you just want to update the displayed data for an item, so you should use one of the notifyItemChanged or notifyItemRangeChanged methods to inform the adapter that a certain item (or range of items) needs to update. If any of those items are currently being displayed in a ViewHolder, then onBindViewHolder will get called again for those items - which is where you set all your text, images etc depending on the item you're displaying. So you'll update them with the current data.
Both those methods have a version that takes a payload Object/Any, where you can pass in some data to be used in a partial bind - basically, onBindViewHolder can receive that data and be smarter about the update, which means you can avoid things like reloading images, etc. by passing in some stuff and checking for it during the binding process. More info about that here in the other version of onBindViewHolder you can implement, if you need to.
I have a custom class for data shown in my RecyclerView. Each object and thus each row has a unique id value for id field in the class.
Whenever I refresh data, the list gets cleared, repopulated and notifyDataSetChanged() is called. This causes for blinking effect.
During these refreshes, although id stays the same, some other fields are changing and some of these changing fields should be reflected in the item view.
Should I be using setHasStableIds(true) combined with getItemId() OR should I use DiffCallback where I can override areItemsTheSame() and areContentsTheSame()?
If I use former, I am not sure if it can detect changes in other fields and update the row.
If you can, you should always prefer DiffCallback. Stable IDs can only compare identity, but not contents. This leads to exactly the blinking effect you describe on item content change, because RecyclerView is forced to assume that the content might have changed, and rebind it/execute the item changed animation. DiffCallback has no such limitation, and will always do the right thing if the callback is correctly implemented.
I'm confused if we use the two methods to tell the adapter that data you point were changed so what is the difference between them.
notifyDataSetChanged() can be thought of as a "major" change. You're telling the adapter that everything in the data set has changed, and so it should re-bind every single child.
notifyItemInserted() (and the other methods like notifyItemRemoved() etc) can all be thought of as "minor" changes. You're telling the adapter exactly how the data set has changed, and so it can perform optimizations (like only re-binding the affected children).
Notably, using the "minor" change methods will also give you nice animations by default, which makes it a lot easier for the user to see what changed in the list.
Based on the documentation
notifyDataSetChanged():
This event does not specify what about the data set has changed, forcing any observers to assume that all existing items and structure may no longer be valid. LayoutManagers will be forced to fully rebind and relayout all visible views.
notifyItemInserted()
Representations of other existing items in the data set are still considered up to date and will not be rebound, though their positions may be altered.
Main difference is that notifyDataSetChanged() will cause more overhead since it will force LayouManagers to full rebind the views where as notifyItemInserted() will not rebound all the views again but rather alter positions for them.
For better performance, rely on notifyDataSetChanged() as a last resort. Use the more specific change events (like notifyItemInserted()) wherever possible for better efficiency.
notifyItemInserted(int position) takes the position of your inserted item as an argument, notifies about that item insert and thus also shifts positions after that item.
notifyDataSetChanged() notifies that the data set connected to the adapter has changed.
Must notifyItemRangeChanged be called after calling notifyItemInserted in an RecyclerView.Adapter?
There are so many examples on SO where they always call notifyItemRangeChanged after notifyItemInserted but I am not sure this is really correct? If this is correct what would be the explanation? What would the case be where you don't need to call notifyItemRangeChanged, otherwise it would be part of notifyItemInserted?
There are no rules as one method should always precede the other.
If there is an addition of a new item, then call notifyItemInserted. If items are changed, then call notifyItemRangeChanged.
If some items are added and some are changed, you have to call both methods with respective positions as arguments. You can call the methods in any order, but based on the order the animations and the position that you have to pass to the methods might change.
Based on the documentation for RecyclerView:
There are two different classes of data change events, item changes and structural changes. Item changes are when a single item has its data updated but no positional changes have occurred. Structural changes are when items are inserted, removed or moved within the data set.
notifyItemInserted
Is a structural change event
notifyItemRangeChanged
Is a item change event
What would the case be where you don't need to call
notifyItemRangeChanged, otherwise it would be part of
notifyItemInserted?
Well its not necessary to always call notifyItemRangeChanged when notifyItemInserted since they both serve different purposes.
To put it in a simple way, if you add a new row/data to existing adapter's dataset then you should call notifyItemInserted.
If you modify certain data in bulk in the adapter's dataset, without adding, moving or deleting the adapter's dataset's content then call notifyItemRangeChanged. For single item change use notifyItemChanged
So I have an activity with RecyclerView and I want to change TextView of every item in the RecyclerView by pressing button that has onClickListener() in the activity.
I'm wondering what is better in terms of performance:
Use notifyDataSetChanged ones.
Use loop with condition like int i is less than List.size() where notifyItemChanged would be called few times.
In both cases I create boolean variable in RecyclerView Adapter which is used by onBindViewHolder to know how to update item. By default it's false and after button click it becomes true so onBindViewHolder updates item in different way.
Also I would like to know if this approach is suitable at all.
If you are simply updating one part of the view, use the notifyItemRangeChanged()or notifyItemChanged() instead of notifiyDataSetChanged(). The difference here has to do with structural changes vs item changes. This is on the android developers RecyclerView.Adapter documentation found here.
Here is another tidbit on the differences between the two types of changes:
There are two different classes of data change events, item changes
and structural changes. Item changes are when a single item has its
data updated but no positional changes have occurred. Structural
changes are when items are inserted, removed or moved within the data
set.
This is taken from that aforementioned page,
If you are writing an adapter it will always be more efficient to use
the more specific change events if you can. Rely on
notifyDataSetChanged() as a last resort.
So just to clarify use notifyDataSetChanged() as a last resort, and instead ask yourself if you can preform one of these methods instead, and if you can use it instead:
notifyItemChanged(int)
notifyItemInserted(int)
notifyItemRemoved(int)
notifyItemRangeChanged(int, int)
notifyItemRangeInserted(int, int)
notifyItemRangeRemoved(int, int)
which makes sense because notifyDataSetChanged() will pretty much try to redraw everything based on the data and make no previous assumptions on it, while the other methods will just look for changes. That means the adapter has to do a lot more work that is not necessary. This is what notifyDataSetChanged() does:
This event does not specify what about the data set has changed,
forcing any observers to assume that all existing items and structure
may no longer be valid. LayoutManagers will be forced to fully rebind
and relayout all visible views.
This also makes sense to use the incremental or range approach, because you are changing the text, you need to go get each new text and when you do that you should tell the adapter you changed it. Now, if you do a button click and get all new text values, and create a new list or something then call heavy notifyDataSetChanged().
I would definitely call notifyDataSetChanged() if all of the data items ar no longer valid. When you call notifyItemChanged(mPos), it is equivalent to a call to notifyItemRangeChanged(mPos, 1), and every time it is called, requestLayout() is also called. On the other hand, when you call notifyDataSetChanged() or notifyItemRangeChanged(0, mList.size()), there is only one call to requestLayout().
Your question should now be, what is better, a call to notifyDataSetChanged() or notifyItemRangeChanged(0, mList.size())? For that one I don't have an answer.
I've noticed that notifyItemChanged(mPos) triggers onBindVieHolder for corresponding position even it's currently not visible.
For me, calling it in a loop for all elements was more costly than notifyDatasetChanged which redrawn only visible ones.
So be careful with large datasets.