Challenge - notifyItemChanged seems slow


#1

When I use mAdapter.[b]notifyItemChanged/b on the updateUI method it gets a delay to render the new layout on the screen. When the CrimeFragment closes I can see the layout changing, although when I use mAdapter.[b]notifyDataSetChanged/b it’s much faster, I can’t see the layout changing.

Is it right? Shouldn’t the notifyDataSetChanged be slower than the notifyItemChanged method?


#2

I noticed this as well. It seems like a slight delay when the updated checkbox status is drawn on after the view appears when using notifyItemChanged, where notifyDataSetChanged the checkbox is properly set when the view is drawn. I can’t figure out why this would be happening. I’m curious now though!


#3

From the RecylerView.Adapter.notifyDataSetChanged() reference: [quote]RecyclerView will attempt to synthesize visible structural change events for adapters that report that they have stable IDs when this method is used. This can help for the purposes of animation and visual object persistence but individual item views will still need to be rebound and relaid out.

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.[/quote]

So notifyDataSetChanged() is more expensive computationally, but everything is redrawn at once so you never see the old state and it appears smoother.

Based on this, I’m going to use notifyDataSetChanged() by default and only switch to notifyItemChanged() when there is a noticeable lag. I’ll take visual consistency over imperceptible performance increase.


#4

Same Problem here too. The notifyItemChanged is noticeably slower than notifyDataSetChanged. Please clarify.


#5

Yeah … exactly the same issue I got there !
any remedy?