-
Notifications
You must be signed in to change notification settings - Fork 729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block clicks on views that are being removed #293
Comments
I have some free time I'll hop on this. Let's save the debounce support for another issue, but I'm all for supporting debouncing! |
Great! The easiest way to do this now would be to change That would be a very easy change, but it only helps people that used When we want to do the debouncing we would also change Butterknife uses a post, but I'm wondering if just checking system clock is more efficient, and also if we may want to delay slightly longer, since requests to rebuild epoxy models are async and posted a frame later, so any changes do the adapter due to a click would take a frame to get notified (even longer if we add diffing) |
Thanks for the detailed feedback! I'll touch on the two topics here. Blocking ClicksThe code change itself is minute, but the interesting aspect here is refactoring to allow for click tests to pass. I'll throw up my code once I'm back on my laptop for your guidance, and to give clarity into what I mean. Debouncing ClicksI was planning on doing it the ButterKnife way originally but you bring up a great point with using the system clock + the extra required delay. I think we can solve this by creating a custom handler and using a combination of both ideas. I think it would look like: public class DebounceHandler extends Handler {
private long debounceTime;
private long lastPosted;
@Override
public void post(Runnable r) {
// If lastPosted - currentTime < debounceTime -> remove message
// Update last posted time.
// Store runnable in map
// PostDelay message by debounce time
}
} On my mobile phone and haven't thought it out filly yet but this might suffice |
Adding a RecyclerView.NO_POSITION != viewHolder.getAdapterPosition() check inside of the click listener wrapper ensures we do not call the click listener when the item is going through a layout. There was a need to make a change to the ControllerLifecycleHelper to ensure that click still passed as the adapter was always supplying `NO_POSITION` for unit tests. The simplest way to get the basic functionality was to spy the viewHolder, and stub this method. ISSUE airbnb#293
Adding a RecyclerView.NO_POSITION != viewHolder.getAdapterPosition() check inside of the click listener wrapper ensures we do not call the click listener when the item is going through a layout. There was a need to make a change to the ControllerLifecycleHelper to ensure that click still passed as the adapter was always supplying `NO_POSITION` for unit tests. The simplest way to get the basic functionality was to spy the viewHolder, and stub this method. ISSUE #293
Closed this since it is fixed, lets take the debounce discussion to #305 |
A handler does synchronization and other in depth stuff under the hood to post, just checking the system clock might be good enough |
We can check that position != NO_POSITION in our click listener wrapper.
I am also considering adding some debouncing support
The text was updated successfully, but these errors were encountered: