Forma tekshiruvi — bu nima, forma tekshiruvi va Android-da qo'llash
Form Validation — ma'lumotlarni serverga yuborishdan oldin forma maydonlarining barchasining to'g'riligini tekshirish jarayoni. Alohida maydonni tekshirishdan farqli o'laroq, Form Validation maydonlar orasidagi o'zaro bog'liqliklarni hisobga oladi: parolni tasdiqlash, bir maydonning boshqasiga bog'liqligi, shartli majburiylik. Google Developers, 2026 ma'lumotlariga ko'ra, Form Validation yuborish paytida formani to'liq tekshirishi va foydalanuvchiga barcha xatolar haqida umumiy ma'lumot berishi kerak. To'g'ri forma tekshiruvi ro'yxatdan o'tish konversiyasini 25-35% ga oshiradi va kiritishdagi xatolar sonini kamaytiradi.
Asosiy ma'lumotlar
- Form Validation — ma'lumotlarni yuborishdan oldin barcha maydonlar va ularning o'zaro bog'liqliklarini kompleks tekshirish.
- Maydonni tekshirish bir maydonni mustaqil tekshiradi, formani tekshirish esa — barcha maydonlarni birgalikda tekshiradi.
- Yuborish tugmasini boshqarish — kamida bitta maydon yaroqsiz bo'lsa, tugma faol bo'lmagan bo'lishi kerak.
- Tekshirish kutubxonalari Saripaar va RxBinding kabi kutubxonalar o'nlab maydonlari bo'lgan formani tekshirishni soddalashtiradi.
- Yuborish paytida tekshirish — maydonlar real vaqtda tekshirilsa ham, majburiy bosqich.
Android-da forma tekshiruvi nima?
Form Validation — foydalanuvchi formaga kiritgan barcha ma'lumotlarning serverga yuborishdan oldin biznes talablariga mos kelishini ta'minlaydigan jarayon. Forma tekshiruvi har bir maydonni alohida tekshirishni, shuningdek o'zaro tekshirishlarni o'z ichiga oladi: parol tasdiqqa mos keladimi, kamida bitta belgilash qutisi tanlanganmi, barcha majburiy maydonlar to'ldirilganmi, sana to'g'rimi (masalan, tug'ilgan sana kelajakda emas).
Oddiy maydon tekshiruvidan farqi shundaki, Form Validation formani yaxlit bir butun sifatida boshqaradi. Shartli maydon to'ldirilmagan bo'lsa, yuborishni bloklashi yoki dialog oynasida xatolar haqida umumiy ma'lumot ko'rsatishi mumkin. Murakkab formalarda (ro'yxatdan o'tish, buyurtma berish, so'rovnoma) forma tekshiruvi UI-dan mustaqil ravishda sinovdan o'tkaziladigan alohida mantiq qatlamidir.
NN Group UX tadqiqotlariga ko'ra, foydalanuvchilar har bir maydondan keyin alohida emas, balki xatolarni yuborishdan keyin darhol ko'rsalar, formani to'ldirishni 3 marta tezroq yakunlaydilar. Biroq, eng yaxshi natija kombinatsiyani beradi: oddiy maydonlarning bir zumda tekshiruvi (uzunlik, format) + o'zaro maydonlar va biznes mantig'i uchun yuborish paytida to'liq tekshirish.
Maydonni tekshirish va formani tekshirish o'rtasidagi farqlar
Maydonni tekshirish savolga javob beradi: bu aniq maydondagi kiritish to'g'rimi? Email user@domain.com formatida, telefon raqamlardan iborat, parol 6 belgidan uzun. Maydonni tekshirish izolyatsiya qilingan — boshqa maydonlarga bog'liq emas va real vaqtda bajarilishi mumkin. Natija: aniq maydon uchun xato yoki uning yo'qligi.
Formani tekshirish savolga javob beradi: formani to'liq yuborish mumkinmi? U nafaqat har bir maydonni, balki ularning kombinatsiyalarini ham hisobga oladi: parol va tasdiq mos kelishi kerak, boshlanish sanasi tugash sanasidan kech bo'lishi mumkin emas, maydonlar yig'indisi 100% bo'lishi kerak. Formani tekshirish yuborish paytida bajariladi va umumiy natijani qaytaradi: forma yaroqli yoki yo'q.
Arxitektura nuqtai nazaridan, maydonni tekshirish UI qatlamida (fragment, ViewModel), formani tekshirish esa domain qatlamida (use case, interactor) joylashtiriladi. Bu forma tekshiruvini turli UI komponentlarida qayta ishlatish va uni emulyatorsiz sinovdan o'tkazish imkonini beradi. Clean Architecture-da forma tekshiruvi biznes qoidasi, UI mantig'i emas.
| Mezon | Maydonni tekshirish | Formani tekshirish |
|---|---|---|
| Tekshirish ob'ekti | Bitta maydon | Barcha maydonlar + ularning o'zaro bog'liqliklari |
| Bajarish vaqti | Real vaqtda / fokus yo'qolganda | Forma yuborilganda |
| Natija | Aniq maydon xatosi | Formaning umumiy holati + xatolar ro'yxati |
| Arxitektura qatlami | UI qatlami | Domain qatlami |
Forma tekshiruviga yondashuvlar
Form Validation uchun ikkita asosiy yondashuv mavjud. Birinchisi — imperativ: dasturchi ketma-ket har bir maydonni tekshiradigan va xatolar ro'yxatini to'playdigan funksiya yozadi. Bu yondashuv tushunish uchun sodda, ammo kod har bir yangi maydon bilan o'sib boradi. 5 maydonli forma uchun imperativ yondashuv hali qulay, 15 maydon uchun — muammoli.
Ikkinchi yondashuv — deklarativ: tekshirish qoidalari annotatsiyalar yoki konfiguratsiya bilan tavsiflanadi. Kutubxona o'zi barcha maydonlarni aylanib chiqadi, qoidalarni qo'llaydi va natijani qaytaradi. Misol: emailData maydoni ustida @Email annotatsiyasi, tasdiq maydoni ustida @ConfirmPassword. Deklarativ yondashuv tekshirish kodini 3-5 marta qisqartiradi va uni o'qishli qiladi.
Uchinchi yondashuv — reaktiv RxJava yoki Kotlin Flow yordamida. Har bir maydon Observable yoki StateFlow sifatida taqdim etiladi. Forma tekshiruvi barcha maydonlarning o'zgarishlariga obuna bo'ladi va har bir o'zgarishda umumiy holatni qayta hisoblaydi. Barcha maydonlar yaroqli bo'lganda yuborish tugmasi avtomatik faol bo'ladi. Bu yondashuv reaktiv dasturlashni tushunishni talab qiladi, lekin eng silliq UXni ta'minlaydi.
Ro'yxatdan o'tish formasini tekshirish misoli
Ro'yxatdan o'tish formasini uch maydon bilan ko'rib chiqaylik: email, parol va parolni tasdiqlash. Forma tekshiruvi o'z ichiga oladi: emailni Patterns.EMAIL_ADDRESS orqali tekshirish, parolni minimal 8 belgi uzunligi va raqam mavjudligiga tekshirish, parol va tasdiqning mosligini tekshirish. Faqat uchala tekshirish ham o'tganda, formani yuborish mumkin.
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)
}Misolda, validateRegistration formaning data classini qabul qiladi va ValidationResult qaytaradi. Agar kamida bitta tekshirish o'tmasa, tegishli xabar bilan false qaytariladi. Yuborish tugmasini boshqarish Result asosida quriladi: agar isValid = true bo'lsa, tugma faol. Holatni real vaqtda yangilash uchun LiveData<ValidationResult> dan foydalanish va har qanday maydon o'zgarganda tugmani yangilash mumkin.
Kotlin Flow bilan reaktiv yondashuv formaning holatini avtomatik qayta hisoblash imkonini beradi. Har bir maydon MutableStateFlow<String> sifatida taqdim etiladi, combine esa ularni bitta Flow<ValidationResult> birlashtiradi. UI-dagi obuna yuborish tugmasini qo'lda tekshirishni chaqirmasdan yangilaydi. Ushbu naqsh Google tomonidan Jetpack Compose va MVVM arxitekturasi uchun tavsiya etiladi.
Formalarni tekshirish uchun kutubxonalar
Android Saripaar — Android uchun eng mashhur tekshirish kutubxonasi. Maydonlar va View-larni bevosita annotatsiya qilish imkonini beradi: @Email, @NotEmpty, @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). Tekshirish bir qator validator.validate() callback bilan chaqiriladi. Saripaar avtomatik ravishda EditText-da setError orqali xato o'rnatadi. Kutubxona shuningdek maxsus biznes qoidalari uchun moslashtirilgan annotatsiyalarni qo'llab-quvvatlaydi.
RxBinding + RxJava — alohida tekshirish kutubxonasisiz reaktiv yondashuv. Har bir maydon o'zgarishlarni RxTextView.textChanges() orqali nashr etadi. combineLatest operatori barcha maydonlarni birlashtiradi va umumiy holatni hisoblaydi. Afzallik: tekshirish pipeline'i ustidan to'liq nazorat, debounce, throttle, filter qo'shish imkoniyati. Kamchilik: RxJava bilimini talab qiladi.
Material Design Components — TextInputLayout va TextInputEditText uchun o'rnatilgan qo'llab-quvvatlash. Kutubxona tekshirishni o'zi ta'minlamaydi, lekin xatolarni ko'rsatish uchun UI beradi: setError(), setHelperText(), setCounterEnabled(). Tekshirishning o'zi uchun hali ham qo'lda mantiq yoki Saripaar kerak. Material Components ko'rsatish uchun javobgar, tekshirish uchun emas.
Forma tekshiruvida tipik xatolar
Birinchi xato — faqat mijoz tomonida tekshirish. Mijoz tomonida Form Validation UX uchun mo'ljallangan, xavfsizlik uchun emas. Tajovuzkor tekshirishni chetlab o'tib, so'rovni to'g'ridan-to'g'ri API-ga yuborishi mumkin. Server barcha maydonlarni qayta tekshirishi kerak. Mijoz tekshiruvi yagona himoya bo'lmasligi kerak — bu foydalanuvchi qulayligi uchun qo'shimcha qatlam, ma'lumot xavfsizligi uchun emas.
Ikkinchi xato — xabarlarsiz yuborish tugmasini bloklash. Agar tugma faol bo'lmasa, foydalanuvchi qaysi maydonlarni tuzatish kerakligini ko'rishi kerak. Izohsiz kulrang tugma — formalar past konversiyasining eng keng tarqalgan sabablaridan biri. Tugma bloklangan bo'lsa ham, har doim maydon xatolarini ularning yonida ko'rsating. Foydalanuvchi aynan nima yuborishga to'sqinlik qilayotganini tushunishi kerak.
Uchinchi xato — o'zaro maydonlarni e'tiborsiz qoldirish. Har bir maydonni alohida tekshirish etarli emas. Maydonlar bir-biriga bog'liq bo'lishi mumkin: parol va tasdiq, boshlanish va tugash sanasi, mamlakat va shahar. Form Validation bu o'zaro bog'liqliklarni tekshirishi kerak. Faqat alohida maydonlarni tekshirish soxta xavfsizlik tuyg'usini yaratadi — forma mos kelmaydigan ma'lumotlar bilan yuborilishi mumkin.
| Xato | Natija | Yechim |
|---|---|---|
| Faqat mijoz tekshiruvi | Xavfsizlik zaifligi | Majburiy server tekshiruvi |
| Xabarlarsiz tugma | Formaning past konversiyasi | Maydon xatolarini ko'rsatish |
| O'zaro tekshirishlarning yo'qligi | Mos kelmaydigan ma'lumotlar | Maydon o'zaro bog'liqliklarini tekshirish |
| Juda tez-tez tekshirishlar | Foydalanuvchining g'azablanishi | Debounce va fokus yo'qolganda tekshirish |
Tez-tez beriladigan savollar
Form Validation maydonni tekshirishdan qanday farq qiladi?
Maydonni tekshirish bitta qiymatni format yoki uzunlik jihatidan tekshiradi. Form Validation barcha maydonlarni birgalikda, shu jumladan o'zaro tekshirishlarni ham tekshiradi: parollarning mos kelishi, maydonlarning bir-biriga bog'liqligi. Maydonni tekshirish UI qatlamida, Form Validation esa domain qatlamida biznes qoidasi sifatida bajariladi.
Forma yuborish tugmasini qanday boshqarish kerak?
Reaktiv yondashuv dan foydalaning: barcha maydonlarni bitta Flow yoki Observable ga birlashtiring va o'zgarishlarga obuna bo'ling. Har qanday maydon o'zgarganda formaning umumiy holatini qayta hisoblang. Agar holat yaroqli bo'lsa — tugma faol. Avtomatik yangilash uchun Kotlin Flow bilan combine yoki RxJava bilan combineLatest dan foydalaning.
Android uchun qaysi tekshirish kutubxonasi yaxshiroq?
Android Saripaar — annotatsiyalar bilan deklarativ tekshirish uchun eng yaxshi tanlov. Loyiha RxJava dan foydalansa — RxBinding alohida kutubxonasiz reaktiv yondashuvni ta'minlaydi. Oddiy formalar uchun tashqi bog'liqliklarsiz Patterns va TextUtils bilan qo'lda tekshirish etarli.
Agar mijoz tekshiruvi mavjud bo'lsa, serverda tekshirish kerakmi?
Majburiy. Mijoz tekshiruvi UXni yaxshilaydi, ammo xavfsizlikni ta'minlamaydi. Server barcha ma'lumotlarni qayta tekshirishi kerak, chunki API to'g'ridan-to'g'ri mavjud. Noto'g'ri yoki zararli ma'lumotlardan himoyalanish uchun hech qachon faqat mijoz tekshiruviga tayanmang.
Jetpack Compose-da formani qanday tekshirish mumkin?
Jetpack Compose-da har bir maydonning holatini saqlash uchun Kotlin Flow yoki StateFlow dan foydalaning. Tekshirish funksiyasi formaning holatini qabul qiladi va ValidationResult qaytaradi. Yuborish tugmasi umumiy holatga obuna bo'ladi. Xatolarni ko'rsatish uchun OutlinedTextField yoki TextField Compose da isError dan foydalaning.
Xulosa
- Form Validation — ma'lumotlarni yuborishdan oldin forma maydonlarining barchasi va ularning o'zaro bog'liqliklarini kompleks tekshirish.
- Maydonni tekshirish izolyatsiya qilingan va UI da bajariladi; formani tekshirish o'zaro bog'liqliklarni hisobga oladi va domain qatlamiga tegishli.
- Yuborish tugmasi yaroqsiz formada faol bo'lmasligi kerak — maydon xatolarini majburiy ko'rsatish bilan.
- Android Saripaar — annotatsiyalar bilan deklarativ tekshirish uchun asosiy kutubxona.
- RxBinding/Flow — har qanday maydon o'zgarganda forma holatini avtomatik qayta hisoblash uchun reaktiv yondashuv.
- Server tekshiruvi xavfsizlik qatlami sifatida majburiy, mijoz tekshiruvi faqat UX uchun.
- O'zaro tekshirishlar — Form Validation ning majburiy elementi, ularsiz forma mos kelmaydigan ma'lumotlarni yuborishi mumkin.
Biz kalit topshirig'i bilan mobil ilovani ishlab chiqamiz
IT Sectr 2017-yildan beri startaplar va korxonalar uchun iOS va Android ilovalarini yaratadi. Biz sizga maslahat beramiz va eng yaxshi yechimni taklif qilamiz.
Shuningdek o'qing