Validate: какво е това, валидация на полета за въвеждане и имплементация в Android

Какво е валидация на поле в Android?

Валидация на поле — е проверка на една конкретна стойност, въведена от потребителя, за съответствие с определени правила. Всяко поле има свой тип данни: имейл, число, телефон, парола, текст. За всеки тип съществуват свои критерии: формат, дължина, диапазон на стойности, задължителност. Валидацията на поле отговаря на въпроса: коректен ли е входът в това поле?

Разликата между валидация на поле и валидация на формуляр е, че полето се проверява независимо от другите полета. Имейлът се проверява според модела на имейл, телефонът — според модела на телефон. Ако полето е невалидно, потребителят вижда грешката точно за това поле. Формулярът може да остане неизпратен, дори ако едно поле не премине проверката. Валидацията на поле е градивен елемент за пълна валидация на формуляр.

Според UX проучвания, потребителите очакват да видят грешка при валидация не по-късно от 1-2 секунди след завършване на въвеждането. Закъснение над 3 секунди се възприема като проблем с приложението. Ето защо валидацията в реално време чрез TextWatcher се предпочита пред проверка само при натискане на бутона за изпращане.

Основни методи за валидация на полета

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

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

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

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

За имейл стандартната проверка включва наличие на символ @, домейн част и липса на интервали и кирилица. Android предоставя Patterns.EMAIL_ADDRESS, който покрива повечето легитимни имейл адреси. Ако обаче се изисква специфична проверка (например, само корпоративни домейни), трябва да се напише персонализиран регулярен израз. Имейлът се валидира след завършване на въвеждането, а не след всеки символ.

Телефонен номер се проверява според маската на държавата или региона. За международни номера се използва формат 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 и опционално съобщение за грешка. Този подход е удобен за композиция: няколко проверки се изпълняват последователно и се връща първата намерена грешка. Валидациите на имейл и телефон се изграждат по същия принцип — всяка връща резултат със съобщение или успех.

Кога да извършвате валидация?

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

Според Material Design Guidelines, се препоръчва комбиниране на стратегии: полето трябва да се проверява при загуба на фокус, както и при изпращане на формуляра. Мигновената валидация е подходяща, когато ограничението е очевидно — например максималната дължина на полето. Ако се показва грешка след всеки символ за имейл, потребителят ще види съобщението, преди да завърши въвеждането. Това дразни и намалява конверсията.

Правило за първата грешка: при изпращане на формуляра показвайте грешка само за първото невалидно поле. Не претоварвайте потребителя със списък от 10 грешки. След коригиране на първата грешка може да се покаже следващата. Това поетапно насочване намалява когнитивното натоварване и помага на потребителя да попълни формуляра по-бързо.

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

Android SDK предоставя основни инструменти за Validate: Patterns за имейл и телефон, TextUtils за проверка на празнота, регулярни изрази за произволни модели. За проекти с 1-3 полета това е достатъчно. Във формуляри с 10+ полета обаче ръчната валидация става трудна за поддръжка — всяко ново поле изисква отделна функция и актуализиране на логиката за изпращане.

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

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

Грешки при валидация на полета

Първа грешка — показване на грешка преди започване на въвеждане. Ако полето е задължително, но потребителят все още не е започнал да го попълва, не показвайте „Полето е задължително". Това създава фалшиво усещане за проблем. Грешката трябва да се появи само след като потребителят е взаимодействал с полето: започнал да въвежда, напуснал полето, опитал да изпрати формуляра.

Втора грешка — неясно съобщение за грешка. Съобщението трябва да бъде конкретно и да подсказва как да се реши проблемът. „Невалиден имейл" — лошо. „Имейлът трябва да съдържа @ и домейн, например user@example.com" — добре. Потребителят трябва да разбере какво точно не е наред и как да го поправи, без да се консултира с документацията.

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