Reputation: 1785
I'm fairly new to Android and am currently working on my first serious app which is based on a RecyclerView. I've been noticing some problematic behaviour in my app when I insert or update an existing row: the added/modified row does not display quite correctly even though I have executed notifyItemInserted(position) in the case of an add or notifyItemRemoved(position) and notifyItemInserted(position) in the case of a change. In researching this, I came across DiffUtil for the first time and see that it is highly recommended for working with RecyclerView.
I gather that managing the notifyXXX methods is tedious when people are dealing with ranges of rows/records in the Adapter but I'm only ever adding, updating, or deleting a single row/record from my ArrayList. Is there any advantage for me in using DiffUtil instead of notifyXXX or is DiffUtil really only helpful when working with groups of rows? There's obviously more code to write with DiffUtil and there is also some overhead involved in executing it.
Upvotes: 2
Views: 839
Reputation: 474
In my opinion, if you are following android recommend architecture, you should use DiffUtil instead. For example, you have 2 activities:
You have observed a list of diaries and update A based on that. Then in B you create a new diary, at that time A will get the signal and update the list. You don't have to call for notifyItemInserted
. All you need is a DiffCallback to have the recycler view not re-draw the items that not changed.
Upvotes: 0
Reputation: 54244
Is there any advantage for me in using DiffUtil instead of notifyXXX
Short answer: no.
or is DiffUtil really only helpful when working with groups of rows?
What DiffUtil
does is take two "before" and "after" lists and compute for you all the various notifyItemInserted()
/ removed / changed calls you would have to make. In cases where you know that you only need to make one of these calls, there's no need to do the work to implement DiffUtil.Callback
.
There's obviously more code to write with DiffUtil
This is the main reason not to bother. It might be a good exercise, but it's always better to keep it simple.
and there is also some overhead involved in executing it.
I wouldn't worry about this unless you can prove that it's a problem. We're talking about nanoseconds in most cases.
Upvotes: 5