Validate: ano ito, pag-validate ng mga input field at implementasyon sa Android

Ano ang pag-validate ng field sa Android?

Pag-validate ng field — ay ang pagsusuri ng isang partikular na halaga na inilagay ng user para sa pagsunod sa itinakdang mga patakaran. Bawat field ay may sariling uri ng data: email, numero, telepono, password, teksto. Para sa bawat uri ay may sariling pamantayan: format, haba, saklaw ng halaga, obligasyon. Ang pag-validate ng field ay sumasagot sa tanong: tama ba ang input sa field na ito?

Ang pagkakaiba sa pagitan ng pag-validate ng field at pag-validate ng form ay ang field ay sinusuri nang hiwalay sa ibang mga field. Ang email ay sinusuri ayon sa pattern ng email, telepono — ayon sa pattern ng telepono. Kung ang field ay hindi wasto, nakikita ng user ang error para mismo sa field na iyon. Ang form ay maaaring manatiling hindi naipadala kahit isang field ay hindi pumasa sa pagsusuri. Ang pag-validate ng field ay ang building block para sa kumpletong pag-validate ng form.

Ayon sa pananaliksik sa UX, inaasahan ng mga user na makita ang error sa pag-validate nang hindi lalampas sa 1-2 segundo pagkatapos ng pagtatapos ng input. Ang pagkaantala ng higit sa 3 segundo ay itinuturing na problema sa application. Kaya naman ang real-time na pag-validate sa pamamagitan ng TextWatcher ay mas gusto kaysa sa pagsusuri lamang kapag pinindot ang send button.

Mga pangunahing paraan ng pag-validate ng field

May tatlong pangunahing approach sa pag-validate ng field sa Android. Una — manu-manong pagsusuri sa pamamagitan ng conditional operators (if, when). Ang developer ay nagsusulat ng function na tumatanggap ng string at nagbabalik ng Boolean o mensahe ng error. Ang approach na ito ay nagbibigay ng kumpletong kontrol sa lohika, ngunit nangangailangan ng pagsulat ng code para sa bawat field at bawat kondisyon.

Ikalawang approach — paggamit ng built-in na Android class. Halimbawa, sinusuri ng Patterns.EMAIL_ADDRESS.matcher(email).matches() ang email ayon sa standard pattern. Patterns.PHONE.matcher(phone).matches() — numero ng telepono. TextUtils.isEmpty() — sinusuri ang kawalan ng laman. Ang mga pamamaraang ito ay sumasaklaw sa mga pangunahing sitwasyon nang hindi kumokonekta ng mga external na dependency.

Ikatlong approach — mga library ng pag-validate. Ang mga library tulad ng InputValidator, AndroidValidator o Commons Validator ay nagbibigay ng mga handa na annotation at chain ng pagsusuri. Inilalarawan ng developer ang mga patakaran nang deklaratibo: @Email, @NotEmpty, @MinLength(6). Ang library mismo ang nagsasagawa ng pagsusuri at nagbabalik ng listahan ng mga error. Pinapabilis nito ang pag-develop, ngunit nagdaragdag ng dependency.

Pag-validate ng email, telepono at password

Para sa email, ang standard na pagsusuri ay kinabibilangan ng pagkakaroon ng @ simbolo, bahagi ng domain at kawalan ng mga espasyo at Cyrillic. Ang Android ay nagbibigay ng Patterns.EMAIL_ADDRESS, na sumasaklaw sa karamihan ng mga lehitimong email address. Gayunpaman, kung kinakailangan ang partikular na pagsusuri (halimbawa, corporate domain lamang), kailangang sumulat ng custom na regular expression. Ang email ay naba-validate pagkatapos ng pagtatapos ng input, hindi pagkatapos ng bawat karakter.

Numero ng telepono ay sinusuri ayon sa mask ng bansa o rehiyon. Para sa mga internasyonal na numero, ginagamit ang format na E.164: +code ng bansa, code ng operator, numero. Ang library na libphonenumber mula sa Google ay ang industry standard para sa pag-validate ng telepono. Tinutukoy nito ang bansa ayon sa code, sinusuri ang haba at format ng numero. Sa Android, maaari mong gamitin ang PhoneNumberUtils.isGlobalPhoneNumber para sa pangunahing pagsusuri.

Password ay may ilang pamantayan ng pagiging kumplikado: minimum na haba, pagkakaroon ng malaki at maliit na titik, numero, espesyal na simbolo. Sa Android, walang built-in na class para sa pagsusuri ng password — bawat proyekto ay tumutukoy ng sarili nitong mga kinakailangan. Karaniwan, ang password ay sinusuri sa pamamagitan ng regular expression o isang set ng mga kondisyon. Mahalagang huwag ibunyag ang eksaktong mga kinakailangan sa mensahe ng error: “Masyadong simple ang password” ay mas mahusay kaysa sa “Kinakailangan ang malaking titik at numero”.

data class ValidationResult(
    val isValid: Boolean,
    val errorMessage: String? = null
)

