Form Validation è il processo di verifica di tutti i campi di un form per accertarne la correttezza prima di inviare i dati al server. A differenza della validazione di un singolo campo, Form Validation tiene conto delle relazioni tra i campi: conferma password, dipendenza di un campo da un altro, obbligatorietà condizionale. Secondo Google Developers, 2026, Form Validation dovrebbe verificare l'intero form al momento dell'invio e fornire all'utente un riepilogo di tutti gli errori. Una corretta validazione del form aumenta la conversione di registrazione del 25-35% e riduce il numero di errori di inserimento.
Punti chiave
Form Validation è un processo che garantisce che tutti i dati inseriti dall'utente in un form soddisfino i requisiti aziendali prima di essere inviati al server. La validazione del form include la verifica di ogni campo individualmente, oltre a controlli incrociati: se la password corrisponde alla conferma, se almeno una casella di controllo è selezionata, se tutti i campi obbligatori sono compilati, se la data è corretta (ad esempio, la data di nascita non è nel futuro).
La differenza rispetto alla semplice validazione di campo è che Form Validation opera sul form come un'unica entità. Può bloccare l'invio se un campo condizionale non è compilato, o mostrare un riepilogo degli errori in una finestra di dialogo. Nei form complessi (registrazione, checkout, questionari), la validazione del form è un livello di logica separato che viene testato indipendentemente dall'interfaccia utente.
Secondo la ricerca UX di NN Group, gli utenti completano un form 3 volte più spesso se vedono gli errori immediatamente dopo l'invio, invece che dopo ogni singolo campo. Tuttavia, il risultato migliore deriva da una combinazione: validazione istantanea dei campi semplici (lunghezza, formato) + controllo completo all'invio per i campi incrociati e la logica di business.
La validazione di campo risponde alla domanda: l'input in questo particolare campo è corretto? L'email ha il formato user@domain.com, il telefono è composto da cifre, la password è più lunga di 6 caratteri. La validazione di campo è isolata — non dipende da altri campi e può essere eseguita in tempo reale. Risultato: un errore per un campo specifico o assenza di errore.
La validazione del form risponde alla domanda: il form può essere inviato nella sua interezza? Tiene conto non solo di ogni campo ma anche delle loro combinazioni: password e conferma devono corrispondere, la data di inizio non può essere successiva alla data di fine, la somma dei campi deve essere pari al 100%. La validazione del form viene eseguita all'invio e restituisce un risultato complessivo: il form è valido o meno.
Architettonicamente, la validazione di campo è collocata nel livello UI (fragment, ViewModel), mentre la validazione del form è collocata nel livello di dominio (use case, interactor). Ciò consente di riutilizzare la validazione del form in diversi componenti UI e di testarla senza emulatore. Nella Clean Architecture, la validazione del form è una regola di business, non logica UI.
| Criterio | Validazione di campo | Validazione di form |
|---|---|---|
| Oggetto di verifica | Un campo | Tutti i campi + le loro relazioni |
| Momento di esecuzione | Tempo reale / alla perdita del focus | All'invio del form |
| Risultato | Errore di un campo specifico | Stato generale del form + elenco errori |
| Livello architetturale | Livello UI | Livello di dominio |
Esistono due approcci principali per Form Validation. Il primo è imperativo: lo sviluppatore scrive una funzione che controlla sequenzialmente ogni campo e raccoglie un elenco di errori. Questo approccio è semplice da capire, ma il codice cresce con ogni nuovo campo. Per un form con 5 campi, l'approccio imperativo è ancora comodo; per 15 campi, è già problematico.
Il secondo approccio è dichiarativo: le regole di validazione vengono descritte tramite annotazioni o configurazione. La libreria stessa scorre tutti i campi, applica le regole e restituisce il risultato. Esempio: l'annotazione @Email sul campo emailData, @ConfirmPassword sul campo di conferma. L'approccio dichiarativo riduce il codice di validazione di 3-5 volte e lo rende leggibile.
Il terzo approccio è reattivo utilizzando RxJava o Kotlin Flow. Ogni campo è rappresentato come Observable o StateFlow. La validazione del form si sottoscrive ai cambiamenti di tutti i campi e ricalcola lo stato generale ad ogni modifica. Il pulsante di invio diventa automaticamente attivo quando tutti i campi sono validi. Questo approccio richiede la comprensione della programmazione reattiva, ma offre l'esperienza utente più fluida.
Consideriamo un form di registrazione con tre campi: email, password e conferma password. La validazione del form include: verifica dell'email tramite Patterns.EMAIL_ADDRESS, controllo che la password abbia una lunghezza minima di 8 caratteri e contenga almeno una cifra, verifica che la password e la conferma corrispondano. Solo quando tutti e tre i controlli vengono superati, il form può essere inviato.
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)
}
Nell'esempio, validateRegistration prende una data class del form e restituisce un ValidationResult. Se almeno un controllo fallisce, restituisce false con un messaggio corrispondente. La gestione del pulsante di invio si basa sul Result: se isValid = true, il pulsante è attivo. Per aggiornare lo stato in tempo reale, si può usare LiveData
L'approccio reattivo con Kotlin Flow permette di ricalcolare automaticamente lo stato del form. Ogni campo è rappresentato come MutableStateFlow
Android Saripaar è la libreria di validazione più popolare per Android. Permette di annotare campi e View direttamente: @Email, @NotEmpty, @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). La validazione viene attivata con una singola riga validator.validate() con un callback. Saripaar imposta automaticamente l'errore tramite setError su EditText. La libreria supporta anche annotazioni personalizzate per regole di business specifiche.
RxBinding + RxJava è un approccio reattivo senza una libreria di validazione separata. Ogni campo pubblica le modifiche tramite RxTextView.textChanges(). L'operatore combineLatest fonde tutti i campi e calcola lo stato generale. Vantaggio: controllo completo sulla pipeline di validazione, possibilità di aggiungere debounce, throttle, filter. Svantaggio: richiede conoscenza di RxJava.
Material Design Components forniscono supporto integrato per TextInputLayout e TextInputEditText. La libreria non fornisce validazione in quanto tale, ma offre un'interfaccia utente per visualizzare gli errori: setError(), setHelperText(), setCounterEnabled(). Per la validazione stessa, è ancora necessaria logica manuale o Saripaar. I Material Components sono responsabili della visualizzazione, non del controllo.
Il primo errore è la validazione solo lato client. Form Validation lato client è progettata per l'esperienza utente, non per la sicurezza. Un utente malintenzionato può inviare una richiesta direttamente all'API, aggirando la validazione. Il server deve ricontrollare tutti i campi. La validazione lato client non dovrebbe essere l'unica protezione — è un livello aggiuntivo per la comodità dell'utente, non per la sicurezza dei dati.
Il secondo errore è bloccare il pulsante di invio senza messaggi. Se il pulsante è inattivo, l'utente deve vedere quali campi devono essere corretti. Un pulsante grigio senza spiegazione è una delle cause più comuni di bassa conversione dei form. Mostra sempre gli errori dei campi accanto ad essi, anche se il pulsante è disabilitato. L'utente deve capire cosa impedisce esattamente l'invio.
Il terzo errore è ignorare i controlli incrociati. Validare ogni campo individualmente è insufficiente. I campi possono dipendere l'uno dall'altro: password e conferma, data di inizio e data di fine, paese e città. Form Validation deve verificare queste relazioni. Controllare solo i campi individuali crea una falsa sensazione di sicurezza — il form potrebbe essere inviato con dati incoerenti.
| Errore | Conseguenza | Soluzione |
|---|---|---|
| Solo validazione lato client | Vulnerabilità di sicurezza | Controllo obbligatorio lato server |
| Pulsante senza messaggi | Bassa conversione del form | Mostrare errori dei campi |
| Nessun controllo incrociato | Dati incoerenti | Validare le relazioni tra campi |
| Controlli troppo frequenti | Irritazione dell'utente | Debounce e controllo alla perdita del focus |
Domande frequenti
La validazione di campo controlla un singolo valore rispetto a requisiti di formato o lunghezza. Form Validation controlla tutti i campi insieme, inclusi i controlli incrociati: corrispondenza delle password, dipendenze tra campi. La validazione di campo viene eseguita nel livello UI, Form Validation — nel livello di dominio come regola di business.
Utilizza un approccio reattivo: combina tutti i campi in un unico Flow o Observable e sottoscriviti alle modifiche. Ad ogni modifica di qualsiasi campo, ricalcola lo stato generale del form. Se lo stato è valido — il pulsante è attivo. Utilizza Kotlin Flow con combine o RxJava con combineLatest per aggiornamenti automatici.
Android Saripaar è la scelta migliore per la validazione dichiarativa con annotazioni. Se il progetto utilizza RxJava — RxBinding fornisce un approccio reattivo senza una libreria separata. Per i form semplici, la validazione manuale con Patterns e TextUtils senza dipendenze esterne è sufficiente.
Assolutamente. La validazione lato client migliora l'esperienza utente ma non fornisce sicurezza. Il server deve convalidare nuovamente tutti i dati poiché l'API è accessibile direttamente. Non affidarti mai esclusivamente alla validazione lato client per proteggerti da dati errati o dannosi.
In Jetpack Compose, utilizza Kotlin Flow o StateFlow per memorizzare lo stato di ogni campo. La funzione di validazione prende lo stato del form e restituisce un ValidationResult. Il pulsante di invio si sottoscrive allo stato generale. Per visualizzare gli errori, utilizza isError in OutlinedTextField o TextField di Compose.
Riepilogo
Svilupperemo un'applicazione mobile chiavi in mano
IT Sectr crea applicazioni iOS e Android per startup e aziende dal 2017. Ti consulteremo e ti proporremo la soluzione migliore.
Leggi anche