Error State — qu'est-ce que c'est, affichage des erreurs de champ et implémentation dans Android

Qu'est-ce que l'état d'erreur de champ dans Android ?

Error State est un mode d'affichage spécial d'un champ de saisie qui s'active lorsque les données saisies échouent à la validation. Visuellement, Error State comprend trois composants : un changement de couleur de la bordure ou du fond du champ (généralement en rouge), l'apparition d'un message texte sous le champ décrivant l'erreur, et optionnellement une icône ou un surlignage. Le but de Error State est d'attirer instantanément l'attention de l'utilisateur sur le champ problématique et de suggérer comment corriger l'erreur.

Dans Android, Error State est implémenté au niveau de TextInputLayout de Material Design Components. TextInputLayout encapsule EditText et gère ses états : normal, focused, error, disabled. La méthode setError(String) bascule le champ en état d'erreur, modifie la couleur de la bordure et affiche le message. Lorsque le texte change ou que setError(null) est appelé, le champ revient à l'état normal.

Selon les Material Design Guidelines, Error State doit être visible mais pas dominant. La couleur rouge de la bordure doit contraster avec l'état normal mais sans surcharger l'interface. Le message d'erreur doit contenir des informations spécifiques sur le problème et comment le résoudre. Une icône d'erreur (par exemple, un cercle rouge avec un point d'exclamation) renforce le signal visuel.

Comment setError fonctionne dans TextInputLayout

La méthode setError(CharSequence errorText) bascule TextInputLayout en état d'erreur. Le paramètre errorText est le texte affiché sous le champ. Si null est passé, l'erreur est effacée. TextInputLayout gère l'animation : le texte d'erreur apparaît avec un fondu en douceur, la bordure passe au rouge. Une icône d'erreur (par défaut : point d'exclamation dans un cercle) est affichée à la fin du champ.

Détails importants : setErrorEnabled(true) doit être appelé avant setError pour réserver l'espace pour le message d'erreur. Sinon, la disposition peut « sauter » lorsque l'erreur apparaît car l'espace n'est pas réservé. Il est recommandé de toujours activer le support d'erreur en XML via app:errorEnabled="true" pour éviter les décalages de disposition.

La méthode setError est automatiquement effacée lorsque le texte du champ change si setErrorEnabled(true) est activé. Ce comportement est pratique pour la validation en temps réel : dès que l'utilisateur commence à corriger l'erreur, la bordure rouge disparaît et le champ revient à l'état normal. Cependant, pour des scénarios complexes, cet effacement automatique peut être indésirable — dans ces cas, gérez l'erreur manuellement.

val til = findViewById<TextInputLayout>(R.id.til_email)

// Activer le support d'erreur (définir en XML sinon)
til.isErrorEnabled = true

// Définir le message d'erreur
til.error = "Invalid email address"

// Effacer l'erreur
til.error = null

// Vérifier si l'erreur existe
if (til.error != null) {
    // Le champ est en état d'erreur
}

L'exemple utilise les propriétés Kotlin pour accéder à setError/isErrorEnabled. TextInputLayout met automatiquement à jour l'interface : modifie boxStrokeColor, affiche l'icône d'erreur, affiche le texte d'erreur. Si le texte dans EditText change, l'erreur est effacée automatiquement. Pour une réinitialisation manuelle, définissez error = null.

Moyens alternatifs d'affichage des erreurs

Tous les projets n'utilisent pas Material Design Components. Pour un affichage d'erreur personnalisé, vous pouvez utiliser un TextView séparé sous EditText qui devient visible en cas d'erreur. Cette approche offre un contrôle total sur les styles et le placement du message. Par exemple, vous pouvez placer le message à droite du champ, utiliser une couleur de fond différente ou ajouter une icône à gauche du texte.

Dans Jetpack Compose, Error State est implémenté via le paramètre isError dans OutlinedTextField ou TextField. Lorsque isError = true, la bordure devient rouge et vous pouvez afficher le texte d'erreur via supportingText. Compose n'a pas d'effacement automatique intégré lors du changement de texte — le développeur gère l'état d'erreur manuellement avec remember et mutableStateOf.

