Form Validation je proces kontroly správnosti všech polí formuláře před odesláním dat na server. Na rozdíl od validace jednotlivého pole bere Form Validation v úvahu vzájemné vazby mezi poli: potvrzení hesla, závislost jednoho pole na druhém, podmíněnou povinnost. Podle údajů Google Developers, 2026 by Form Validation měla při odeslání zkontrolovat celý formulář a poskytnout uživateli shrnutí všech chyb. Správná validace formuláře zvyšuje konverzi registrace o 25-35% a snižuje počet chyb při zadávání.
Hlavní body
Form Validation je proces, který zaručuje, že všechna data zadaná uživatelem do formuláře splňují obchodní požadavky před odesláním na server. Validace formuláře zahrnuje kontrolu každého pole jednotlivě, stejně jako křížové kontroly: shoduje se heslo s potvrzením, je zaškrtnuto alespoň jedno zaškrtávací políčko, jsou vyplněna všechna povinná pole, je datum správné (např. datum narození není v budoucnosti).
Rozdíl od jednoduché validace pole spočívá v tom, že Form Validation pracuje s formulářem jako s jediným celkem. Může blokovat odeslání, pokud podmíněné pole není vyplněno, nebo zobrazit shrnutí chyb v dialogovém okně. U složitých formulářů (registrace, objednávka, dotazník) je validace formuláře samostatnou vrstvou logiky, která je testována nezávisle na UI.
Podle UX výzkumů NN Group uživatelé 3krát častěji dokončí vyplnění formuláře, pokud vidí chyby ihned po odeslání, nikoli po každém poli jednotlivě. Nejlepší výsledek však dává kombinace: okamžitá validace jednoduchých polí (délka, formát) + úplná kontrola při odeslání pro křížová pole a obchodní logiku.
Validace pole odpovídá na otázku: je zadání v tomto konkrétním poli správné? E-mail má formát user@domain.com, telefon se skládá z číslic, heslo je delší než 6 znaků. Validace pole je izolovaná — nezávisí na jiných polích a může být prováděna v reálném čase. Výsledek: chyba pro konkrétní pole nebo její nepřítomnost.
Validace formuláře odpovídá na otázku: lze formulář odeslat jako celek? Zohledňuje nejen každé pole, ale také jejich kombinace: heslo a potvrzení se musí shodovat, datum zahájení nesmí být pozdější než datum ukončení, součet polí musí být 100%. Validace formuláře se provádí při odeslání a vrací celkový výsledek: formulář je platný nebo ne.
Architektonicky je validace pole umístěna v UI vrstvě (fragment, ViewModel), a validace formuláře v doménové vrstvě (use case, interactor). To umožňuje opakované použití validace formuláře v různých UI komponentách a její testování bez emulátoru. V Clean Architecture je validace formuláře obchodním pravidlem, nikoli UI logikou.
| Kritérium | Validace pole | Validace formuláře |
|---|---|---|
| Předmět kontroly | Jedno pole | Všechna pole + jejich vzájemné vazby |
| Čas provedení | V reálném čase / při ztrátě fokusu | Při odeslání formuláře |
| Výsledek | Chyba konkrétního pole | Celkový stav formuláře + seznam chyb |
| Architektonická vrstva | UI vrstva | Doménová vrstva |
Existují dva hlavní přístupy k Form Validation. První — imperativní: vývojář napíše funkci, která sekvenčně kontroluje každé pole a shromažďuje seznam chyb. Tento přístup je jednoduchý na pochopení, ale kód narůstá s každým novým polem. Pro formulář s 5 poli je imperativní přístup ještě pohodlný, pro 15 polí — již problematický.
Druhý přístup — deklarativní: validační pravidla jsou popsána anotacemi nebo konfigurací. Knihovna sama projde všechna pole, aplikuje pravidla a vrátí výsledek. Příklad: anotace @Email nad polem emailData, @ConfirmPassword nad polem potvrzení. Deklarativní přístup zkracuje validační kód 3-5krát a činí jej čitelným.
Třetí přístup — reaktivní s použitím RxJava nebo Kotlin Flow. Každé pole je reprezentováno jako Observable nebo StateFlow. Validace formuláře se přihlásí k odběru změn všech polí a přepočítává celkový stav při každé změně. Tlačítko odeslání se automaticky stane aktivním, když jsou všechna pole platná. Tento přístup vyžaduje pochopení reaktivního programování, ale poskytuje nejplynulejší UX.
Zvažme registrační formulář se třemi poli: e-mail, heslo a potvrzení hesla. Validace formuláře zahrnuje: kontrolu e-mailu pomocí Patterns.EMAIL_ADDRESS, kontrolu hesla na minimální délku 8 znaků a přítomnost číslice, kontrolu shody hesla a potvrzení. Teprve když všechny tři kontroly projdou, lze formulář odeslat.
data class RegistrationForm(
val email: String,
val password: String,
val confirmPassword: String
)
fun validateRegistration(form: RegistrationForm): ValidationResult {
if (!Patterns.EMAIL_ADDRESS.matcher(form.email).matches())
return ValidationResult(false, "Invalid email address")
if (form.password.length < 8)
return ValidationResult(false, "Password too short")
if (form.password != form.confirmPassword)
return ValidationResult(false, "Passwords do not match")
return ValidationResult(true)
}
V příkladu validateRegistration přijímá data class formuláře a vrací ValidationResult. Pokud alespoň jedna kontrola neprojde, vrací se false s odpovídající zprávou. Správa tlačítka odeslání je založena na Result: pokud je isValid = true, tlačítko je aktivní. Pro aktualizaci stavu v reálném čase lze použít LiveData<ValidationResult> a aktualizovat tlačítko při každé změně libovolného pole.
Reaktivní přístup s Kotlin Flow umožňuje automatický přepočet stavu formuláře. Každé pole je reprezentováno jako MutableStateFlow<String>, a combine je spojí do jednoho Flow<ValidationResult>. Odběr v UI aktualizuje tlačítko odeslání bez ručního volání validace. Tento vzor doporučuje Google pro Jetpack Compose a architekturu MVVM.
Android Saripaar — nejoblíbenější validační knihovna pro Android. Umožňuje přímé anotování polí a View: @Email, @NotEmpty, @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). Validace se volá jedním řádkem validator.validate() s callbackem. Saripaar automaticky nastaví chybu pomocí setError na EditText. Knihovna také podporuje vlastní anotace pro specifická obchodní pravidla.
RxBinding + RxJava — reaktivní přístup bez samostatné validační knihovny. Každé pole publikuje změny prostřednictvím RxTextView.textChanges(). Operátor combineLatest spojí všechna pole a vypočítá celkový stav. Výhoda: plná kontrola nad validačním pipeline, možnost přidání debounce, throttle, filter. Nevýhoda: vyžaduje znalost RxJava.
Material Design Components — vestavěná podpora pro TextInputLayout a TextInputEditText. Knihovna neposkytuje validaci jako takovou, ale dává UI pro zobrazení chyb: setError(), setHelperText(), setCounterEnabled(). Pro samotnou validaci je stále potřeba ruční logika nebo Saripaar. Material Components jsou zodpovědné za zobrazení, nikoli za kontrolu.
První chyba — validace pouze na straně klienta. Form Validation na straně klienta je určena pro UX, nikoli pro bezpečnost. Útočník může odeslat požadavek přímo na API, čímž obejde validaci. Server musí znovu zkontrolovat všechna pole. Klientská validace by neměla být jedinou ochranou — je to další vrstva pro pohodlí uživatele, nikoli pro bezpečnost dat.
Druhá chyba — blokování tlačítka odeslání bez zpráv. Pokud je tlačítko neaktivní, uživatel by měl vidět, která pole je třeba opravit. Šedé tlačítko bez vysvětlení — jedna z nejčastějších příčin nízké konverze formulářů. Vždy zobrazujte chyby polí vedle nich, i když je tlačítko blokováno. Uživatel musí chápat, co přesně brání odeslání.
Třetí chyba — ignorování křížových polí. Validace každého pole jednotlivě není dostatečná. Pole mohou na sobě záviset: heslo a potvrzení, datum zahájení a datum ukončení, země a město. Form Validation musí tyto vzájemné vazby kontrolovat. Kontrola pouze jednotlivých polí vytváří falešný pocit bezpečí — formulář může být odeslán s nekonzistentními daty.
| Chyba | Důsledek | Řešení |
|---|---|---|
| Pouze klientská validace | Bezpečnostní zranitelnost | Povinná serverová kontrola |
| Tlačítko bez zpráv | Nízká konverze formuláře | Zobrazovat chyby polí |
| Žádné křížové kontroly | Nekonzistentní data | Validace vzájemných vazeb polí |
| Příliš časté kontroly | Podráždění uživatele | Debounce a kontrola při ztrátě fokusu |
Často kladené otázky
Validace pole kontroluje jednu hodnotu z hlediska formátu nebo délky. Form Validation kontroluje všechna pole dohromady, včetně křížových kontrol: shoda hesel, vzájemná závislost polí. Validace pole se provádí v UI vrstvě, Form Validation — v doménové vrstvě jako obchodní pravidlo.
Použijte reaktivní přístup: spojte všechna pole do jednoho Flow nebo Observable a přihlaste se ke změnám. Při každé změně libovolného pole přepočítejte celkový stav formuláře. Pokud je stav platný — tlačítko je aktivní. Použijte Kotlin Flow s combine nebo RxJava s combineLatest pro automatickou aktualizaci.
Android Saripaar — nejlepší volba pro deklarativní validaci s anotacemi. Pokud projekt používá RxJava — RxBinding poskytne reaktivní přístup bez samostatné knihovny. Pro jednoduché formuláře stačí ruční validace s Patterns a TextUtils bez externích závislostí.
Povinně. Klientská validace zlepšuje UX, ale nezajišťuje bezpečnost. Server musí znovu zkontrolovat všechna data, protože API je přímo přístupné. Nikdy se nespoléhejte pouze na klientskou validaci pro ochranu před nesprávnými nebo škodlivými daty.
V Jetpack Compose použijte Kotlin Flow nebo StateFlow pro ukládání stavu každého pole. Validační funkce přijímá stav formuláře a vrací ValidationResult. Tlačítko odeslání se přihlásí k odběru celkového stavu. Pro zobrazení chyb použijte isError v OutlinedTextField nebo TextField Compose.
Shrnutí
Vyvineme mobilní aplikaci na klíč
IT Sectr vytváří aplikace pro iOS a Android pro startupy a podniky od roku 2017. Poradíme vám a navrhneme nejlepší řešení.
Přečtěte si také