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). Свака стратегија је погодна за различите сценарије. Тренутна валидација је добра за поља са строгим ограничењима — број телефона, PIN код. OnFocusLost — за email и име. OnSubmit — за обавезна поља.

Према Material Design Guidelines, препоручује се комбиновање стратегија: поље треба проверити при губитку фокуса, као и при слању обрасца. Тренутна валидација је прикладна када је ограничење очигледно — на пример, максимална дужина поља. Ако се приказује грешка након сваког знака за 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 + прилагођена валидација са обрасцима из доменског слоја Clean Architecture.

Грешке при валидацији поља

Прва грешка — приказивање грешке пре почетка уноса. Ако је поље обавезно, али корисник још није почео да га попуњава, не приказујте „Поље је обавезно". Ово ствара лажни утисак проблема. Грешка треба да се појави тек након што је корисник интераговао са пољем: почео да уноси, изашао из поља, покушао да пошаље образац.

Друга грешка — неразумљива порука о грешци. Порука треба да буде конкретна и да сугерише како да се проблем реши. „Неисправан email" — лоше. „Email мора да садржи @ и домен, на пример user@example.com" — добро. Корисник треба да разуме шта тачно није у реду и како да то поправи без консултовања документације.

Трећа грешка — блокирање слања без објашњења. Ако је дугме за слање неактивно због грешака валидације, корисник треба да види која су поља невалидна. Сиво дугме без порука представља ћорсокак за корисника. Увек истичите поља са грешкама и приказујте текст грешке поред сваког невалидног поља.