Pour les erreurs de groupe (un seul message pour plusieurs champs, par exemple, « Remplissez tous les champs obligatoires »), utilisez Snackbar, Dialog ou un bloc en ligne en haut du formulaire. Une erreur de groupe ne remplace pas l'Error State des champs individuels mais le complète. L'utilisateur voit d'abord le message général, puis cherche les champs spécifiques avec des erreurs.

Couleurs, icônes et animation des erreurs

La couleur de Error State dans Material Design Components est contrôlée via l'attribut boxStrokeErrorColor ou l'attribut colorError dans le thème. Par défaut, la couleur rouge système est utilisée, mais elle peut être redéfinie dans le thème de l'application ou directement dans TextInputLayout via app:boxStrokeErrorColor="@color/customErrorColor". Pour la prise en charge du thème sombre, il est recommandé d'utiliser un sélecteur avec différentes couleurs pour les modes clair et sombre.

Icône d'erreur est configurée via app:errorIconDrawable. Par défaut, un point d'exclamation dans un cercle est affiché. Elle peut être remplacée par une icône personnalisée ou supprimée complètement en définissant app:errorIconDrawable="@null". L'icône est affichée à la fin de TextInputLayout et sert de marqueur visuel supplémentaire. Dans Material Design 3, l'icône d'erreur est obligatoire pour l'accessibilité.

L'animation d'apparition de l'erreur est intégrée dans TextInputLayout : le texte glisse du bas avec un changement progressif d'opacité. Pour une animation personnalisée, utilisez Transition API ou MotionLayout. Par exemple, secouer le champ lors d'une erreur attire une attention supplémentaire. Cependant, l'utilisation excessive d'animations dégrade l'UX — une apparition en douceur du message est suffisante.

Gestion de l'état d'erreur lors de la validation

La gestion de Error State se divise en deux étapes : définir l'erreur lors de la validation du champ et effacer l'erreur lors de la correction. Dans le cas le plus simple, la validation est appelée dans TextWatcher.afterTextChanged : si la valeur est invalide, setError est appelé avec un message d'erreur. Si valide, setError(null) est appelé. TextInputLayout masque automatiquement l'erreur lorsque setError(null) efface l'état.

Pour la validation de formulaire, les erreurs sont définies lors de l'étape d'envoi du formulaire. Parcourez tous les champs, validez chacun, définissez les erreurs pour les champs invalides et concentrez-vous sur le premier champ erroné. Le bouton d'envoi est bloqué pendant ce processus. Si le formulaire est grand, il est recommandé de faire défiler jusqu'au premier champ avec erreur et de définir le focus automatiquement.

La règle du focus unique d'erreur : lors de l'envoi d'un formulaire, définissez le focus uniquement sur le premier champ avec erreur. L'utilisateur corrige une erreur à la fois, et après la correction, le champ suivant avec erreur reçoit automatiquement le focus. Cette approche étape par étape réduit la charge cognitive. Material TextInputLayout n'intercepte pas le focus lors de la définition d'une erreur — cela doit être fait manuellement via requestFocus().

Erreurs courantes lors du travail avec Error State

La première erreur — absence de isErrorEnabled. Si setErrorEnabled n'est pas appelé avant setError, la disposition peut se décaler lorsque le message d'erreur apparaît. C'est particulièrement critique si le champ est au milieu de l'écran — l'utilisateur perd sa position de défilement. Activez toujours setErrorEnabled(true) en XML via app:errorEnabled="true" ou par programmation avant de définir une erreur.

La deuxième erreur — message d'erreur trop long. Un texte long se répartit sur plusieurs lignes et peut chevaucher les champs voisins. La longueur recommandée du message d'erreur est de 20 à 40 caractères. Si plus d'informations sont nécessaires, utilisez helperText à l'état normal ou une info-bulle pour des explications supplémentaires. La brièveté est la base d'un bon Error State.

La troisième erreur — ignorer l'accessibilité. Error State doit être accessible aux lecteurs d'écran. TextInputLayout annonce automatiquement l'erreur via contentDescription, mais les implémentations personnalisées doivent le faire manuellement. Utilisez announceForAccessibility() ou android:importantForAccessibility pour les messages d'erreur. Les utilisateurs de TalkBack doivent entendre l'erreur immédiatement après son apparition.