TextWatcher: apa itu, antarmuka TextWatcher dan implementasi di Android

Apa itu TextWatcher dan untuk apa?

TextWatcher adalah antarmuka dari paket android.text yang memberi tahu aplikasi tentang perubahan teks pada objek Editable. Pada setiap input, penghapusan, atau penggantian karakter, TextWatcher secara berurutan memanggil tiga metode, mengirimkan informasi tentang posisi perubahan. Ini memungkinkan pengembang untuk bereaksi terhadap tindakan pengguna secara instan — tanpa tombol tambahan atau pemicu.

Skenario penggunaan utama mencakup validasi bidang secara real-time: memeriksa email saat setiap karakter dimasukkan, menghitung karakter yang tersisa di bidang dengan batas panjang, implementasi pencarian dengan pengiriman permintaan yang ditunda melalui debounce. TextWatcher juga digunakan untuk pemformatan input — misalnya, menempatkan spasi secara otomatis di nomor telepon atau menambahkan masker untuk tanggal.

Menurut Android Developers, TextWatcher hadir di 70% aplikasi yang bekerja dengan formulir. Pustaka seperti Material Design Components dan TextInputEditText menggunakan TextWatcher secara internal untuk mengelola status kesalahan dan menampilkan penghitung. Memahami cara kerja antarmuka ini diperlukan untuk setiap pengembang Android.

Bagaimana antarmuka TextWatcher bekerja

TextWatcher terhubung ke objek TextView atau EditText mana pun melalui metode addTextChangedListener. Saat pengguna memasukkan atau menghapus karakter, Android pertama-tama memanggil beforeTextChanged, kemudian onTextChanged, dan akhirnya afterTextChanged. Dalam parameter setiap metode, data tentang rentang yang diubah dikirimkan: posisi awal, jumlah karakter yang dihapus, dan jumlah karakter yang ditambahkan.

Penting untuk dipahami bahwa setelah afterTextChanged dipanggil, objek Editable sudah berisi nilai saat ini. Oleh karena itu, dalam afterTextChanged lebih mudah untuk memeriksa teks akhir bidang. Sampai saat itu, data belum sepenuhnya diperbarui. Pengembang sering salah memahami tujuan metode dan menggunakan onTextChanged untuk validasi akhir, padahal pilihan yang benar adalah afterTextChanged.

Fitur pemanggilan metode

Pada setiap penyisipan, penggantian, atau penghapusan karakter, rantai panggilan dijamin akan dieksekusi sepenuhnya. Namun, jika di dalam afterTextChanged teks diubah (melalui clear, append, insert), TextWatcher akan terpicu secara rekursif. Ini adalah penyebab paling umum dari StackOverflowError di formulir Android. Untuk mencegah rekursi, digunakan flag pemblokiran.

Tiga metode TextWatcher: beforeTextChanged, onTextChanged, afterTextChanged

Masing-masing dari tiga metode memainkan perannya dalam siklus hidup perubahan teks. Metode beforeTextChanged(CharSequence s, int start, int count, int after) dipanggil sebelum perubahan diterapkan. Ini mengirimkan status string saat ini, posisi awal perubahan, jumlah karakter yang akan dihapus, dan jumlah karakter yang akan ditambahkan. Di sini Anda dapat menyimpan nilai sebelumnya atau memeriksa kondisi sebelum modifikasi.

Metode onTextChanged dipanggil selama perubahan, ketika karakter telah dihapus tetapi yang baru belum dimasukkan. Parameter: teks setelah penghapusan, posisi awal, jumlah karakter yang dihapus, dan jumlah karakter yang akan ditambahkan. Metode ini berguna untuk animasi atau logging, tetapi tidak untuk bekerja dengan teks akhir saat ini — teks belum lengkap.

Metode afterTextChanged adalah yang paling banyak diminta. Metode ini menerima objek Editable dan dipanggil setelah perubahan diterapkan sepenuhnya. Dalam metode ini, Anda dapat membaca nilai akhir bidang, melakukan validasi, memperbarui UI, dan mengubah teks (dengan hati-hati karena rekursi).

Contoh implementasi TextWatcher untuk penghitungan karakter

Contoh praktis — penghitung karakter untuk bidang input yang diperbarui pada setiap perubahan teks. Elemen seperti ini sering ditemukan di formulir kontak, postingan, dan pesan dengan batas panjang. Implementasi melalui TextWatcher hanya membutuhkan beberapa baris dan tidak memerlukan pustaka pihak ketiga.

val editText = findViewById<EditText>(R.id.edit_text)
val counterText = findViewById<TextView>(R.id.counter)

