Validate: что это, валидация полей ввода и реализация в Android

Что такое валидация поля в Android?

Валидация поля — это проверка одного конкретного значения, введённого пользователем, на соответствие заданным правилам. Каждое поле имеет свой тип данных: email, число, телефон, пароль, текст. Для каждого типа существуют свои критерии: формат, длина, диапазон значений, обязательность. Валидация поля отвечает на вопрос: корректен ли ввод в этом поле?

Отличие валидации поля от валидации формы в том, что поле проверяется независимо от других полей. Email проверяется по шаблону email, телефон — по шаблону телефона. Если поле невалидно, пользователь видит ошибку именно для этого поля. Форма при этом может оставаться неотправленной, даже если одно поле не прошло проверку. Валидация поля — это строительный блок для полной валидации формы.

По данным UX-исследований, пользователи ожидают увидеть ошибку валидации не позднее чем через 1-2 секунды после завершения ввода. Задержка более 3 секунд воспринимается как проблема с приложением. Именно поэтому валидация через TextWatcher в реальном времени предпочтительнее проверки только при нажатии кнопки отправки.

Основные методы валидации полей

Существует три основных подхода к валидации полей в Android. Первый — ручная проверка через условные операторы (if, when). Разработчик пишет функцию, которая принимает строку и возвращает Boolean или сообщение об ошибке. Этот подход даёт полный контроль над логикой, но требует написания кода для каждого поля и каждого условия.

Второй подход — использование встроенных классов Android. Например, Patterns.EMAIL_ADDRESS.matcher(email).matches() проверяет email по стандартному шаблону. Patterns.PHONE.matcher(phone).matches() — номер телефона. TextUtils.isEmpty() — проверяет пустоту. Эти методы покрывают базовые сценарии без подключения внешних зависимостей.

Третий подход — библиотеки валидации. Библиотеки вроде InputValidator, AndroidValidator или Commons Validator предоставляют готовые аннотации и цепочки проверок. Разработчик описывает правила декларативно: @Email, @NotEmpty, @MinLength(6). Библиотека сама выполняет проверку и возвращает список ошибок. Это ускоряет разработку, но добавляет зависимость.

Валидация email, телефона и пароля

Для email стандартная проверка включает наличие символа @, доменной части и отсутствие пробелов и кириллицы. Android предоставляет Patterns.EMAIL_ADDRESS, который покрывает большинство легитимных email-адресов. Однако если требуется специфическая проверка (например, только корпоративные домены), нужно писать кастомную регулярку. Email валидируется после завершения ввода, а не после каждого символа.

Номер телефона проверяется по маске страны или региона. Для международных номеров используется формат E.164: +код страны, код оператора, номер. Библиотека libphonenumber от Google — отраслевой стандарт для валидации телефонов. Она определяет страну по коду, проверяет длину и формат номера. В Android можно использовать PhoneNumberUtils.isGlobalPhoneNumber для базовой проверки.

Пароль имеет несколько критериев сложности: минимальная длина, наличие заглавных и строчных букв, цифр, спецсимволов. В Android нет встроенного класса для проверки пароля — каждый проект определяет свои требования. Обычно пароль проверяется через регулярное выражение или набор условий. Важно не раскрывать точные требования в сообщении об ошибке: "Пароль слишком простой" лучше, чем "Нужна заглавная буква и цифра".

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

В примере validatePassword возвращает ValidationResult с полем isValid и опциональным сообщением об ошибке. Такой подход удобен для композиции: несколько проверок выполняются последовательно, и возвращается первая найденная ошибка. Валидации email и телефона строятся по тому же принципу — каждая возвращает результат с сообщением или успехом.

Когда выполнять валидацию?

Момент валидации критически влияет на UX. Существует три стратегии: валидация после ввода каждого символа (instant), после потери фокуса (onFocusLost) и при отправке формы (onSubmit). Каждая стратегия подходит для разных сценариев. Instant-валидация хороша для полей с жёсткими ограничениями — номер телефона, PIN-код. OnFocusLost — для email и имени. OnSubmit — для обязательных полей.

По данным Material Design Guidelines, рекомендуется комбинировать стратегии: поле должно проверяться при потере фокуса, а также при отправке формы. Instant-валидация уместна, когда ограничение очевидно — например, максимальная длина поля. Если показывать ошибку после каждого символа для email, пользователь увидит сообщение, ещё не закончив ввод. Это раздражает и снижает конверсию.

Правило первой ошибки: при отправке формы показывайте ошибку только для первого невалидного поля. Не заваливайте пользователя списком из 10 ошибок. После исправления первой ошибки можно показать следующую. Это пошаговое руководство снижает когнитивную нагрузку и помогает пользователю быстрее заполнить форму.

Инструменты и библиотеки для валидации

Android SDK предоставляет базовые инструменты для Validate: Patterns для email и телефона, TextUtils для проверки пустоты, регулярные выражения для произвольных шаблонов. Для проектов с 1-3 полями этого достаточно. Однако в формах с 10+ полями ручная валидация становится трудно поддерживаемой — каждое новое поле требует отдельную функцию и обновление логики отправки.

Популярные библиотеки валидации: Android Saripaar (аннотации @Email, @NotEmpty, @Password), Commons Validator от Apache (проверка email, URL, номера кредитной карты), RxBinding + RxJava для реактивной валидации. Saripaar позволяет повесить аннотации прямо на поля ввода и вызвать валидацию одной строкой: validator.validate(). Библиотека автоматически показывает ошибки через setError.

Google рекомендует использовать Material Design Components с TextInputLayout. Встроенная валидация через setError, setHelperText и setCounterEnabled покрывает базовые сценарии без сторонних библиотек. Для сложных проектов (финтех, медицина) лучше использовать комбинацию: Material Components + кастомная валидация с паттернами из domain-слоя Clean Architecture.

Ошибки при валидации полей

Первая ошибка — показывать ошибку до начала ввода. Если поле обязательное, но пользователь ещё не начал его заполнять, не показывайте "Поле обязательно". Это создаёт ложное ощущение проблемы. Ошибка должна появляться только после того, как пользователь взаимодействовал с полем: начал вводить, ушёл из поля, попытался отправить форму.

Вторая ошибка — непонятное сообщение об ошибке. Сообщение должно быть конкретным и подсказывать, как исправить проблему. "Некорректный email" — плохо. "Email должен содержать @ и домен, например user@example.com" — хорошо. Пользователь должен понять, что именно не так и как это исправить, без обращения к документации.

Третья ошибка — блокировка отправки без объяснения. Если кнопка отправки неактивна из-за ошибок валидации, пользователь должен видеть, какие именно поля невалидны. Серая кнопка без сообщений — тупик для пользователя. Всегда подсвечивайте поля с ошибками и показывайте текст ошибки рядом с каждым невалидным полем.