Introduction

In Android, preventing a double click usually means preventing the same action from firing twice before the first one finishes. This matters for navigation, payment submission, network requests, and any action where duplicate taps can create duplicate work.

The safest fix is not just to make the button look disabled for a moment. You need to decide whether the right behavior is click debouncing, temporary disabling, or protecting the underlying business logic against duplicate execution.

The Simple Debounce Approach

A common UI-level solution is to ignore taps that happen too close together. In Kotlin, a click listener wrapper works well:

1import android.os.SystemClock
2import android.view.View
3
4class SingleClickListener(
5    private val intervalMs: Long = 800,
6    private val onSingleClick: (View) -> Unit
7) : View.OnClickListener {
8
9    private var lastClickTime: Long = 0
10
11    override fun onClick(v: View) {
12        val now = SystemClock.elapsedRealtime()
13        if (now - lastClickTime < intervalMs) return
14
15        lastClickTime = now
16        onSingleClick(v)
17    }
18}

Usage:

1submitButton.setOnClickListener(
2    SingleClickListener {
3        submitOrder()
4    }
5)

This is easy to reuse and works well for most accidental double-tap cases.

Why elapsedRealtime() Is Better Than Wall Clock Time

For debounce logic, use SystemClock.elapsedRealtime() rather than System.currentTimeMillis(). Wall-clock time can jump if the user changes the device clock or if the system syncs time. Elapsed realtime only moves forward, which makes it better for measuring tap intervals.

That detail matters more than it first appears. A debounce check based on wall-clock time can behave strangely after time changes.

Temporarily Disabling the Button

If the button starts a real operation such as an API request, disabling it until the operation completes is often better than a pure time-based debounce.

1submitButton.setOnClickListener {
2    submitButton.isEnabled = false
3
4    lifecycleScope.launch {
5        try {
6            submitOrderToServer()
7        } finally {
8            submitButton.isEnabled = true
9        }
10    }
11}

This pattern communicates clearly to the user that the action is already in progress.

It also handles the case where the first action takes longer than the debounce window. A hardcoded 800 millisecond delay may not be enough if the user can still trigger the same operation again while the first request is running.

Protect the Action, Not Just the Button

UI protection is useful, but it is not enough on its own. If the underlying action must never happen twice, guard it in your state or business logic too.

For example:

1private var submitting = false
2
3private fun submitOrder() {
4    if (submitting) return
5    submitting = true
6
7    lifecycleScope.launch {
8        try {
9            submitOrderToServer()
10        } finally {
11            submitting = false
12        }
13    }
14}

This helps even if the action can be triggered from somewhere other than the button, such as keyboard input, accessibility interactions, or another code path.

A Reusable Extension Function

If you prefer a lighter call site, use an extension function:

1import android.os.SystemClock
2import android.view.View
3
4fun View.setDebouncedClickListener(
5    intervalMs: Long = 800,
6    onClick: (View) -> Unit
7) {
8    var lastClickTime = 0L
9
10    setOnClickListener { view ->
11        val now = SystemClock.elapsedRealtime()
12        if (now - lastClickTime >= intervalMs) {
13            lastClickTime = now
14            onClick(view)
15        }
16    }
17}

Then call it like this:

submitButton.setDebouncedClickListener {
    submitOrder()
}

This keeps button setup clean without repeating the timing logic everywhere.

Common Pitfalls

The biggest pitfall is solving only the UI symptom. If a duplicate submission would be dangerous, the underlying action should also be idempotent or otherwise protected against repeated execution.

Another common mistake is re-enabling the button too early, such as immediately after starting an asynchronous request rather than after the request finishes.

Developers also sometimes use a global static click guard that blocks unrelated buttons. Debounce state should normally be scoped to the specific action or view.

Finally, do not forget user feedback. If the button is disabled or taps are ignored, show progress or a visual state change so the app does not feel broken.

Summary

• For accidental double taps, a debounced click listener is often enough.
• Use SystemClock.elapsedRealtime() for interval checks instead of wall-clock time.
• For real async work, disabling the button until completion is often better than a fixed delay.
• Protect critical actions in business logic too, not only at the button level.
• Give users feedback when an action is already in progress so ignored taps make sense.