Валидација обрасца — шта је то, валидација обрасца и имплементација у Android-у
Form Validation је процес провере исправности свих поља обрасца пре слања података на сервер. За разлику од валидације појединачног поља, Form Validation узима у обзир међусобне везе између поља: потврду лозинке, зависност једног поља од другог, условну обавезност. Према подацима Google Developers, 2026, Form Validation треба да провери цео образац при слању и пружи кориснику преглед свих грешака. Исправна валидација обрасца повећава конверзију регистрације за 25-35% и смањује број грешака при уносу.
Главно
- Form Validation — свеобухватна провера свих поља и њихових међусобних веза пре слања података.
- Валидација поља проверава једно поље независно, а валидација обрасца — сва поља заједно.
- Управљање дугметом за слање — дугме треба да буде неактивно док је бар једно поље неважеће.
- Библиотеке за валидацију попут Saripaar и RxBinding поједностављују проверу обрасца са десетинама поља.
- Валидација при слању — обавезна фаза, чак и ако се поља проверавају у реалном времену.
Шта је валидација обрасца у Android-у?
Form Validation је процес који гарантује да сви подаци које је корисник унео у образац задовољавају пословне захтеве пре слања на сервер. Валидација обрасца укључује проверу сваког поља појединачно, као и унакрсне провере: да ли се лозинка поклапа са потврдом, да ли је изабрано бар једно поље за потврду, да ли су попуњена сва обавезна поља, да ли је датум исправан (нпр. датум рођења није у будућности).
Разлика од једноставне валидације поља је у томе што Form Validation оперише обрасцем као јединственом целином. Може да блокира слање ако условно поље није попуњено или да прикаже преглед грешака у дијалошком прозору. У сложеним обрасцима (регистрација, наручивање, упитник) валидација обрасца је посебан слој логике који се тестира независно од UI-ја.
Према UX истраживањима NN Group, корисници 3 пута чешће завршавају попуњавање обрасца ако виде грешке одмах након слања, а не након сваког поља појединачно. Међутим, најбољи резултат даје комбинација: тренутна валидација једноставних поља (дужина, формат) + потпуна провера при слању за унакрсна поља и пословну логику.
Разлике између валидације поља и валидације обрасца
Валидација поља одговара на питање: да ли је унос у овом конкретном пољу исправан? Емаил има формат user@domain.com, телефон се састоји од цифара, лозинка је дужа од 6 карактера. Валидација поља је изолована — не зависи од других поља и може се извршавати у реалном времену. Резултат: грешка за конкретно поље или њено одсуство.
Валидација обрасца одговара на питање: да ли се образац може послати у целини? Узима у обзир не само свако поље, већ и њихове комбинације: лозинка и потврда морају бити усклађени, датум почетка не може бити каснији од датума завршетка, збир поља мора бити 100%. Валидација обрасца се извршава при слању и враћа општи резултат: образац је важећи или није.
Архитектонски, валидација поља се смешта у UI слој (фрагмент, ViewModel), а валидација обрасца — у доменски слој (use case, interactor). Ово омогућава поновну употребу валидације обрасца у различитим UI компонентама и њено тестирање без емулатора. У Clean Architecture валидација обрасца је пословно правило, а не UI логика.
| Критеријум | Валидација поља | Валидација обрасца |
|---|---|---|
| Објекат провере | Једно поље | Сва поља + њихове међусобне везе |
| Тренутак извршења | У реалном времену / при губитку фокуса | При слању обрасца |
| Резултат | Грешка конкретног поља | Општи статус обрасца + листа грешака |
| Архитектонски слој | UI слој | Доменски слој |
Приступи валидацији обрасца
Постоје два основна приступа Form Validation. Први — императивни: програмер пише функцију која секвенцијално проверава свако поље и прикупља листу грешака. Овај приступ је једноставан за разумевање, али код расте са сваким новим пољем. За образац са 5 поља императивни приступ је још увек згодан, за 15 поља — већ проблематичан.
Други приступ — декларативни: правила валидације се описују анотацијама или конфигурацијом. Библиотека сама обилази сва поља, примењује правила и враћа резултат. Пример: анотација @Email изнад поља emailData, @ConfirmPassword изнад поља за потврду. Декларативни приступ скраћује код валидације 3-5 пута и чини га читљивим.
Трећи приступ — реактивни коришћењем RxJava или Kotlin Flow. Свако поље је представљено као Observable или StateFlow. Валидација обрасца се претплаћује на промене свих поља и прерачунава опште стање при свакој промени. Дугме за слање аутоматски постаје активно када су сва поља важећа. Овај приступ захтева разумевање реактивног програмирања, али пружа најглаткији UX.
Пример валидације обрасца регистрације
Размотримо образац регистрације са три поља: емаил, лозинка и потврда лозинке. Валидација обрасца укључује: проверу емаила кроз Patterns.EMAIL_ADDRESS, проверу лозинке на минималну дужину од 8 карактера и присуство цифре, проверу поклапања лозинке и потврде. Тек када све три провере прођу, образац се може послати.
kotlin
data class RegistrationForm(
val email: String,
val password: String,
val confirmPassword: String
)
fun validateRegistration(form: RegistrationForm): ValidationResult {
if (!Patterns.EMAIL_ADDRESS.matcher(form.email).matches())
return ValidationResult(false, "Invalid email address")
if (form.password.length < 8)
return ValidationResult(false, "Password too short")
if (form.password != form.confirmPassword)
return ValidationResult(false, "Passwords do not match")
return ValidationResult(true)
}У примеру, validateRegistration прима data class обрасца и враћа ValidationResult. Ако бар једна провера не прође, враћа се false са одговарајућом поруком. Управљање дугметом за слање се заснива на Result: ако је isValid = true, дугме је активно. За ажурирање стања у реалном времену може се користити LiveData<ValidationResult> и ажурирати дугме при свакој промени било ког поља.
Реактивни приступ са Kotlin Flow омогућава аутоматско прерачунавање стања обрасца. Свако поље је представљено као MutableStateFlow<String>, а combine их спаја у један Flow<ValidationResult>. Претплата у UI-ју ажурира дугме за слање без ручног позивања валидације. Овај образац препоручује Google за Jetpack Compose и MVVM архитектуру.
Библиотеке за валидацију образаца
Android Saripaar — најпопуларнија библиотека за валидацију за Android. Омогућава директно анотирање поља и View-ова: @Email, @NotEmpty, @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). Валидација се позива једним редом validator.validate() са callback-ом. Saripaar аутоматски поставља грешку путем setError на EditText. Библиотека такође подржава прилагођене анотације за специфична пословна правила.
RxBinding + RxJava — реактивни приступ без посебне библиотеке за валидацију. Свако поље објављује промене кроз RxTextView.textChanges(). Оператор combineLatest спаја сва поља и израчунава општи статус. Предност: потпуна контрола над pipeline-ом валидације, могућност додавања debounce, throttle, filter. Недостатак: захтева познавање RxJava.
Material Design Components — уграђена подршка за TextInputLayout и TextInputEditText. Библиотека не пружа валидацију као такву, али даје UI за приказивање грешака: setError(), setHelperText(), setCounterEnabled(). За саму валидацију је и даље потребна ручна логика или Saripaar. Material Components су задужени за приказ, а не за проверу.
Типичне грешке при валидацији обрасца
Прва грешка — валидација само на клијенту. Form Validation на клијенту је намењена за UX, а не за безбедност. Нападач може послати захтев директно ка API-ју, заобилазећи валидацију. Сервер мора поново да провери сва поља. Клијентска валидација не треба да буде једина заштита — то је додатни слој за удобност корисника, а не за безбедност података.
Друга грешка — блокирање дугмета за слање без порука. Ако је дугме неактивно, корисник мора да види која поља треба да исправи. Сиво дугме без објашњења — један од најчешћих узрока ниске конверзије образаца. Увек приказујте грешке поља поред њих, чак и ако је дугме блокирано. Корисник мора да разуме шта тачно спречава слање.
Трећа грешка — игнорисање унакрсних поља. Валидација сваког поља појединачно је недовољна. Поља могу зависити једна од других: лозинка и потврда, датум почетка и датум завршетка, држава и град. Form Validation мора да провери ове међусобне везе. Провера само појединачних поља ствара лажни осећај сигурности — образац може бити послат са неусаглашеним подацима.
| Грешка | Последица | Решење |
|---|---|---|
| Само клијентска валидација | Безбедносна рањивост | Обавезна серверска провера |
| Дугме без порука | Ниска конверзија обрасца | Приказивати грешке поља |
| Нема унакрсних провера | Неусаглашени подаци | Валидација међусобних веза поља |
| Пречесте провере | Иритација корисника | Debounce и провера при губитку фокуса |
Често постављана питања
По чему се Form Validation разликује од валидације поља?
Валидација поља проверава једну вредност у погледу формата или дужине. Form Validation проверава сва поља заједно, укључујући унакрсне провере: поклапање лозинки, зависност поља једно од другог. Валидација поља се извршава у UI слоју, Form Validation — у доменском слоју као пословно правило.
Како управљати дугметом за слање обрасца?
Користите реактивни приступ: обједините сва поља у један Flow или Observable и претплатите се на промене. При свакој промени било ког поља прерачунајте општи статус обрасца. Ако је статус важећи — дугме је активно. Користите Kotlin Flow са combine или RxJava са combineLatest за аутоматско ажурирање.
Која библиотека за валидацију је најбоља за Android?
Android Saripaar — најбољи избор за декларативну валидацију са анотацијама. Ако пројекат користи RxJava — RxBinding обезбеђује реактивни приступ без посебне библиотеке. За једноставне обрасце довољна је ручна валидација са Patterns и TextUtils без спољних зависности.
Да ли је потребна валидација на серверу ако постоји клијентска?
Обавезно. Клијентска валидација побољшава UX, али не обезбеђује сигурност. Сервер мора поново да провери све податке, јер је API директно доступан. Никада се не ослањајте само на клијентску валидацију за заштиту од неисправних или злонамерних података.
Како валидирати образац у Jetpack Compose-у?
У Jetpack Compose-у користите Kotlin Flow или StateFlow за чување стања сваког поља. Функција валидације прима стање обрасца и враћа ValidationResult. Дугме за слање се претплаћује на општи статус. За приказивање грешака користите isError у OutlinedTextField или TextField Compose-у.
Закључци
- Form Validation — свеобухватна провера свих поља обрасца и њихових међусобних веза пре слања података.
- Валидација поља је изолована и извршава се у UI-ју; валидација обрасца узима у обзир унакрсне зависности и припада доменском слоју.
- Дугме за слање треба да буде неактивно при неважећем обрасцу — са обавезним приказивањем грешака поља.
- Android Saripaar — главна библиотека за декларативну валидацију са анотацијама.
- RxBinding/Flow — реактивни приступ за аутоматско прерачунавање статуса обрасца при промени било ког поља.
- Серверска валидација је обавезна као сигурносни слој, клијентска — само за UX.
- Унакрсне провере — обавезан елемент Form Validation, без њих образац може послати неусаглашене податке.
Развићемо мобилну апликацију под кључ
IT Sectr креира iOS и Android апликације за стартапе и предузећа од 2017. године. Саветоваћемо вас и предложити најбоље решење.
Прочитајте такође