Validate: mi ez, beviteli mezők érvényesítése és implementáció Androidban

Mi a mezőérvényesítés Androidban?

Mezőérvényesítés — egy adott, felhasználó által bevitt érték ellenőrzése a meghatározott szabályoknak való megfelelésre. Minden mezőnek megvan a saját adattípusa: e-mail, szám, telefon, jelszó, szöveg. Minden típushoz saját kritériumok tartoznak: formátum, hossz, értéktartomány, kötelezőség. A mezőérvényesítés arra a kérdésre válaszol: helyes-e a bevitel ebben a mezőben?

A különbség a mezőérvényesítés és az űrlapérvényesítés között az, hogy a mezőt a többi mezőtől függetlenül ellenőrizzük. Az e-mailt az e-mail minta szerint, a telefont a telefon minta szerint ellenőrizzük. Ha a mező érvénytelen, a felhasználó pontosan ehhez a mezőhöz látja a hibát. Az űrlap elküldetlen maradhat, még ha egy mező nem is felel meg az ellenőrzésnek. A mezőérvényesítés az építőköve a teljes űrlapérvényesítésnek.

UX kutatások szerint a felhasználók legkésőbb 1-2 másodperccel a bevitel befejezése után várják az érvényesítési hibát. A 3 másodpercnél hosszabb késlekedést az alkalmazással kapcsolatos problémának érzékelik. Éppen ezért a valós idejű érvényesítés TextWatcher-en keresztül előnyösebb, mint csak a küldés gomb megnyomásakor történő ellenőrzés.

A mezőérvényesítés fő módszerei

Három fő megközelítés létezik a mezőérvényesítésre Androidban. Az első — kézi ellenőrzés feltételes operátorokkal (if, when). A fejlesztő ír egy függvényt, amely egy sztringet fogad és Boolean-t vagy hibaüzenetet ad vissza. Ez a megközelítés teljes kontrollt biztosít a logika felett, de kódot igényel minden mezőhöz és minden feltételhez.

A második megközelítés — beépített Android osztályok használata. Például a Patterns.EMAIL_ADDRESS.matcher(email).matches() az e-mailt a standard minta szerint ellenőrzi. Patterns.PHONE.matcher(phone).matches() — a telefonszámot. TextUtils.isEmpty() — az ürességet ellenőrzi. Ezek a módszerek lefedik az alap forgatókönyveket külső függőségek csatlakoztatása nélkül.

A harmadik megközelítés — érvényesítő könyvtárak. Az olyan könyvtárak, mint az InputValidator, AndroidValidator vagy Commons Validator, kész annotációkat és ellenőrzési láncokat biztosítanak. A fejlesztő deklaratívan írja le a szabályokat: @Email, @NotEmpty, @MinLength(6). A könyvtár maga végzi el az ellenőrzést és visszaadja a hibák listáját. Ez felgyorsítja a fejlesztést, de függőséget ad hozzá.

E-mail, telefon és jelszó érvényesítése

E-mail esetén a standard ellenőrzés magában foglalja a @ jel, a domain rész meglétét, valamint a szóközök és cirill betűk hiányát. Az Android biztosítja a Patterns.EMAIL_ADDRESS-t, amely a legtöbb legitim e-mail címet lefedi. Ha azonban specifikus ellenőrzés szükséges (pl. csak vállalati domainek), egyedi reguláris kifejezést kell írni. Az e-mail a bevitel befejezése után érvényesítendő, nem minden karakter után.

Telefonszám ellenőrzése az ország vagy régió maszkja szerint történik. Nemzetközi számokhoz az E.164 formátumot használjuk: +országkód, operátorkód, szám. A Google libphonenumber könyvtára az ipari szabvány a telefonérvényesítéshez. Kód alapján meghatározza az országot, ellenőrzi a szám hosszát és formátumát. Androidban a PhoneNumberUtils.isGlobalPhoneNumber használható alapvető ellenőrzésre.

Jelszó több összetettségi kritériummal rendelkezik: minimális hossz, nagy- és kisbetűk, számok, speciális karakterek megléte. Androidban nincs beépített osztály a jelszó ellenőrzésére — minden projekt saját követelményeket határoz meg. Általában a jelszót reguláris kifejezéssel vagy feltételhalmazzal ellenőrizzük. Fontos, hogy ne fedjük fel a pontos követelményeket a hibaüzenetben: „A jelszó túl egyszerű" jobb, mint „Nagybetű és szám szükséges".

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

