Validate: cos'è, validazione dei campi di input e implementazione in Android

Cos'è la validazione del campo in Android?

La validazione del campo è la verifica di un singolo valore inserito dall'utente secondo le regole specificate. Ogni campo ha il proprio tipo di dati: email, numero, telefono, password, testo. Ogni tipo ha i propri criteri: formato, lunghezza, intervallo di valori, obbligatorietà. La validazione del campo risponde alla domanda: l'input in questo campo è corretto?

La differenza tra validazione del campo e validazione del modulo è che un campo viene verificato indipendentemente dagli altri campi. L'email viene validata secondo un pattern email, il telefono secondo un pattern telefonico. Se un campo non è valido, l'utente vede un errore per quel campo specifico. Il modulo può rimanere non inviato anche se un campo non supera la validazione. La validazione del campo è il blocco costitutivo per la validazione completa del modulo.

Secondo la ricerca UX, gli utenti si aspettano di vedere un errore di validazione non oltre 1-2 secondi dopo aver completato l'input. Un ritardo superiore a 3 secondi viene percepito come un problema dell'applicazione. Ecco perché la validazione in tempo reale tramite TextWatcher è preferibile al controllo solo quando si preme il pulsante di invio.

Principali metodi di validazione dei campi

Esistono tre approcci principali per la validazione dei campi in Android. Il primo è il controllo manuale tramite operatori condizionali (if, when). Lo sviluppatore scrive una funzione che accetta una stringa e restituisce un Boolean o un messaggio di errore. Questo approccio dà il controllo completo sulla logica, ma richiede la scrittura di codice per ogni campo e ogni condizione.

Il secondo approccio è l'uso di classi integrate di Android. Ad esempio, Patterns.EMAIL_ADDRESS.matcher(email).matches() valida un'email secondo un pattern standard. Patterns.PHONE.matcher(phone).matches() valida un numero di telefono. TextUtils.isEmpty() controlla se è vuoto. Questi metodi coprono scenari di base senza aggiungere dipendenze esterne.

Il terzo approccio sono le librerie di validazione. Librerie come InputValidator, AndroidValidator o Commons Validator forniscono annotazioni pronte e catene di validazione. Lo sviluppatore descrive le regole in modo dichiarativo: @Email, @NotEmpty, @MinLength(6). La libreria stessa esegue la validazione e restituisce un elenco di errori. Questo accelera lo sviluppo ma aggiunge una dipendenza.

Validazione di email, telefono e password

Per l'email, la validazione standard include la verifica della presenza del simbolo @, di una parte di dominio e dell'assenza di spazi e caratteri cirillici. Android fornisce Patterns.EMAIL_ADDRESS, che copre la maggior parte degli indirizzi email legittimi. Tuttavia, se è richiesta una validazione specifica (ad esempio, solo domini aziendali), è necessario scrivere un'espressione regolare personalizzata. L'email viene validata dopo il completamento dell'input, non dopo ogni carattere.

Il numero di telefono viene validato secondo una maschera nazionale o regionale. Per i numeri internazionali viene utilizzato il formato E.164: +codice paese, codice operatore, numero. La libreria libphonenumber di Google è lo standard industriale per la validazione dei telefoni. Determina il paese dal codice, controlla la lunghezza e il formato del numero. In Android, PhoneNumberUtils.isGlobalPhoneNumber può essere utilizzato per la validazione di base.

La password ha diversi criteri di complessità: lunghezza minima, presenza di lettere maiuscole e minuscole, cifre, caratteri speciali. Android non ha una classe integrata per la validazione delle password — ogni progetto definisce i propri requisiti. Tipicamente, una password viene validata tramite un'espressione regolare o un insieme di condizioni. È importante non rivelare i requisiti esatti nel messaggio di errore: “La password è troppo semplice” è meglio di “Sono necessari una lettera maiuscola e una cifra”.

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

