Validate: what it is, input field validation and implementation in Android

What is field validation in Android?

Field validation is the verification of a single value entered by the user against specified rules. Each field has its own data type: email, number, phone, password, text. Each type has its own criteria: format, length, value range, required status. Field validation answers the question: is the input in this field correct?

The difference between field validation and form validation is that a field is checked independently of other fields. Email is validated against an email pattern, phone against a phone pattern. If a field is invalid, the user sees an error for that specific field. The form may remain unsent even if one field fails validation. Field validation is the building block for complete form validation.

According to UX research, users expect to see a validation error no later than 1-2 seconds after completing input. A delay of more than 3 seconds is perceived as an application problem. This is why real-time validation via TextWatcher is preferable to checking only when the submit button is pressed.

Main field validation methods

There are three main approaches to field validation in Android. The first is manual checking through conditional operators (if, when). The developer writes a function that takes a string and returns a Boolean or error message. This approach gives full control over the logic but requires writing code for each field and each condition.

The second approach is using built-in Android classes. For example, Patterns.EMAIL_ADDRESS.matcher(email).matches() validates an email against a standard pattern. Patterns.PHONE.matcher(phone).matches() validates a phone number. TextUtils.isEmpty() checks for emptiness. These methods cover basic scenarios without adding external dependencies.

The third approach is validation libraries. Libraries like InputValidator, AndroidValidator or Commons Validator provide ready-made annotations and validation chains. The developer describes rules declaratively: @Email, @NotEmpty, @MinLength(6). The library itself performs validation and returns a list of errors. This speeds up development but adds a dependency.

Validating email, phone and password

For email, standard validation includes checking for the @ symbol, a domain part, and the absence of spaces and Cyrillic characters. Android provides Patterns.EMAIL_ADDRESS, which covers most legitimate email addresses. However, if specific validation is required (e.g., only corporate domains), a custom regex must be written. Email is validated after input is complete, not after each character.

Phone number is validated against a country or region mask. For international numbers, the E.164 format is used: +country code, operator code, number. Google's libphonenumber library is the industry standard for phone validation. It determines the country by code, checks the length and format of the number. In Android, PhoneNumberUtils.isGlobalPhoneNumber can be used for basic validation.

Password has several complexity criteria: minimum length, presence of uppercase and lowercase letters, digits, special characters. Android has no built-in class for password validation — each project defines its own requirements. Typically, a password is validated through a regular expression or a set of conditions. It is important not to reveal exact requirements in the error message: “Password is too simple” is better than “An uppercase letter and a digit are required”.

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

In the example, validatePassword returns a ValidationResult with an isValid field and an optional error message. This approach is convenient for composition: several checks are performed sequentially, and the first error found is returned. Email and phone validation follow the same principle — each returns a result with a message or success.

When to perform validation?

Validation timing critically affects UX. There are three strategies: validation after each character (instant), after losing focus (onFocusLost), and on form submission (onSubmit). Each strategy suits different scenarios. Instant validation is good for fields with strict constraints — phone number, PIN code. OnFocusLost works for email and name. OnSubmit works for required fields.

According to Material Design Guidelines, it is recommended to combine strategies: a field should be validated on focus loss and also on form submission. Instant validation is appropriate when the constraint is obvious — for example, maximum field length. If an error is shown after each character for email, the user will see a message before finishing input. This is annoying and reduces conversion.

The first error rule: when submitting a form, show an error only for the first invalid field. Do not overwhelm the user with a list of 10 errors. After fixing the first error, the next one can be shown. This step-by-step guidance reduces cognitive load and helps the user fill out the form faster.

Tools and libraries for validation

The Android SDK provides basic tools for Validate: Patterns for email and phone, TextUtils for checking emptiness, regular expressions for arbitrary patterns. For projects with 1-3 fields, this is sufficient. However, in forms with 10+ fields, manual validation becomes difficult to maintain — each new field requires a separate function and updated submission logic.

Popular validation libraries: Android Saripaar (annotations @Email, @NotEmpty, @Password), Apache Commons Validator (email, URL, credit card number validation), RxBinding + RxJava for reactive validation. Saripaar allows you to put annotations directly on input fields and call validation with one line: validator.validate(). The library automatically shows errors via setError.

Google recommends using Material Design Components with TextInputLayout. Built-in validation via setError, setHelperText and setCounterEnabled covers basic scenarios without third-party libraries. For complex projects (fintech, healthcare), it is better to use a combination: Material Components + custom validation with patterns from the domain layer of Clean Architecture.

Common errors in field validation

The first error is showing an error before input begins. If a field is required but the user has not started filling it, do not show “Field is required”. This creates a false sense of a problem. An error should appear only after the user has interacted with the field: started typing, left the field, or tried to submit the form.

The second error is an unclear error message. The message should be specific and suggest how to fix the problem. “Invalid email” is bad. “Email must contain @ and a domain, e.g. user@example.com” is good. The user should understand what exactly is wrong and how to fix it without referring to documentation.

The third error is blocking submission without explanation. If the submit button is inactive due to validation errors, the user should see which fields are invalid. A gray button without messages is a dead end for the user. Always highlight fields with errors and show the error text next to each invalid field.