A példában a validatePassword egy ValidationResult-t ad vissza isValid mezővel és opcionális hibaüzenettel. Ez a megközelítés kényelmes a kompozícióhoz: több ellenőrzés szekvenciálisan történik, és az első talált hiba kerül visszaadásra. Az e-mail és telefon érvényesítések ugyanezen az elven épülnek fel — mindegyik eredményt ad vissza üzenettel vagy sikerrel.

Mikor végezzük az érvényesítést?

Az érvényesítés időpontja kritikusan befolyásolja az UX-et. Három stratégia létezik: érvényesítés minden karakter után (instant), fókuszvesztés után (onFocusLost) és az űrlap beküldésekor (onSubmit). Minden stratégia különböző forgatókönyvekhez alkalmas. Az azonnali érvényesítés jó a szigorú korlátokkal rendelkező mezőkhöz — telefonszám, PIN-kód. OnFocusLost — e-mailhez és névhez. OnSubmit — kötelező mezőkhöz.

A Material Design Guidelines szerint ajánlott a stratégiák kombinálása: a mezőt fókuszvesztéskor, valamint az űrlap beküldésekor is ellenőrizni kell. Az azonnali érvényesítés akkor megfelelő, ha a korlát nyilvánvaló — például a mező maximális hossza. Ha e-mailnél minden karakter után hibát mutatunk, a felhasználó a bevitel befejezése előtt látja az üzenetet. Ez irritáló és csökkenti a konverziót.

Az első hiba szabálya: az űrlap beküldésekor csak az első érvénytelen mezőhöz mutass hibát. Ne terheljük a felhasználót 10 hibából álló listával. Az első hiba kijavítása után a következő is megjeleníthető. Ez a lépésről lépésre történő vezetés csökkenti a kognitív terhelést és segít a felhasználónak gyorsabban kitölteni az űrlapot.

Eszközök és könyvtárak az érvényesítéshez

Az Android SDK alapvető eszközöket biztosít a Validate-hez: Patterns e-mailhez és telefonhoz, TextUtils az üresség ellenőrzéséhez, reguláris kifejezések tetszőleges mintákhoz. Az 1-3 mezős projektekhez ez elegendő. Azonban a 10+ mezős űrlapokban a kézi érvényesítés nehezen karbantarthatóvá válik — minden új mező külön függvényt és a küldési logika frissítését igényli.

Népszerű érvényesítő könyvtárak: Android Saripaar (@Email, @NotEmpty, @Password annotációk), Commons Validator az Apache-tól (e-mail, URL, hitelkártyaszám ellenőrzés), RxBinding + RxJava reaktív érvényesítéshez. A Saripaar lehetővé teszi annotációk közvetlen elhelyezését a beviteli mezőkön és az érvényesítés egy sorral történő meghívását: validator.validate(). A könyvtár automatikusan megjeleníti a hibákat a setError-on keresztül.

A Google a Material Design Components használatát ajánlja TextInputLayout-tal. A beépített érvényesítés setError, setHelperText és setCounterEnabled segítségével lefedi az alap forgatókönyveket külső könyvtárak nélkül. Összetett projektekhez (fintech, orvostudomány) jobb kombinációt használni: Material Components + egyedi érvényesítés a Clean Architecture domain rétegéből származó mintákkal.

Gyakori hibák a mezőérvényesítésben

Első hiba — hiba megjelenítése a bevitel megkezdése előtt. Ha a mező kötelező, de a felhasználó még nem kezdte el kitölteni, ne mutassuk a „Mező kötelező" üzenetet. Ez hamis problémaérzetet kelt. A hibának csak azután szabad megjelennie, hogy a felhasználó interakcióba lépett a mezővel: elkezdett beírni, elhagyta a mezőt, megpróbálta elküldeni az űrlapot.

Második hiba — érthetetlen hibaüzenet. Az üzenetnek konkrétnak kell lennie, és javaslatot kell tennie a probléma megoldására. „Érvénytelen e-mail" — rossz. „Az e-mailnek tartalmaznia kell @-et és domaint, például user@example.com" — jó. A felhasználónak meg kell értenie, mi a hiba, és hogyan javítsa ki a dokumentáció olvasása nélkül.

Harmadik hiba — a beküldés blokkolása magyarázat nélkül. Ha a küldés gomb inaktív az érvényesítési hibák miatt, a felhasználónak látnia kell, mely mezők érvénytelenek. A szürke gomb üzenetek nélkül zsákutca a felhasználó számára. Mindig emeljük ki a hibás mezőket, és mutassuk a hiba szövegét minden érvénytelen mező mellett.