TextWatcher: ano ito, interface ng TextWatcher at implementasyon sa Android

Ano ang TextWatcher at para saan ito?

TextWatcher ay isang interface mula sa package na android.text na nag-aabiso sa aplikasyon tungkol sa mga pagbabago sa teksto sa mga bagay na Editable. Sa bawat input, pagtanggal, o pagpapalit ng karakter, sunod-sunod na tinatawagan ng TextWatcher ang tatlong pamamaraan, na nagpapadala ng impormasyon tungkol sa posisyon ng mga pagbabago. Ito ay nagpapahintulot sa developer na tumugon sa mga aksyon ng user kaagad — nang walang mga karagdagang pindutan o trigger.

Ang mga pangunahing senaryo ng paggamit ay kinabibilangan ng real-time na pag-validate ng field: pagsusuri ng email sa bawat input ng karakter, pagbibilang ng natitirang mga karakter sa isang field na may limitasyon sa haba, implementasyon ng paghahanap na may naantalang pagpapadala ng kahilingan sa pamamagitan ng debounce. Ginagamit din ang TextWatcher para sa pag-format ng input — halimbawa, awtomatikong paglalagay ng mga puwang sa numero ng telepono o pagdaragdag ng mask para sa petsa.

Ayon sa Android Developers, ang TextWatcher ay naroroon sa 70% ng mga aplikasyon na nagtatrabaho sa mga form. Ang mga library tulad ng Material Design Components at TextInputEditText ay gumagamit ng TextWatcher sa loob para sa pamamahala ng estado ng error at pagpapakita ng mga counter. Ang pag-unawa sa paggana ng interface na ito ay kinakailangan para sa bawat developer ng Android.

Paano gumagana ang interface ng TextWatcher

Ang TextWatcher ay kumokonekta sa anumang bagay na TextView o EditText sa pamamagitan ng pamamaraang addTextChangedListener. Kapag ang user ay nag-input o nagtanggal ng karakter, tinatawagan muna ng Android ang beforeTextChanged, pagkatapos ay onTextChanged, at sa wakas ay afterTextChanged. Sa mga parameter ng bawat pamamaraan, ipinapadala ang data tungkol sa saklaw na binago: panimulang posisyon, bilang ng mga tinanggal na karakter, at bilang ng mga idinagdag na karakter.

Mahalagang maunawaan na pagkatapos tawagan ang afterTextChanged, ang bagay na Editable ay naglalaman na ng kasalukuyang halaga. Kaya naman sa afterTextChanged ay maginhawang suriin ang huling teksto ng field. Hanggang sa sandaling iyon, ang data ay hindi pa ganap na na-update. Madalas na nalilito ng mga developer ang layunin ng mga pamamaraan at ginagamit ang onTextChanged para sa huling pag-validate, kahit na ang tamang pagpili ay afterTextChanged.

Mga tampok ng pagtawag ng mga pamamaraan

Sa bawat pagpasok, pagpapalit, o pagtanggal ng karakter, ang chain ng pagtawag ay garantisadong ganap na maipapatupad. Gayunpaman, kung sa loob ng afterTextChanged ang teksto ay binago (sa pamamagitan ng clear, append, insert), ang TextWatcher ay ma-t-trigger nang recursive. Ito ang pinakakaraniwang sanhi ng StackOverflowError sa mga form ng Android. Para maiwasan ang recursion, ginagamit ang isang blocking flag.

Tatlong pamamaraan ng TextWatcher: beforeTextChanged, onTextChanged, afterTextChanged

Ang bawat isa sa tatlong pamamaraan ay gumaganap ng kaniyang papel sa lifecycle ng pagbabago ng teksto. Ang pamamaraang beforeTextChanged(CharSequence s, int start, int count, int after) ay tinatawag bago ilapat ang mga pagbabago. Ipinapadala nito ang kasalukuyang estado ng string, panimulang posisyon ng pagbabago, bilang ng mga karakter na tatanggalin, at bilang ng mga karakter na idadagdag. Dito maaaring i-save ang nakaraang halaga o suriin ang mga kondisyon bago ang modipikasyon.

Ang pamamaraang onTextChanged ay tinatawag habang nagbabago, kapag ang mga karakter ay natanggal na ngunit ang mga bago ay hindi pa naipapasok. Mga parameter: teksto pagkatapos ng pagtanggal, panimulang posisyon, bilang ng mga tinanggal na karakter, at bilang ng mga idadagdag na karakter. Ang pamamaraang ito ay kapaki-pakinabang para sa animation o logging, ngunit hindi para sa pagtatrabaho sa kasalukuyang huling teksto — hindi pa ito kumpleto.

Ang pamamaraang afterTextChanged ay ang pinaka-hinihingi. Ito ay tumatanggap ng isang bagay na Editable at tinatawag pagkatapos na ganap na mailapat ang mga pagbabago. Sa pamamaraang ito, maaaring basahin ang huling halaga ng field, magsagawa ng pag-validate, mag-update ng UI, at magbago ng teksto (nang may pag-iingat dahil sa recursion).

