Error State — ano ito, pagpapakita ng mga error sa field at pagpapatupad sa Android

Ano ang estado ng error ng field sa Android?

Error State ay isang espesyal na mode ng pagpapakita ng input field na nag-a-activate kapag ang inilagay na data ay hindi pumasa sa validation. Biswal, ang Error State ay may tatlong bahagi: pagbabago ng kulay ng border o background ng field (karaniwang pula), paglitaw ng text message sa ilalim ng field na may paglalarawan ng error, at opsyonal — isang icon o highlight. Ang layunin ng Error State ay agad na makuha ang atensyon ng user sa problematikong field at magmungkahi kung paano ayusin ang error.

Sa Android, ang Error State ay ipinapatupad sa antas ng TextInputLayout mula sa Material Design Components. Binabalot ng TextInputLayout ang EditText at pinamamahalaan ang mga estado nito: normal, focused, error, disabled. Ang setError(String) na pamamaraan ay nagpapalipat ng field sa error state, nagpapalit ng kulay ng border, at nagpapakita ng mensahe. Sa pagbabago ng text o pagtawag ng setError(null), ang field ay bumabalik sa normal.

Ayon sa Material Design Guidelines, ang Error State ay dapat kapansin-pansin ngunit hindi dominante. Ang pulang kulay ng border ay dapat mag-contrast sa normal na estado ngunit hindi mag-overload sa interface. Ang error message ay dapat maglaman ng tiyak na impormasyon tungkol sa problema at kung paano ito lutasin. Ang icon ng error (halimbawa, pulang bilog na may tandang padamdam) ay nagpapatibay ng visual signal.

Paano gumagana ang setError sa TextInputLayout

Ang pamamaraang setError(CharSequence errorText) ay nagpapalipat ng TextInputLayout sa error state. Ang parameter na errorText ay ang text na ipinapakita sa ilalim ng field. Kung ang null ay ipinasa, ang error ay nire-reset. Pinamamahalaan ng TextInputLayout ang animation: ang error text ay lumilitaw nang may maayos na paglipat, ang border ay nagiging pula. Ang icon ng error (default ay tandang padamdam sa bilog) ay ipinapakita sa dulo ng field.

Mahahalagang detalye: Ang setErrorEnabled(true) ay dapat tawagan bago ang setError upang magreserba ng espasyo para sa error message. Kung hindi, ang layout ay maaaring tumalon kapag lumitaw ang error dahil ang espasyo para sa mensahe ay hindi naka-reserba. Inirerekomenda na laging paganahin ang suporta sa error sa XML sa pamamagitan ng app:errorEnabled="true" upang maiwasan ang paggalaw ng layout.

Ang setError na pamamaraan ay awtomatikong nagre-reset sa pagbabago ng text ng field kung ang opsyon na setErrorEnabled(true) ay pinagana. Ang pag-uugaling ito ay maginhawa para sa real-time na validation: sa sandaling simulan ng user na itama ang error, ang pulang border ay nawawala at ang field ay bumabalik sa normal na estado. Gayunpaman, para sa mga komplikadong senaryo, ang auto-reset na ito ay maaaring hindi kanais-nais — sa mga ganitong kaso, pamahalaan ang error nang manu-mano.

val til = findViewById<TextInputLayout>(R.id.til_email)

// Paganahin ang suporta sa error (itakda sa XML kung hindi)
til.isErrorEnabled = true

// Itakda ang mensahe ng error
til.error = "Invalid email address"

// I-clear ang error
til.error = null

// Suriin kung may error
if (til.error != null) {
    // Ang field ay nasa error state
}

Sa halimbawa, ginagamit ang mga property ng Kotlin para sa pag-access sa setError/isErrorEnabled. Ang TextInputLayout ay awtomatikong nag-a-update ng UI: nagpapalit ng kulay ng boxStrokeColor, nagpapakita ng icon ng error, nagpapakita ng error text. Kung babaguhin mo ang text sa EditText, ang error ay awtomatikong nagre-reset. Para sa manu-manong pag-reset, itakda ang error = null.

Mga alternatibong paraan ng pagpapakita ng error

Hindi lahat ng proyekto ay gumagamit ng Material Design Components. Para sa custom na pagpapakita ng error, maaari kang gumamit ng hiwalay na TextView sa ilalim ng EditText na nagiging visible kapag may error. Ang pamamaraang ito ay nagbibigay ng buong kontrol sa mga estilo at posisyon ng mensahe. Halimbawa, maaari mong ilagay ang mensahe sa kanan ng field, gumamit ng ibang kulay ng background, o magdagdag ng icon sa kaliwa ng text.

Sa Jetpack Compose, ang Error State ay ipinapatupad sa pamamagitan ng parameter na isError sa OutlinedTextField o TextField. Kapag ang isError = true, ang border ay nagiging pula at maaari mong ipakita ang error text sa pamamagitan ng supportingText. Ang Compose ay walang built-in na auto-clear sa pagbabago ng text — ang developer ay namamahala ng error state nang manu-mano sa pamamagitan ng remember at mutableStateOf.