Nell'esempio, validatePassword restituisce un ValidationResult con un campo isValid e un messaggio di errore opzionale. Questo approccio è conveniente per la composizione: diversi controlli vengono eseguiti in sequenza e viene restituito il primo errore trovato. La validazione di email e telefono segue lo stesso principio — ognuna restituisce un risultato con un messaggio o successo.

Quando eseguire la validazione?

Il momento della validazione influisce criticamente sull'UX. Esistono tre strategie: validazione dopo ogni carattere (istantanea), dopo la perdita del focus (onFocusLost) e all'invio del modulo (onSubmit). Ogni strategia è adatta a scenari diversi. La validazione istantanea è buona per i campi con vincoli rigidi — numero di telefono, codice PIN. OnFocusLost funziona per email e nome. OnSubmit funziona per i campi obbligatori.

Secondo le Material Design Guidelines, si consiglia di combinare le strategie: un campo dovrebbe essere validato alla perdita del focus e anche all'invio del modulo. La validazione istantanea è appropriata quando il vincolo è ovvio — ad esempio, la lunghezza massima del campo. Se viene mostrato un errore dopo ogni carattere per l'email, l'utente vedrà un messaggio prima di terminare l'input. Questo è fastidioso e riduce la conversione.

La regola del primo errore: quando si invia un modulo, mostra un errore solo per il primo campo non valido. Non sovraccaricare l'utente con un elenco di 10 errori. Dopo aver corretto il primo errore, è possibile mostrare il successivo. Questa guida passo passo riduce il carico cognitivo e aiuta l'utente a compilare il modulo più rapidamente.

Strumenti e librerie per la validazione

L'SDK Android fornisce strumenti di base per Validate: Patterns per email e telefono, TextUtils per controllare il vuoto, espressioni regolari per pattern arbitrari. Per progetti con 1-3 campi, questo è sufficiente. Tuttavia, in moduli con 10+ campi, la validazione manuale diventa difficile da mantenere — ogni nuovo campo richiede una funzione separata e una logica di invio aggiornata.

Librerie di validazione popolari: Android Saripaar (annotazioni @Email, @NotEmpty, @Password), Apache Commons Validator (validazione di email, URL, numero di carta di credito), RxBinding + RxJava per validazione reattiva. Saripaar consente di inserire annotazioni direttamente sui campi di input e chiamare la validazione con una riga: validator.validate(). La libreria mostra automaticamente gli errori tramite setError.

Google raccomanda di utilizzare Material Design Components con TextInputLayout. La validazione integrata tramite setError, setHelperText e setCounterEnabled copre scenari di base senza librerie di terze parti. Per progetti complessi (fintech, sanità), è meglio utilizzare una combinazione: Material Components + validazione personalizzata con pattern dal livello di dominio di Clean Architecture.

Errori comuni nella validazione dei campi

Il primo errore è mostrare un errore prima dell'inizio dell'input. Se un campo è obbligatorio ma l'utente non ha iniziato a compilarlo, non mostrare “Campo obbligatorio”. Questo crea una falsa sensazione di problema. Un errore dovrebbe apparire solo dopo che l'utente ha interagito con il campo: ha iniziato a digitare, ha lasciato il campo, ha tentato di inviare il modulo.

Il secondo errore è un messaggio di errore poco chiaro. Il messaggio dovrebbe essere specifico e suggerire come risolvere il problema. “Email non valida” è negativo. “L'email deve contenere @ e un dominio, ad esempio user@example.com” è positivo. L'utente dovrebbe capire esattamente cosa non va e come risolverlo senza consultare la documentazione.

Il terzo errore è bloccare l'invio senza spiegazione. Se il pulsante di invio è inattivo a causa di errori di validazione, l'utente dovrebbe vedere quali campi non sono validi. Un pulsante grigio senza messaggi è un vicolo cieco per l'utente. Evidenzia sempre i campi con errori e mostra il testo dell'errore accanto a ciascun campo non valido.