Halimbawa ng implementasyon ng TextWatcher para sa pagbibilang ng karakter

Praktikal na halimbawa — isang tagabilang ng karakter para sa input field na nag-a-update sa bawat pagbabago ng teksto. Ang ganitong elemento ay madalas na matatagpuan sa mga contact form, post, at mensahe na may limitasyon sa haba. Ang implementasyon sa pamamagitan ng TextWatcher ay nangangailangan lamang ng ilang linya at hindi nangangailangan ng mga third-party na library.

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"
    }
})

Sa halimbawa, ang pamamaraang afterTextChanged ay tumatanggap ng kasalukuyang nilalaman ng field sa pamamagitan ng parameter s na uri ng Editable. Ang haba ng teksto ay na-update sa isang hiwalay na TextView. Upang maiwasan ang recursion sa kasong ito, ang counterText lamang ang binago, hindi ang EditText mismo, kaya walang loop na nalikha. Sa limitasyon na 200 karakter, maaaring harangan ang input pagkatapos lumampas.

Ang mga pamamaraang beforeTextChanged at onTextChanged ay mananatiling walang laman, dahil para sa pagbibilang ng haba, sapat na ang huling estado. Kung kinakailangan ang logging ng bawat pagbabago, ang code ay maaaring idagdag sa onTextChanged. Ang ganitong flexibility ay gumagawa ng TextWatcher na isang unibersal na kasangkapan para sa anumang senaryo ng pagtatrabaho sa text input.

TextWatcher para sa real-time na pag-validate ng field

Ang real-time na pag-validate ay makabuluhang nagpapabuti sa UX: nakikita ng user ang error kaagad pagkatapos mag-input ng maling halaga, hindi pagkatapos pindutin ang send button. Ang TextWatcher ay nagbibigay-daan sa agarang pagsusuri ng email, password, numero ng telepono, at iba pang mga field. Ang resulta ay ipinapakita sa pamamagitan ng setError sa EditText o sa pamamagitan ng hiwalay na TextView na may mensahe ng error.

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(...) {}
    })
}

Sa halimbawa, ginagamit ang built-in na Patterns.EMAIL_ADDRESS mula sa Android SDK para sa pagsusuri ng email. Kung ang teksto ay hindi walang laman at hindi tumutugma sa pattern, ang field ay bibigyan ng error sa pamamagitan ng property na error. Sa tamang input, ang error ay tinatanggal. Mahalagang huwag patakbuhin ang pag-validate sa isang walang laman na field — ang user ay maaaring hindi pa nagsimulang mag-input, at ang mensahe ng error ay magiging maaga.

Para sa mga password at numero ng telepono, ginagamit ang custom na regular expression o mga espesyalisadong library. Halimbawa, para sa pagsusuri ng pagiging kumplikado ng password, mabibilang ang bilang ng mga digit, malaki at maliit na titik. Ang TextWatcher ay nagbibigay-daan sa pag-update ng indicator ng pagiging kumplikado ng password sa real-time, na may positibong epekto sa conversion ng pagpaparehistro.

Mga karaniwang pagkakamali kapag nagtatrabaho sa TextWatcher

Ang una at pinaka-kritikal na pagkakamali — recursive na pagtawag. Kung sa loob ng afterTextChanged ang teksto ng parehong EditText ay binago (sa pamamagitan ng s.clear(), s.append() o s.insert()), ang TextWatcher ay ma-t-trigger muli. Ito ay lumilikha ng walang katapusang loop na nagtatapos sa StackOverflowError. Ang solusyon — gumamit ng blocking flag na isUpdating o suriin kung ang teksto ay talagang nagbago.

Ang pangalawang karaniwang problema — tagas ng memorya. Ang TextWatcher ay naglalaman ng implicit na sanggunian sa Activity o Fragment sa pamamagitan ng isang anonymous na klase. Kung ang listener ay hindi tinanggal kapag ang View ay nawasak, ang garbage collector ay hindi makakapagpalaya ng memorya. Ang solusyon — gumamit ng lifecycle component o tahasang tawagan ang removeTextChangedListener sa onDestroyView.

Ang pangatlong pagkakamali — paggamit ng maling pamamaraan. Ang ilang mga developer ay nagsasagawa ng huling pag-validate sa onTextChanged, nang hindi naghihintay ng afterTextChanged. Sa onTextChanged, ang teksto ay hindi pa ganap na na-update at ang pagbabasa ng huling halaga ay maaaring magbalik ng maling data. Ang tamang diskarte — ilagay ang lahat ng lohika ng pagbabasa at pagsusuri ng huling teksto sa afterTextChanged.

Ang pang-apat na pagkakamali — paulit-ulit na pagdaragdag ng TextWatcher. Kung ang addTextChangedListener ay tinawag nang maraming beses para sa parehong EditText, lahat ng listener ay magpoproseso ng parehong pagbabago. Sa mga form na may dynamic na pagdaragdag ng View, ito ay humahantong sa pagdoble ng mga pagsusuri at hindi mahuhulaan na pag-uugali. Palaging suriin kung ang listener ay naidagdag na dati o gumamit ng iisang instance.