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» — добре. Користувач повинен зрозуміти, що саме не так і як це виправити, без звернення до документації.

Третя помилка — блокування відправки без пояснення. Якщо кнопка відправки неактивна через помилки валідації, користувач повинен бачити, які саме поля невалідні. Сіра кнопка без повідомлень — глухий кут для користувача. Завжди підсвічуйте поля з помилками та показуйте текст помилки поруч із кожним невалідним полем.