Why ButterKnife uses a DebouncingOnClickListener for @OnClick methods?

Question

I was looking at the generated code of ButterKnife, and noticed that for @OnClick annotations it is using a DebouncingOnClickListener, implemented by the library.

What the DebouncingOnClickListener does it to avoid more than one click on any element using that listener on the same frame (to achieve this they use a static flag). You can see the implementation here.

I have tried to find an explanation on why they decided to use this for every on click event managed by the library, but could not find any.

So, why they use that? Why have they decided that every user of ButterKnife need this? Shouldn't be the user who decides to use that or not? Why couple the view binding help it provides with this "feature"? What happens if I want to receive more than one click on the same frame? I couldn't use ButterKnife for click events.

I don't pretend to be offensive, just want an explanation, maybe I am missing something.

Answer 1

Why have they decided that every user of ButterKnife need this?

Assume you have a button and a click event on this button launches a new activity. Now what will happen, when user very quickly double taps the button? There is some chance, that the click listener would be fired two times, thus 2 activities would be launched, which you most possibly do not want.

What this DebouncingOnClickListener does is it assures, that no subsequent click listener would be regarded. As soon as the first click happens, subsequent clicks would be disregarded until next frame, when they would be switched on.

When you are performing an action with a view, you are posting an event on the MessageQueue. Now, when first click happens, you are posting an event - launch new activity. And you are immediately posting another event - enable click listener, on the next frame. The second event is guaranteed to happen after the first one, because is has been post()ed to the queue.

What happens if I want to receive more than one click on the same frame?

If it is acceptable for you to receive multiple subsequent click events, than you should use @OnTouch, because you are interested in touch event and not in click events.

---

Listen to @Piwai's clarification concerning the case at Fragmented Podcast #88 (starting from 38:20).