editText.addTextChangedListener(object : TextWatcher {
    override fun beforeTextChanged(
        s: CharSequence?, start: Int,
        count: Int, after: Int
    ) {}

    override fun onTextChanged(
        s: CharSequence?, start: Int,
        before: Int, count: Int
    ) {}

    override fun afterTextChanged(s: Editable?) {
        val len = s?.length ?: 0
        counterText.text = "$len / 200"
    }
})

Dalam contoh, metode afterTextChanged menerima konten bidang saat ini melalui parameter s bertipe Editable. Panjang teks diperbarui di TextView terpisah. Untuk menghindari rekursi dalam kasus ini, hanya counterText yang diubah, bukan EditText itu sendiri, sehingga tidak terjadi loop. Dengan batas 200 karakter, input dapat diblokir setelah melebihi batas.

Metode beforeTextChanged dan onTextChanged tetap kosong, karena untuk menghitung panjang, status akhir sudah cukup. Jika diperlukan logging setiap perubahan, kode dapat ditambahkan ke onTextChanged. Fleksibilitas seperti itu menjadikan TextWatcher alat universal untuk setiap skenario kerja dengan input teks.

TextWatcher untuk validasi bidang secara real-time

Validasi real-time secara signifikan meningkatkan UX: pengguna melihat kesalahan segera setelah memasukkan nilai yang salah, bukan setelah menekan tombol kirim. TextWatcher memungkinkan pemeriksaan instan email, kata sandi, nomor telepon, dan bidang lainnya. Hasilnya ditampilkan melalui setError di EditText atau melalui TextView terpisah dengan pesan kesalahan.

fun validateEmail(emailEditText: EditText) {
    emailEditText.addTextChangedListener(object : TextWatcher {
        override fun afterTextChanged(s: Editable?) {
            val email = s?.toString () ?: ""
            if (email.isNotBlank() &&
                !Patterns.EMAIL_ADDRESS.matcher(email).matches()) {
                emailEditText.error = "Invalid email address"
            } else {
                emailEditText.error = null
            }
        }

        override fun beforeTextChanged(...) {}
        override fun onTextChanged(...) {}
    })
}

Dalam contoh, Patterns.EMAIL_ADDRESS bawaan dari Android SDK digunakan untuk memeriksa email. Jika teks tidak kosong dan tidak cocok dengan pola, bidang akan diberi kesalahan melalui properti error. Saat input benar, kesalahan dihapus. Penting untuk tidak menjalankan validasi pada bidang kosong — pengguna mungkin belum mulai memasukkan, dan pesan kesalahan akan menjadi prematur.

Untuk kata sandi dan nomor telepon, ekspresi reguler kustom atau pustaka khusus digunakan. Misalnya, untuk memeriksa kompleksitas kata sandi, Anda dapat menghitung jumlah digit, huruf besar dan kecil. TextWatcher memungkinkan pembaruan indikator kompleksitas kata sandi secara real-time, yang berdampak positif pada konversi pendaftaran.

Kesalahan umum saat bekerja dengan TextWatcher

Kesalahan pertama dan paling kritis — panggilan rekursif. Jika di dalam afterTextChanged teks dari EditText yang sama diubah (melalui s.clear(), s.append() atau s.insert()), TextWatcher akan terpicu lagi. Ini menciptakan loop tak terbatas yang berakhir dengan StackOverflowError. Solusinya — gunakan flag pemblokiran isUpdating atau periksa apakah teks benar-benar berubah.

Masalah umum kedua — kebocoran memori. TextWatcher berisi referensi implisit ke Activity atau Fragment melalui kelas anonim. Jika listener tidak dihapus saat View dihancurkan, garbage collector tidak dapat membebaskan memori. Solusinya — gunakan komponen siklus hidup atau panggil removeTextChangedListener secara eksplisit di onDestroyView.

Kesalahan ketiga — penggunaan metode yang salah. Beberapa pengembang melakukan validasi akhir di onTextChanged, tanpa menunggu afterTextChanged. Di onTextChanged, teks belum sepenuhnya diperbarui dan membaca nilai akhir dapat mengembalikan data yang salah. Pendekatan yang benar — tempatkan semua logika pembacaan dan pemeriksaan teks akhir di afterTextChanged.

Kesalahan keempat — penambahan TextWatcher berulang kali. Jika addTextChangedListener dipanggil beberapa kali untuk EditText yang sama, semua listener akan memproses perubahan yang sama. Di formulir dengan penambahan View secara dinamis, ini menyebabkan duplikasi pemeriksaan dan perilaku yang tidak dapat diprediksi. Selalu periksa apakah listener sudah ditambahkan sebelumnya atau gunakan satu instance.