You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Item IDs have a problem, which is ensuring composed adapters with stable item IDs form a composite adapter whose ID ranges don't accidentally overlap. If they overlapped it'd result in strange behavior in RecyclerView, which would be difficult to debug. We also don't want users to have to worry about stable IDs outside of overriding getItemId().
Consider this related problem: what if your model IDs are strings? Many systems use UUIDs.
My thoughts right now are to change PowerAdapter.getItemId() to return an Object instead. Since an Object is unique in the system, any headers/footers would automatically have a stable ID. The challenge is how to map the objects into a range of longs in a way that isn't prone to memory leaks, and has decent performance.
The text was updated successfully, but these errors were encountered:
Item IDs have a problem, which is ensuring composed adapters with stable item IDs form a composite adapter whose ID ranges don't accidentally overlap. If they overlapped it'd result in strange behavior in
RecyclerView
, which would be difficult to debug. We also don't want users to have to worry about stable IDs outside of overridinggetItemId()
.Consider this related problem: what if your model IDs are strings? Many systems use UUIDs.
My thoughts right now are to change
PowerAdapter.getItemId()
to return anObject
instead. Since anObject
is unique in the system, any headers/footers would automatically have a stable ID. The challenge is how to map the objects into a range of longs in a way that isn't prone to memory leaks, and has decent performance.The text was updated successfully, but these errors were encountered: