The Adapter implementation on top of BaseAdapter of the ListView wrongly implements the stable ids, it supposes to provide from its data source.
According to BaseAdapter#hasStableIds() with hasStableIds() returning true "the same id always refers to the same object". In the implementation of list-view.android.ts the id used is the index of the item in the array.
That means changing the underlaying data, by reordering, filtering or entirely reloading will break the named above contract.
For us that causes app crashes because the cached views of the adapter are out of sync with realizedItems and realizedTemplates. But it can also cause behaviour that is similar to "the list view doesn't properly update". Unfortunately it is hard to reproduce.
I want to propose an enhancement to the android list-view implementation that allows to delegate calculating the id from the item itself to the listview's container/consumer (similar to the templateSelector), with a default implementation being compatible to the current version.
This applies to 3.1, and from what I can see in the code, to 3.2 as well.
The Adapter implementation on top of
BaseAdapterof the ListView wrongly implements the stable ids, it supposes to provide from its data source.According to BaseAdapter#hasStableIds() with hasStableIds() returning true "the same id always refers to the same object". In the implementation of list-view.android.ts the id used is the index of the item in the array.
That means changing the underlaying data, by reordering, filtering or entirely reloading will break the named above contract.
For us that causes app crashes because the cached views of the adapter are out of sync with realizedItems and realizedTemplates. But it can also cause behaviour that is similar to "the list view doesn't properly update". Unfortunately it is hard to reproduce.
I want to propose an enhancement to the android list-view implementation that allows to delegate calculating the id from the item itself to the listview's container/consumer (similar to the templateSelector), with a default implementation being compatible to the current version.
This applies to 3.1, and from what I can see in the code, to 3.2 as well.