Yeah, not really news, but just fell into one of those traps, where you not only forget/fail to fully read the documentation, but also fall prey to premature optimization.
It probably dates back to my 8086-Assembler-4.77MHz programming times, that I want to avoid an API call whenever possible - so if their result appears invariant, I happily store if to avoid a second call.
40 years later, when working with Android RecylcerViews, this led to a terrible bug that cost me 2 days to identify and fix.
As the docs say for onBindViewHolder (for the RecyclerView.Adpater)
Note that unlike android.widget.ListView, RecyclerView will not call this method again if the position of the item changes in the data set unless the item itself is invalidated or the new position cannot be determined. For this reason, you should only use the position parameter while acquiring the related data item inside this method and should not keep a copy of it. If you need the position of an item later on (e.g. in a click listener), use getBindingAdapterPosition which will have the updated adapter position.
In order to pass the adapter position down to an onClick lambda, I even — specifically — made it final.
No wonder, that the code didn't work correctly in some — albeit very rare — circumstances, e.g. when an item further up in the list got removed from the view / adapter.
Again, reading the above would make it clear that this was not a time for premature optimization.
I think I should avoid those optimizations at all, the compiler and jvm is quite good at it anyway — especially identifying invariant function calls. Moreover, Android phones no longer run on 4.77MHz CPUs ;)
Lesson learned.
Subscribe