Para sa group error (isang mensahe para sa maraming field, halimbawa “Punan ang lahat ng kinakailangang field”) ay ginagamit ang Snackbar, Dialog, o isang inline block sa itaas ng form. Ang group error ay hindi pumapalit sa Error State ng mga indibidwal na field kundi nagpupuno dito. Unang nakikita ng user ang pangkalahatang mensahe, pagkatapos ay hinahanap ang mga tiyak na field na may error.

Mga kulay, icon at animation ng error

Ang kulay ng Error State sa Material Design Components ay pinamamahalaan sa pamamagitan ng attribute na boxStrokeErrorColor o attribute na colorError sa theme. Bilang default, ginagamit ang sistemang pulang kulay, ngunit maaari itong i-override sa theme ng app o direkta sa TextInputLayout sa pamamagitan ng app:boxStrokeErrorColor="@color/customErrorColor". Para sa suporta ng dark theme, inirerekomenda na gumamit ng selector na may iba't ibang kulay para sa light at dark mode.

Icon ng error ay nako-configure sa pamamagitan ng app:errorIconDrawable. Bilang default, ang tandang padamdam sa bilog ay ipinapakita. Maaari itong palitan ng custom na icon o ganap na alisin sa pamamagitan ng pagtatakda ng app:errorIconDrawable="@null". Ang icon ay ipinapakita sa dulo ng TextInputLayout at nagsisilbing karagdagang visual marker. Sa Material Design 3, ang icon ng error ay kinakailangan para sa accessibility.

Animation ng paglitaw ng error ay built-in sa TextInputLayout: ang text ay lumalabas mula sa ibaba na may maayos na pagbabago ng opacity. Para sa custom na animation, gamitin ang Transition API o MotionLayout. Halimbawa, ang pag-alog ng field kapag may error ay nakakaakit ng karagdagang atensyon. Ngunit ang labis na paggamit ng animation ay nagpapalala ng UX — sapat na ang maayos na paglitaw ng mensahe.

Pamamahala ng estado ng error sa panahon ng validation

Ang pamamahala ng Error State ay nahahati sa dalawang yugto: pagtatakda ng error sa panahon ng validation ng field at pag-reset ng error sa pagwawasto. Sa pinakasimpleng kaso, ang validation ay tinatawag sa TextWatcher.afterTextChanged: kung ang halaga ay hindi wasto, ang setError ay tinatawag na may error message. Kung wasto — setError(null). Awtomatikong itinago ng TextInputLayout ang error kapag nire-reset ng setError(null) ang estado.

Para sa validation ng form, ang mga error ay itinatakda sa yugto ng pagsusumite ng form. Pag-ulit sa lahat ng field, pagsuri sa bawat isa, pagtatakda ng mga error para sa mga hindi wastong field, at pag-focus sa unang field na may error. Ang submit button ay naka-block sa panahong ito. Kung malaki ang form, inirerekomenda na i-scroll ang screen sa unang field na may error at awtomatikong mag-focus dito.

Ang panuntunang single error focus: kapag nagsusumite ng form, itakda ang focus lamang sa unang field na may error. Itinatama ng user ang isang error sa bawat pagkakataon, at pagkatapos ng pagwawasto, ang susunod na field na may error ay awtomatikong makakatanggap ng focus. Ang step-by-step na pamamaraang ito ay nagbabawas ng cognitive load. Ang Material TextInputLayout ay hindi humaharang ng focus kapag nagtatakda ng error — ito ay dapat gawin nang manu-mano sa pamamagitan ng requestFocus().

Mga pagkakamali sa pagtatrabaho sa Error State

Unang pagkakamali — kawalan ng isErrorEnabled. Kung ang setErrorEnabled ay hindi tinawag bago ang setError, ang layout ay maaaring gumalaw kapag lumitaw ang error message. Ito ay lalong kritikal kung ang field ay nasa gitna ng screen — nawawala ang scroll position ng user. Palaging paganahin ang setErrorEnabled(true) sa XML sa pamamagitan ng app:errorEnabled="true" o programmatically bago itakda ang error.

Pangalawang pagkakamali — masyadong mahabang error message. Ang mahabang text ay bumabalot sa maraming linya at maaaring tumakip sa mga katabing field. Ang inirerekomendang haba ng error message ay 20-40 karakter. Kung kailangan ng mas maraming impormasyon, gamitin ang helperText (pahiwatig) sa normal na estado o tooltip para sa karagdagang paliwanag. Ang pagiging maikli ay pundasyon ng isang mahusay na Error State.

Pangatlong pagkakamali — pagbabalewala ng accessibility. Ang Error State ay dapat ma-access ng mga screen reader. Awtomatikong inaannounce ng TextInputLayout ang error sa pamamagitan ng contentDescription, ngunit ang mga custom na implementasyon ay dapat gawin ito nang manu-mano. Gamitin ang announceForAccessibility() o android:importantForAccessibility para sa mga error message. Ang mga gumagamit ng TalkBack ay dapat makarinig ng error kaagad pagkatapos itong lumitaw.