fun validatePassword(password: String): ValidationResult {
    if (password.length < 6)
        return ValidationResult(false, "Minimum 6 characters")
    if (!password.any { it.isUpperCase() })
        return ValidationResult(false, "Uppercase letter required")
    return ValidationResult(true)
}

Sa halimbawa, ang validatePassword ay nagbabalik ng ValidationResult na may field na isValid at opsyonal na mensahe ng error. Ang approach na ito ay maginhawa para sa komposisyon: maraming pagsusuri ang ginagawa nang sunud-sunod at ang unang nakitang error ay ibinabalik. Ang pag-validate ng email at telepono ay binuo sa parehong prinsipyo — bawat isa ay nagbabalik ng resulta na may mensahe o tagumpay.

Kailan gagawin ang pag-validate?

Ang oras ng pag-validate ay kritikal na nakakaapekto sa UX. May tatlong estratehiya: pag-validate pagkatapos ng bawat karakter (instant), pagkatapos mawalan ng focus (onFocusLost) at sa pagpapadala ng form (onSubmit). Bawat estratehiya ay angkop para sa iba't ibang sitwasyon. Ang instant na pag-validate ay mabuti para sa mga field na may mahigpit na limitasyon — numero ng telepono, PIN code. OnFocusLost — para sa email at pangalan. OnSubmit — para sa mga mandatoryong field.

Ayon sa Material Design Guidelines, inirerekomenda na pagsamahin ang mga estratehiya: ang field ay dapat suriin sa pagkawala ng focus, pati na rin sa pagpapadala ng form. Ang instant na pag-validate ay angkop kapag ang limitasyon ay halata — halimbawa, ang maximum na haba ng field. Kung magpapakita ng error pagkatapos ng bawat karakter para sa email, makikita ng user ang mensahe bago matapos ang input. Ito ay nakakainis at nagbabawas ng conversion.

Ang patakaran ng unang error: sa pagpapadala ng form, magpakita lamang ng error para sa unang hindi wastong field. Huwag bombahin ang user ng listahan ng 10 error. Pagkatapos itama ang unang error, maaaring ipakita ang susunod. Ang step-by-step na gabay na ito ay nagbabawas ng cognitive load at tumutulong sa user na punan ang form nang mas mabilis.

Mga tool at library para sa pag-validate

Ang Android SDK ay nagbibigay ng mga pangunahing tool para sa Validate: Patterns para sa email at telepono, TextUtils para sa pagsusuri ng kawalan ng laman, regular na expression para sa arbitrary pattern. Para sa mga proyekto na may 1-3 field, ito ay sapat. Gayunpaman, sa mga form na may 10+ field, ang manu-manong pag-validate ay nagiging mahirap panatilihin — bawat bagong field ay nangangailangan ng hiwalay na function at pag-update ng lohika ng pagpapadala.

Mga sikat na library ng pag-validate: Android Saripaar (annotation @Email, @NotEmpty, @Password), Commons Validator mula sa Apache (pagsusuri ng email, URL, numero ng credit card), RxBinding + RxJava para sa reactive na pag-validate. Pinapayagan ng Saripaar na ilagay ang mga annotation nang direkta sa mga input field at tawagan ang pag-validate sa isang linya: validator.validate(). Awtomatikong nagpapakita ang library ng mga error sa pamamagitan ng setError.

Inirerekomenda ng Google ang paggamit ng Material Design Components na may TextInputLayout. Ang built-in na pag-validate sa pamamagitan ng setError, setHelperText at setCounterEnabled ay sumasaklaw sa mga pangunahing sitwasyon nang walang external na library. Para sa mga komplikadong proyekto (fintech, medisina), mas mainam na gumamit ng kombinasyon: Material Components + custom na pag-validate na may pattern mula sa domain layer ng Clean Architecture.

Mga error sa pag-validate ng field

Unang error — pagpapakita ng error bago magsimula ang input. Kung ang field ay mandatory ngunit hindi pa nagsimulang punan ng user, huwag ipakita ang “Kinakailangan ang field”. Ito ay lumilikha ng maling impresyon ng problema. Ang error ay dapat lumitaw lamang pagkatapos na nakipag-ugnayan ang user sa field: nagsimulang mag-input, umalis sa field, sinubukang ipadala ang form.

Ikalawang error — hindi malinaw na mensahe ng error. Ang mensahe ay dapat tiyak at magmungkahi kung paano ayusin ang problema. “Hindi wastong email” — masama. “Ang email ay dapat maglaman ng @ at domain, halimbawa user@example.com” — mabuti. Dapat maunawaan ng user kung ano ang mali at kung paano ito ayusin nang hindi kumukonsulta sa dokumentasyon.

Ikatlong error — pag-block ng pagpapadala nang walang paliwanag. Kung ang send button ay hindi aktibo dahil sa mga error sa pag-validate, dapat makita ng user kung aling mga field ang hindi wasto. Ang gray na button na walang mensahe ay dead end para sa user. Palaging i-highlight ang mga field na may error at ipakita ang text ng error sa tabi ng bawat hindi wastong field.