Form Validation este procesul de verificare a corectitudinii tuturor câmpurilor formularului înainte de trimiterea datelor la server. Spre deosebire de validarea unui câmp individual, Form Validation ia în considerare interconexiunile dintre câmpuri: confirmarea parolei, dependența unui câmp de altul, obligativitatea condiționată. Conform datelor Google Developers, 2026, Form Validation trebuie să verifice formularul în întregime la trimitere și să ofere utilizatorului un sumar al tuturor erorilor. Validarea corectă a formularului crește conversia înregistrării cu 25-35% și reduce numărul erorilor la introducere.
Puncte principale
Form Validation este un proces care garantează că toate datele introduse de utilizator în formular respectă cerințele de afaceri înainte de trimiterea la server. Validarea formularului include verificarea fiecărui câmp individual, precum și verificări încrucișate: se potrivește parola cu confirmarea, este selectată cel puțin o căsuță de bifat, sunt completate toate câmpurile obligatorii, este corectă data (de exemplu, data nașterii nu este în viitor).
Diferența față de validarea simplă a câmpului este că Form Validation operează cu formularul ca un întreg unitar. Poate bloca trimiterea dacă un câmp condiționat nu este completat sau poate afișa un sumar al erorilor într-o fereastră de dialog. În formulare complexe (înregistrare, comandă, chestionar) validarea formularului este un strat separat de logică care se testează independent de UI.
Conform cercetărilor UX ale NN Group, utilizatorii termină completarea formularului de 3 ori mai des dacă văd erorile imediat după trimitere, nu după fiecare câmp individual. Totuși, cel mai bun rezultat îl oferă combinația: validarea instantanee a câmpurilor simple (lungime, format) + verificarea completă la trimitere pentru câmpurile încrucișate și logica de afaceri.
Validarea câmpului răspunde la întrebarea: este corectă introducerea în acest câmp specific? Emailul are formatul user@domain.com, telefonul constă din cifre, parola este mai lungă de 6 caractere. Validarea câmpului este izolată — nu depinde de alte câmpuri și poate fi executată în timp real. Rezultat: eroare pentru un câmp specific sau absența acesteia.
Validarea formularului răspunde la întrebarea: poate fi trimis formularul în întregime? Ia în considerare nu doar fiecare câmp, ci și combinațiile lor: parola și confirmarea trebuie să coincidă, data de început nu poate fi mai târziu decât data de sfârșit, suma câmpurilor trebuie să fie 100%. Validarea formularului se execută la trimitere și returnează un rezultat general: formularul este valid sau nu.
Arhitectural, validarea câmpului se plasează în stratul UI (fragment, ViewModel), iar validarea formularului — în stratul domain (use case, interactor). Acest lucru permite reutilizarea validării formularului în diferite componente UI și testarea acesteia fără emulator. În Clean Architecture, validarea formularului este o regulă de afaceri, nu o logică UI.
| Criteriu | Validarea câmpului | Validarea formularului |
|---|---|---|
| Obiect de verificare | Un câmp | Toate câmpurile + interconexiunile lor |
| Momentul executării | În timp real / la pierderea focalizării | La trimiterea formularului |
| Rezultat | Eroarea unui câmp specific | Statusul general al formularului + lista erorilor |
| Stratul arhitecturii | Stratul UI | Stratul domain |
Există două abordări principale ale Form Validation. Prima — imperativă: dezvoltatorul scrie o funcție care verifică secvențial fiecare câmp și colectează lista erorilor. Această abordare este simplă de înțeles, dar codul crește cu fiecare câmp nou. Pentru un formular cu 5 câmpuri abordarea imperativă este încă convenabilă, pentru 15 câmpuri — deja problematică.
A doua abordare — declarativă: regulile de validare sunt descrise prin adnotări sau configurare. Biblioteca parcurge singură toate câmpurile, aplică regulile și returnează rezultatul. Exemplu: adnotarea @Email deasupra câmpului emailData, @ConfirmPassword deasupra câmpului de confirmare. Abordarea declarativă scurtează codul de validare de 3-5 ori și îl face lizibil.
A treia abordare — reactivă cu utilizarea RxJava sau Kotlin Flow. Fiecare câmp este reprezentat ca Observable sau StateFlow. Validarea formularului se abonează la modificările tuturor câmpurilor și recalculează starea generală la fiecare modificare. Butonul de trimitere devine automat activ când toate câmpurile sunt valide. Această abordare necesită înțelegerea programării reactive, dar oferă cel mai fluid UX.
Să considerăm formularul de înregistrare cu trei câmpuri: email, parolă și confirmarea parolei. Validarea formularului include: verificarea emailului prin Patterns.EMAIL_ADDRESS, verificarea parolei pentru lungimea minimă de 8 caractere și prezența unei cifre, verificarea coincidenței parolei cu confirmarea. Doar când toate cele trei verificări trec, formularul poate fi trimis.
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)
}
În exemplu, validateRegistration primește data class a formularului și returnează ValidationResult. Dacă cel puțin o verificare nu trece, se returnează false cu un mesaj corespunzător. Gestionarea butonului de trimitere se bazează pe Result: dacă isValid = true, butonul este activ. Pentru actualizarea stării în timp real se poate folosi LiveData<ValidationResult> și actualiza butonul la fiecare modificare a oricărui câmp.
Abordarea reactivă cu Kotlin Flow permite recalcularea automată a stării formularului. Fiecare câmp este reprezentat ca MutableStateFlow<String>, iar combine le unește într-un singur Flow<ValidationResult>. Abonarea în UI actualizează butonul de trimitere fără apelarea manuală a validării. Acest model este recomandat de Google pentru Jetpack Compose și arhitectura MVVM.
Android Saripaar — cea mai populară bibliotecă de validare pentru Android. Permite adnotarea directă a câmpurilor și View-urilor: @Email, @NotEmpty, @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). Validarea se apelează cu o singură linie validator.validate() cu callback. Saripaar setează automat eroarea prin setError pe EditText. Biblioteca suportă și adnotări personalizate pentru reguli specifice de afaceri.
RxBinding + RxJava — abordare reactivă fără bibliotecă separată de validare. Fiecare câmp publică modificările prin RxTextView.textChanges(). Operatorul combineLatest combină toate câmpurile și calculează statusul general. Avantaj: control complet asupra pipeline-ului de validare, posibilitatea de a adăuga debounce, throttle, filter. Dezavantaj: necesită cunoștințe de RxJava.
Material Design Components — suport încorporat pentru TextInputLayout și TextInputEditText. Biblioteca nu oferă validare ca atare, dar oferă UI pentru afișarea erorilor: setError(), setHelperText(), setCounterEnabled(). Pentru validarea propriu-zisă este necesară logică manuală sau Saripaar. Material Components se ocupă de afișare, nu de verificare.
Prima greșeală — validarea doar pe client. Form Validation pe client este destinată UX-ului, nu securității. Un atacator poate trimite o solicitare direct la API, ocolind validarea. Serverul trebuie să verifice toate câmpurile din nou. Validarea client nu trebuie să fie singura protecție — este un strat suplimentar pentru confortul utilizatorului, nu pentru securitatea datelor.
A doua greșeală — blocarea butonului de trimitere fără mesaje. Dacă butonul este inactiv, utilizatorul trebuie să vadă care câmpuri necesită corectare. Butonul gri fără explicații — una dintre cele mai frecvente cauze ale conversiei scăzute a formularelor. Afișați întotdeauna erorile câmpurilor lângă ele, chiar dacă butonul este blocat. Utilizatorul trebuie să înțeleagă ce anume împiedică trimiterea.
A treia greșeală — ignorarea câmpurilor încrucișate. Validarea fiecărui câmp individual este insuficientă. Câmpurile pot depinde unul de altul: parola și confirmarea, data de început și data de sfârșit, țara și orașul. Form Validation trebuie să verifice aceste interconexiuni. Verificarea doar a câmpurilor individuale creează un fals sentiment de securitate — formularul poate fi trimis cu date necoordonate.
| Greșeală | Consecință | Soluție |
|---|---|---|
| Doar validare client | Vulnerabilitate de securitate | Verificare obligatorie pe server |
| Buton fără mesaje | Conversie scăzută a formularului | Afișarea erorilor câmpurilor |
| Fără verificări încrucișate | Date necoordonate | Validarea interconexiunilor câmpurilor |
| Verificări prea frecvente | Iritarea utilizatorului | Debounce și verificare la pierderea focalizării |
Întrebări frecvente
Validarea câmpului verifică o singură valoare în funcție de format sau lungime. Form Validation verifică toate câmpurile împreună, inclusiv verificări încrucișate: coincidența parolelor, dependența câmpurilor unul de altul. Validarea câmpului se execută în stratul UI, Form Validation — în stratul domain ca regulă de afaceri.
Folosiți abordarea reactivă: uniți toate câmpurile într-un singur Flow sau Observable și abonați-vă la modificări. La fiecare modificare a oricărui câmp, recalculați statusul general al formularului. Dacă statusul este valid — butonul este activ. Utilizați Kotlin Flow cu combine sau RxJava cu combineLatest pentru actualizare automată.
Android Saripaar — cea mai bună alegere pentru validare declarativă cu adnotări. Dacă proiectul folosește RxJava — RxBinding asigură o abordare reactivă fără bibliotecă separată. Pentru formulare simple este suficientă validarea manuală cu Patterns și TextUtils fără dependințe externe.
Obligatoriu. Validarea client îmbunătățește UX-ul, dar nu asigură securitatea. Serverul trebuie să verifice toate datele din nou, deoarece API-ul este accesibil direct. Nu vă bazați niciodată doar pe validarea client pentru protecția împotriva datelor incorecte sau malițioase.
În Jetpack Compose utilizați Kotlin Flow sau StateFlow pentru stocarea stării fiecărui câmp. Funcția de validare primește starea formularului și returnează ValidationResult. Butonul de trimitere se abonează la statusul general. Pentru afișarea erorilor utilizați isError în OutlinedTextField sau TextField Compose.
Concluzii
Vom dezvolta o aplicație mobilă la cheie
IT Sectr creează aplicații iOS și Android pentru startup-uri și afaceri din 2017. Vă vom consilia și vă vom propune cea mai bună soluție.
Citiți și