Validate: qué es, validación de campos de entrada e implementación en Android

¿Qué es la validación de campo en Android?

La validación de campo es la verificación de un único valor introducido por el usuario según las reglas especificadas. Cada campo tiene su propio tipo de datos: email, número, teléfono, contraseña, texto. Cada tipo tiene sus propios criterios: formato, longitud, rango de valores, obligatoriedad. La validación de campo responde a la pregunta: ¿es correcta la entrada en este campo?

La diferencia entre la validación de campo y la validación de formulario es que un campo se verifica independientemente de otros campos. El email se valida según un patrón de email, el teléfono según un patrón de teléfono. Si un campo no es válido, el usuario ve un error para ese campo específico. El formulario puede permanecer sin enviar incluso si un campo no pasa la validación. La validación de campo es el bloque de construcción para la validación completa del formulario.

Según investigaciones de UX, los usuarios esperan ver un error de validación no más tarde de 1-2 segundos después de completar la entrada. Un retraso de más de 3 segundos se percibe como un problema de la aplicación. Es por eso que la validación en tiempo real mediante TextWatcher es preferible a comprobar solo cuando se presiona el botón de envío.

Principales métodos de validación de campos

Hay tres enfoques principales para la validación de campos en Android. El primero es la comprobación manual mediante operadores condicionales (if, when). El desarrollador escribe una función que toma una cadena y devuelve un Boolean o un mensaje de error. Este enfoque da control total sobre la lógica, pero requiere escribir código para cada campo y cada condición.

El segundo enfoque es el uso de clases integradas de Android. Por ejemplo, Patterns.EMAIL_ADDRESS.matcher(email).matches() valida un email según un patrón estándar. Patterns.PHONE.matcher(phone).matches() valida un número de teléfono. TextUtils.isEmpty() comprueba si está vacío. Estos métodos cubren escenarios básicos sin añadir dependencias externas.

El tercer enfoque son las bibliotecas de validación. Bibliotecas como InputValidator, AndroidValidator o Commons Validator proporcionan anotaciones y cadenas de validación listas para usar. El desarrollador describe las reglas de forma declarativa: @Email, @NotEmpty, @MinLength(6). La propia biblioteca realiza la validación y devuelve una lista de errores. Esto acelera el desarrollo, pero añade una dependencia.

Validación de email, teléfono y contraseña

Para el email, la validación estándar incluye la comprobación de la presencia del símbolo @, una parte de dominio y la ausencia de espacios y caracteres cirílicos. Android proporciona Patterns.EMAIL_ADDRESS, que cubre la mayoría de las direcciones de email legítimas. Sin embargo, si se requiere una validación específica (por ejemplo, solo dominios corporativos), se debe escribir una expresión regular personalizada. El email se valida después de completar la entrada, no después de cada carácter.

El número de teléfono se valida según una máscara de país o región. Para números internacionales se utiliza el formato E.164: +código de país, código de operador, número. La biblioteca libphonenumber de Google es el estándar de la industria para la validación de teléfonos. Determina el país por el código, comprueba la longitud y el formato del número. En Android, se puede usar PhoneNumberUtils.isGlobalPhoneNumber para la validación básica.

La contraseña tiene varios criterios de complejidad: longitud mínima, presencia de mayúsculas y minúsculas, dígitos, caracteres especiales. Android no tiene una clase integrada para la validación de contraseñas — cada proyecto define sus propios requisitos. Normalmente, una contraseña se valida mediante una expresión regular o un conjunto de condiciones. Es importante no revelar los requisitos exactos en el mensaje de error: “La contraseña es demasiado simple” es mejor que “Se requiere una letra mayúscula y un dígito”.

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

En el ejemplo, validatePassword devuelve un ValidationResult con un campo isValid y un mensaje de error opcional. Este enfoque es conveniente para la composición: varias comprobaciones se realizan secuencialmente y se devuelve el primer error encontrado. La validación de email y teléfono sigue el mismo principio — cada una devuelve un resultado con un mensaje o éxito.

¿Cuándo realizar la validación?

El momento de la validación afecta críticamente a la UX. Existen tres estrategias: validación después de cada carácter (instantánea), después de perder el foco (onFocusLost) y al enviar el formulario (onSubmit). Cada estrategia es adecuada para diferentes escenarios. La validación instantánea es buena para campos con restricciones estrictas — número de teléfono, código PIN. OnFocusLost funciona para email y nombre. OnSubmit funciona para campos obligatorios.

Según las Material Design Guidelines, se recomienda combinar estrategias: un campo debe validarse al perder el foco y también al enviar el formulario. La validación instantánea es apropiada cuando la restricción es obvia — por ejemplo, la longitud máxima del campo. Si se muestra un error después de cada carácter para el email, el usuario verá un mensaje antes de terminar la entrada. Esto es molesto y reduce la conversión.

La regla del primer error: al enviar un formulario, muestre un error solo para el primer campo no válido. No abrume al usuario con una lista de 10 errores. Después de corregir el primer error, se puede mostrar el siguiente. Esta guía paso a paso reduce la carga cognitiva y ayuda al usuario a completar el formulario más rápido.

Herramientas y bibliotecas para la validación

El SDK de Android proporciona herramientas básicas para Validate: Patterns para email y teléfono, TextUtils para comprobar vacíos, expresiones regulares para patrones arbitrarios. Para proyectos con 1-3 campos, esto es suficiente. Sin embargo, en formularios con 10+ campos, la validación manual se vuelve difícil de mantener — cada nuevo campo requiere una función separada y una lógica de envío actualizada.

Bibliotecas de validación populares: Android Saripaar (anotaciones @Email, @NotEmpty, @Password), Apache Commons Validator (validación de email, URL, número de tarjeta de crédito), RxBinding + RxJava para validación reactiva. Saripaar permite poner anotaciones directamente en los campos de entrada y llamar a la validación con una línea: validator.validate(). La biblioteca muestra automáticamente los errores mediante setError.

Google recomienda usar Material Design Components con TextInputLayout. La validación integrada mediante setError, setHelperText y setCounterEnabled cubre escenarios básicos sin bibliotecas de terceros. Para proyectos complejos (fintech, salud), es mejor usar una combinación: Material Components + validación personalizada con patrones de la capa de dominio de Clean Architecture.

Errores comunes en la validación de campos

El primer error es mostrar un error antes de comenzar la entrada. Si un campo es obligatorio pero el usuario no ha empezado a rellenarlo, no muestre “El campo es obligatorio”. Esto crea una falsa sensación de problema. Un error debe aparecer solo después de que el usuario haya interactuado con el campo: empezó a escribir, salió del campo, intentó enviar el formulario.

El segundo error es un mensaje de error poco claro. El mensaje debe ser específico y sugerir cómo solucionar el problema. “Email no válido” es malo. “El email debe contener @ y un dominio, por ejemplo user@example.com” es bueno. El usuario debe entender qué está mal exactamente y cómo solucionarlo sin consultar la documentación.

El tercer error es bloquear el envío sin explicación. Si el botón de envío está inactivo debido a errores de validación, el usuario debe ver qué campos no son válidos. Un botón gris sin mensajes es un callejón sin salida para el usuario. Siempre resalte los campos con errores y muestre el texto del error junto a cada campo no válido.