Runtime layout changes can affect more than one item

[androidacy-user]

About this issue

We have some logic to change button layout and text in the item depending on user settings. We change these settings in onBindView of the ViewHolder. We would expect that to just effect the viewholder we're currently creating, but it seems to effect them at random (it does effect the wanted viewholder, but then randomly changes things in others). This applies to click actions, actions we do in onbindview, etc.

In our case, we read a value from prefs and set an install button to reinstall. That value can only be modified once user clicks an install button, so it requires user action, but random other items are affected that should not be.

Details

• [x] Used library version 5.7.0
• [ ] Used support library version
• [x] Used gradle build tools version 8.1.2
• [ ] Used tooling / Android Studio version
• [ ] Other used libraries, potential conflicting libraries

Checklist

• [x] Searched for similar issues
• [x] Checked out the sample application
• [x] Read the README
• [x] Checked out the CHANGELOG
• [x] Checked out the MIGRATION GUIDE

[androidacy-user]

Even stranger, it affects exactly every 13 items on a 300 item recyclerview 🤔 nope, just random coincedence

Putting in logging indicates our logic correctly only fires once. So why is it effecting anything else?

[androidacy-user]

This behavior also copies over to expandable items - once one sub item is expanded, any changes to it reflect on any other expanded items.

[mikepenz]

Based on the description this sounds to be related to the implementation within your app, and not to the behavior of this library itself. Keep in mind this library only focuses on the Adapter component. And general RecyclerView APIs and behaviors are outside of its scope.

Overall, based on the description, it seems that you are keeping reference to the View of an item, and modify these directly. This is not allowed to be done in RecyclerViews and any modification to the data, has to result in a notify on the adapter.

It is then in the rv's responsibility to trigger the right calls and result in rebinding the view via a call to onBindView. There you will use the new data, and update the view accordingly.

Also remember that there are different APIs which allow to notify for the change of singular items, vs multiple (or all) items.

[androidacy-user]

Based on the description this sounds to be related to the implementation within your app, and not to the behavior of this library itself. Keep in mind this library only focuses on the Adapter component. And general RecyclerView APIs and behaviors are outside of its scope.

Overall, based on the description, it seems that you are keeping reference to the View of an item, and modify these directly. This is not allowed to be done in RecyclerViews and any modification to the data, has to result in a notify on the adapter.

It is then in the rv's responsibility to trigger the right calls and result in rebinding the view via a call to onBindView. There you will use the new data, and update the view accordingly.

Also remember that there are different APIs which allow to notify for the change of singular items, vs multiple (or all) items.

Isn't that the point of your library? Handling boilerplate code? We, I think somewhat reasonably, expected your library to handle that logic, hence why we didn't just write it ourselves. If we start having to handle that logic ourselves, what's even the benefit of this library?.

We don't have a "data" structure. We're literally just modifying an icon based on if a user has selected an option previously, and flipping an icon when the item is expanded

Sorry for bothering you. Clearly you're more interested in just blaming us.

[mikepenz]

The library focuses on handling Adapter related boilerplate code, that is correct.

However it does not affect how the internals of the RecyclerView function and how Views are being reused via the ViewHolders. The reason I outlined this in my first comment is that it is a common source of problems in 95% of all reports.

You can check the sample app and see if you can reproduce your problem there.