Form Validation, verileri sunucuya göndermeden önce formdaki tüm alanların doğruluğunu kontrol etme sürecidir. Tek bir alanın doğrulanmasının aksine, Form Validation alanlar arasındaki ilişkileri dikkate alır: şifre onayı, bir alanın diğerine bağımlılığı, koşullu zorunluluk. Google Developers, 2026'ya göre, Form Validation gönderim sırasında formun tamamını kontrol etmeli ve kullanıcıya tüm hataların bir özetini sunmalıdır. Doğru form doğrulama, kayıt dönüşümünü %25-35 artırır ve giriş hatalarını azaltır.
Önemli Noktalar
Form Validation, kullanıcının bir forma girdiği tüm verilerin sunucuya gönderilmeden önce iş gereksinimlerini karşıladığını garanti eden bir süreçtir. Form doğrulama, her alanı ayrı ayrı kontrol etmenin yanı sıra çapraz kontrolleri de içerir: şifre onay ile eşleşiyor mu, en az bir onay kutusu seçilmiş mi, tüm zorunlu alanlar doldurulmuş mu, tarih doğru mu (örneğin, doğum tarihi gelecekte değil).
Basit alan doğrulamadan farkı, Form Validation'ın formu tek bir bütün olarak ele almasıdır. Koşullu bir alan doldurulmamışsa gönderimi engelleyebilir veya bir iletişim kutusunda hataların bir özetini gösterebilir. Karmaşık formlarda (kayıt, ödeme, anketler), form doğrulama, kullanıcı arayüzünden bağımsız olarak test edilen ayrı bir mantık katmanıdır.
NN Group UX araştırmasına göre, kullanıcılar her bir alandan sonra ayrı ayrı hata görmek yerine gönderimden hemen sonra hataları görürlerse bir formu 3 kat daha fazla tamamlarlar. Ancak en iyi sonuç bir kombinasyondan gelir: basit alanların (uzunluk, biçim) anında doğrulanması + çapraz alanlar ve iş mantığı için gönderimde tam kontrol.
Alan doğrulama şu soruyu yanıtlar: bu belirli alandaki giriş doğru mu? E-posta user@domain.com biçimindedir, telefon rakamlardan oluşur, şifre 6 karakterden uzundur. Alan doğrulama izole edilmiştir — diğer alanlara bağlı değildir ve gerçek zamanlı olarak gerçekleştirilebilir. Sonuç: belirli bir alan için hata veya hata yok.
Form doğrulama şu soruyu yanıtlar: form bir bütün olarak gönderilebilir mi? Yalnızca her alanı değil, aynı zamanda bunların kombinasyonlarını da dikkate alır: şifre ve onay eşleşmelidir, başlangıç tarihi bitiş tarihinden sonra olamaz, alanların toplamı %100 olmalıdır. Form doğrulama gönderim sırasında gerçekleştirilir ve genel bir sonuç döndürür: form geçerli veya geçersiz.
Mimari olarak, alan doğrulama UI katmanına (fragment, ViewModel) yerleştirilirken, form doğrulama alan katmanına (use case, interactor) yerleştirilir. Bu, form doğrulamanın farklı UI bileşenlerinde yeniden kullanılmasına ve öykünücü olmadan test edilmesine olanak tanır. Clean Architecture'da form doğrulama bir iş kuralıdır, UI mantığı değildir.
| Kriter | Alan doğrulama | Form doğrulama |
|---|---|---|
| Kontrol nesnesi | Tek alan | Tüm alanlar + ilişkileri |
| Yürütme zamanı | Gerçek zaman / odak kaybında | Form gönderiminde |
| Sonuç | Belirli alan hatası | Genel form durumu + hata listesi |
| Mimari katman | UI katmanı | Alan katmanı |
Form Validation için iki ana yaklaşım vardır. Birincisi zorunludur: geliştirici, her alanı sırayla kontrol eden ve bir hata listesi toplayan bir işlev yazar. Bu yaklaşım anlaşılması kolaydır, ancak kod her yeni alanla birlikte büyür. 5 alanlı bir form için zorunlu yaklaşım hala uygundur; 15 alan için zaten sorunludur.
İkinci yaklaşım bildirimseldir: doğrulama kuralları ek açıklamalar veya yapılandırma ile tanımlanır. Kütüphanenin kendisi tüm alanları tarar, kuralları uygular ve sonucu döndürür. Örnek: emailData alanında @Email ek açıklaması, onay alanında @ConfirmPassword. Bildirimsel yaklaşım, doğrulama kodunu 3-5 kat azaltır ve okunabilir hale getirir.
Üçüncü yaklaşım, RxJava veya Kotlin Flow kullanarak tepkiseldir. Her alan bir Observable veya StateFlow olarak temsil edilir. Form doğrulama, tüm alanlardaki değişiklikleri abone olur ve her değişiklikte genel durumu yeniden hesaplar. Tüm alanlar geçerli olduğunda gönder düğmesi otomatik olarak etkinleşir. Bu yaklaşım, tepkisel programlama anlayışı gerektirir ancak en pürüzsüz kullanıcı deneyimini sağlar.
Üç alanlı bir kayıt formu düşünelim: e-posta, şifre ve şifre onayı. Form doğrulama şunları içerir: Patterns.EMAIL_ADDRESS ile e-posta kontrolü, şifrenin minimum 8 karakter uzunluğunda ve en az bir rakam içermesi kontrolü, şifre ve onayın eşleşmesi kontrolü. Yalnızca üç kontrol de geçildiğinde form gönderilebilir.
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)
}
Örnekte, validateRegistration bir form veri sınıfı alır ve bir ValidationResult döndürür. En az bir kontrol başarısız olursa, ilgili bir mesajla false döndürür. Gönder düğmesi yönetimi Result'a dayanır: isValid = true ise düğme etkindir. Durumu gerçek zamanlı olarak güncellemek için LiveData
Kotlin Flow ile tepkisel yaklaşım, form durumunun otomatik olarak yeniden hesaplanmasını sağlar. Her alan MutableStateFlow
Android Saripaar, Android için en popüler doğrulama kütüphanesidir. Alanları ve View'ları doğrudan ek açıklama ile işaretlemeye olanak tanır: @Email, @NotEmpty, @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). Doğrulama, bir geri çağırma ile tek satırlık validator.validate() ile tetiklenir. Saripaar, EditText'te setError aracılığıyla otomatik olarak hatayı ayarlar. Kütüphane ayrıca belirli iş kuralları için özel ek açıklamaları da destekler.
RxBinding + RxJava, ayrı bir doğrulama kütüphanesi olmadan tepkisel bir yaklaşımdır. Her alan, RxTextView.textChanges() aracılığıyla değişiklikleri yayınlar. combineLatest operatörü tüm alanları birleştirir ve genel durumu hesaplar. Avantaj: doğrulama hattı üzerinde tam kontrol, debounce, throttle, filter ekleme imkanı. Dezavantaj: RxJava bilgisi gerektirir.
Material Design Components, TextInputLayout ve TextInputEditText için yerleşik destek sağlar. Kütüphane doğrulamanın kendisini sağlamaz, ancak hataları görüntülemek için bir kullanıcı arayüzü sunar: setError(), setHelperText(), setCounterEnabled(). Doğrulamanın kendisi için hala manuel mantık veya Saripaar gereklidir. Material Components görüntülemeden sorumludur, kontrolden değil.
İlk hata yalnızca istemci tarafı doğrulamadır. İstemcide Form Validation, kullanıcı deneyimi içindir, güvenlik için değil. Bir saldırgan, doğrulamayı atlayarak doğrudan API'ye istek gönderebilir. Sunucu tüm alanları yeniden kontrol etmelidir. İstemci tarafı doğrulama tek koruma olmamalıdır — bu, kullanıcı rahatlığı için ek bir katmandır, veri güvenliği için değil.
İkinci hata mesaj vermeden gönder düğmesini engellemektir. Düğme devre dışıysa, kullanıcı hangi alanların düzeltilmesi gerektiğini görmelidir. Açıklama olmadan gri bir düğme, düşük form dönüşümünün en yaygın nedenlerinden biridir. Düğme devre dışı olsa bile alan hatalarını her zaman alanların yanında gösterin. Kullanıcı, gönderimi tam olarak neyin engellediğini anlamalıdır.
Üçüncü hata çapraz alan kontrollerini görmezden gelmektir. Her alanı ayrı ayrı doğrulamak yetersizdir. Alanlar birbirine bağımlı olabilir: şifre ve onay, başlangıç tarihi ve bitiş tarihi, ülke ve şehir. Form Validation bu ilişkileri kontrol etmelidir. Yalnızca bireysel alanları kontrol etmek yanlış bir güvenlik hissi yaratır — form tutarsız verilerle gönderilebilir.
| Hata | Sonuç | Çözüm |
|---|---|---|
| Yalnızca istemci doğrulaması | Güvenlik açığı | Zorunlu sunucu tarafı kontrolü |
| Mesaj vermeyen düğme | Düşük form dönüşümü | Alan hatalarını göster |
| Çapraz kontrol yok | Tutarsız veri | Alan ilişkilerini doğrula |
| Çok sık kontroller | Kullanıcı rahatsızlığı | Debounce ve odak kaybında kontrol |
Sıkça Sorulan Sorular
Alan doğrulama, tek bir değeri biçim veya uzunluk gereksinimlerine göre kontrol eder. Form Validation, çapraz kontroller dahil olmak üzere tüm alanları birlikte kontrol eder: şifre eşleştirme, alan bağımlılıkları. Alan doğrulama UI katmanında gerçekleştirilir, Form Validation — bir iş kuralı olarak alan katmanında gerçekleştirilir.
Tepkisel bir yaklaşım kullanın: tüm alanları tek bir Flow veya Observable'da birleştirin ve değişikliklere abone olun. Herhangi bir alandaki her değişiklikte, genel form durumunu yeniden hesaplayın. Durum geçerliyse — düğme etkindir. Otomatik güncellemeler için Kotlin Flow'u combine ile veya RxJava'yı combineLatest ile kullanın.
Android Saripaar, ek açıklamalarla bildirimsel doğrulama için en iyi seçimdir. Proje RxJava kullanıyorsa — RxBinding ayrı bir kütüphane olmadan tepkisel bir yaklaşım sağlar. Basit formlar için, üçüncü taraf bağımlılıkları olmadan Patterns ve TextUtils ile manuel doğrulama yeterlidir.
Kesinlikle. İstemci tarafı doğrulama kullanıcı deneyimini iyileştirir ancak güvenlik sağlamaz. API doğrudan erişilebilir olduğundan sunucu tüm verileri yeniden doğrulamalıdır. Yanlış veya kötü niyetli verilere karşı korunmak için asla yalnızca istemci tarafı doğrulamaya güvenmeyin.
Jetpack Compose'da, her alanın durumunu depolamak için Kotlin Flow veya StateFlow kullanın. Doğrulama işlevi form durumunu alır ve bir ValidationResult döndürür. Gönder düğmesi genel duruma abone olur. Hataları görüntülemek için Compose'un OutlinedTextField veya TextField'ında isError kullanın.
Özet
Anahtar teslim bir mobil uygulama geliştireceğiz
IT Sectr, 2017'den beri girişimler ve işletmeler için iOS ve Android uygulamaları oluşturmaktadır. Size danışmanlık yapacak ve en iyi çözümü önereceğiz.
Ayrıca okuyun