Introduction

In Android, listening for text changes usually means attaching a TextWatcher to an EditText. The three callbacks look similar at first, but each one fires at a different moment, so choosing the right callback makes the code simpler and avoids accidental recursion or unnecessary work.

Use TextWatcher for Real-Time Input Reactions

TextWatcher gives you three methods: beforeTextChanged, onTextChanged, and afterTextChanged.

1import android.text.Editable
2import android.text.TextWatcher
3import android.widget.EditText
4
5fun attachWatcher(editText: EditText) {
6    editText.addTextChangedListener(object : TextWatcher {
7        override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) {
8            // old value is still visible here
9        }
10
11        override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {
12            // text is changing right now
13        }
14
15        override fun afterTextChanged(s: Editable?) {
16            // final editable content is available here
17        }
18    })
19}

A common rule is to put simple UI reactions in onTextChanged and logic that depends on the final editable text in afterTextChanged.

A Practical Validation Example

Live form validation is one of the most common use cases.

1emailEditText.addTextChangedListener(object : TextWatcher {
2    override fun beforeTextChanged(s: CharSequence?, start: Int, count: Int, after: Int) = Unit
3
4    override fun onTextChanged(s: CharSequence?, start: Int, before: Int, count: Int) {
5        saveButton.isEnabled = !s.isNullOrBlank()
6    }
7
8    override fun afterTextChanged(s: Editable?) {
9        val text = s?.toString().orEmpty()
10        emailLayout.error = if ('@' in text || text.isEmpty()) null else "Invalid email"
11    }
12})

This separates two concerns: enabling the button immediately while showing validation feedback after the change is complete.

Avoid Heavy Work on Every Keystroke

Network calls, database queries, or expensive filtering should not run on every character change without some control. Search boxes often need debouncing so the app waits briefly before firing the expensive action.

TextWatcher itself does not provide debouncing, so you usually combine it with a Handler, coroutines, RxJava, or another scheduling tool.

The principle is simple: react immediately for cheap UI changes, but delay or batch expensive work.

Be Careful When Modifying the Same Text

Changing the text of the same EditText from inside afterTextChanged can trigger the watcher again and create loops.

A common safe pattern is to temporarily remove the watcher, apply the text formatting, and then add it back, or use a guard flag.

This matters when you implement auto-formatting such as phone numbers, card numbers, or uppercase normalization.

Kotlin Extensions and Simpler APIs

If you use Android KTX or other helper libraries, you may see shorthand listener helpers. Those can improve readability, but under the hood the concept is still the same: you are responding to text-change events with a TextWatcher-style mechanism.

It is worth understanding the base API first because debugging eventually leads back to it.

If a watcher is attached inside a view that is recreated often, such as a recycled row or a fragment view, be deliberate about when it is added and removed. Reattaching watchers carelessly can duplicate callbacks and make debugging text behavior surprisingly difficult.

Common Pitfalls

Putting expensive work in onTextChanged without throttling can make typing feel slow.

Updating the same field inside afterTextChanged without a guard can create recursive listener behavior.

Using all three callbacks when only one is needed makes the code harder to follow.

Summary

• Use TextWatcher to react to EditText changes.
• Pick the callback that matches the stage of the change you actually care about.
• Keep per-keystroke work lightweight and debounce expensive operations.
• Be careful when changing the same text from inside the watcher.