Validate: co to je, validace vstupních polí a implementace v Android

Co je validace pole v Androidu?

Validace pole — je kontrola jedné konkrétní hodnoty zadané uživatelem na shodu s danými pravidly. Každé pole má svůj datový typ: email, číslo, telefon, heslo, text. Pro každý typ existují vlastní kritéria: formát, délka, rozsah hodnot, povinnost. Validace pole odpovídá na otázku: je vstup v tomto poli správný?

Rozdíl mezi validací pole a validací formuláře je v tom, že pole je kontrolováno nezávisle na ostatních polích. Email je kontrolován podle vzoru emailu, telefon — podle vzoru telefonu. Pokud je pole neplatné, uživatel vidí chybu právě pro toto pole. Formulář může zůstat neodeslaný, i když jedno pole neprošlo kontrolou. Validace pole je stavebním blokem pro úplnou validaci formuláře.

Podle UX výzkumů uživatelé očekávají, že uvidí chybu validace nejpozději 1-2 sekundy po dokončení zadávání. Zpoždění delší než 3 sekundy je vnímáno jako problém s aplikací. Právě proto je validace v reálném čase přes TextWatcher preferována před kontrolou pouze při kliknutí na tlačítko odeslání.

Hlavní metody validace polí

Existují tři hlavní přístupy k validaci polí v Androidu. První — ruční kontrola pomocí podmíněných operátorů (if, when). Vývojář napíše funkci, která přijímá řetězec a vrací Boolean nebo chybovou hlášku. Tento přístup poskytuje plnou kontrolu nad logikou, ale vyžaduje psaní kódu pro každé pole a každou podmínku.

Druhý přístup — použití vestavěných tříd Android. Například Patterns.EMAIL_ADDRESS.matcher(email).matches() kontroluje email podle standardního vzoru. Patterns.PHONE.matcher(phone).matches() — telefonní číslo. TextUtils.isEmpty() — kontroluje prázdnotu. Tyto metody pokrývají základní scénáře bez připojení externích závislostí.

Třetí přístup — knihovny pro validaci. Knihovny jako InputValidator, AndroidValidator nebo Commons Validator poskytují hotové anotace a řetězce kontrol. Vývojář popisuje pravidla deklarativně: @Email, @NotEmpty, @MinLength(6). Knihovna sama provede kontrolu a vrátí seznam chyb. To urychluje vývoj, ale přidává závislost.

Validace emailu, telefonu a hesla

Pro email standardní kontrola zahrnuje přítomnost znaku @, doménové části a absenci mezer a azbuky. Android poskytuje Patterns.EMAIL_ADDRESS, který pokrývá většinu legitimních e-mailových adres. Pokud je však vyžadována specifická kontrola (např. pouze firemní domény), je třeba napsat vlastní regulární výraz. Email se validuje po dokončení zadávání, ne po každém znaku.

Telefonní číslo se kontroluje podle masky země nebo regionu. Pro mezinárodní čísla se používá formát E.164: +kód země, kód operátora, číslo. Knihovna libphonenumber od Google je průmyslovým standardem pro validaci telefonů. Určuje zemi podle kódu, kontroluje délku a formát čísla. V Androidu můžete použít PhoneNumberUtils.isGlobalPhoneNumber pro základní kontrolu.

Heslo má několik kritérií složitosti: minimální délka, přítomnost velkých a malých písmen, číslic, speciálních znaků. V Androidu neexistuje vestavěná třída pro kontrolu hesla — každý projekt si stanoví vlastní požadavky. Obvykle se heslo kontroluje pomocí regulárního výrazu nebo sady podmínek. Je důležité neodhalovat přesné požadavky v chybové hlášce: „Heslo je příliš jednoduché" je lepší než „Je vyžadováno velké písmeno a číslice".

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

V příkladu validatePassword vrací ValidationResult s polem isValid a volitelnou chybovou hláškou. Tento přístup je vhodný pro kompozici: několik kontrol se provádí sekvenčně a vrací se první nalezená chyba. Validace emailu a telefonu se staví na stejném principu — každá vrací výsledek s hláškou nebo úspěchem.

Kdy provádět validaci?

Okamžik validace kriticky ovlivňuje UX. Existují tři strategie: validace po zadání každého znaku (instant), po ztrátě fokusu (onFocusLost) a při odeslání formuláře (onSubmit). Každá strategie je vhodná pro různé scénáře. Okamžitá validace je dobrá pro pole s přísnými omezeními — telefonní číslo, PIN kód. OnFocusLost — pro email a jméno. OnSubmit — pro povinná pole.

Podle Material Design Guidelines se doporučuje kombinovat strategie: pole by mělo být kontrolováno při ztrátě fokusu a také při odeslání formuláře. Okamžitá validace je vhodná, když je omezení zřejmé — například maximální délka pole. Pokud se zobrazuje chyba po každém znaku pro email, uživatel uvidí hlášku dříve, než dokončí zadávání. To je otravné a snižuje konverzi.

Pravidlo první chyby: při odeslání formuláře zobrazte chybu pouze pro první neplatné pole. Nezahlcujte uživatele seznamem 10 chyb. Po opravě první chyby lze zobrazit další. Toto vedení krok za krokem snižuje kognitivní zátěž a pomáhá uživateli vyplnit formulář rychleji.

Nástroje a knihovny pro validaci

Android SDK poskytuje základní nástroje pro Validate: Patterns pro email a telefon, TextUtils pro kontrolu prázdnoty, regulární výrazy pro libovolné vzory. Pro projekty s 1-3 poli to stačí. Avšak ve formulářích s 10+ poli se ruční validace stává obtížně udržovatelnou — každé nové pole vyžaduje samostatnou funkci a aktualizaci logiky odeslání.

Populární knihovny pro validaci: Android Saripaar (anotace @Email, @NotEmpty, @Password), Commons Validator od Apache (kontrola emailu, URL, čísla kreditní karty), RxBinding + RxJava pro reaktivní validaci. Saripaar umožňuje umístit anotace přímo na vstupní pole a zavolat validaci jedním řádkem: validator.validate(). Knihovna automaticky zobrazuje chyby přes setError.

Google doporučuje používat Material Design Components s TextInputLayout. Vestavěná validace přes setError, setHelperText a setCounterEnabled pokrývá základní scénáře bez externích knihoven. Pro složité projekty (fintech, medicína) je lepší použít kombinaci: Material Components + vlastní validace se vzory z doménové vrstvy Clean Architecture.

Chyby při validaci polí

První chyba — zobrazení chyby před zahájením zadávání. Pokud je pole povinné, ale uživatel ještě nezačal vyplňovat, nezobrazujte „Pole je povinné". To vytváří falešný dojem problému. Chyba by se měla objevit až poté, co uživatel s polem interagoval: začal zadávat, opustil pole, pokusil se odeslat formulář.

Druhá chyba — nesrozumitelná chybová hláška. Hláška by měla být konkrétní a napovídat, jak problém vyřešit. „Neplatný email" — špatně. „Email musí obsahovat @ a doménu, například user@example.com" — dobře. Uživatel by měl pochopit, co je přesně špatně a jak to opravit bez nahlížení do dokumentace.

Třetí chyba — blokování odeslání bez vysvětlení. Pokud je tlačítko odeslání neaktivní kvůli chybám validace, uživatel by měl vidět, která pole jsou neplatná. Šedé tlačítko bez zpráv je pro uživatele slepá ulička. Vždy zvýrazňujte pole s chybami a zobrazujte text chyby vedle každého neplatného pole.