Validate: nedir, giriş alanı doğrulama ve Android'de uygulama

Android'de alan doğrulama nedir?

Alan doğrulama, belirtilen kurallara göre kullanıcının girdiği tek bir değerin kontrol edilmesidir. Her alanın kendi veri türü vardır: e-posta, sayı, telefon, şifre, metin. Her türün kendi kriterleri vardır: biçim, uzunluk, değer aralığı, zorunluluk. Alan doğrulama şu soruyu yanıtlar: Bu alandaki giriş doğru mu?

Alan doğrulama ile form doğrulama arasındaki fark, bir alanın diğer alanlardan bağımsız olarak kontrol edilmesidir. E-posta bir e-posta desenine göre, telefon bir telefon desenine göre doğrulanır. Bir alan geçersizse, kullanıcı o belirli alan için bir hata görür. Bir alan doğrulamayı geçemese bile form gönderilmemiş halde kalabilir. Alan doğrulama, tam form doğrulamasının yapı taşıdır.

UX araştırmalarına göre, kullanıcılar girişi tamamladıktan en geç 1-2 saniye sonra bir doğrulama hatası görmeyi bekler. 3 saniyeden fazla gecikme, uygulama sorunu olarak algılanır. Bu nedenle TextWatcher aracılığıyla gerçek zamanlı doğrulama, yalnızca gönder düğmesine basıldığında kontrol etmekten daha tercih edilir.

Alan doğrulamanın temel yöntemleri

Android'de alan doğrulama için üç ana yaklaşım vardır. Birincisi, koşullu operatörler (if, when) aracılığıyla manuel kontroldür. Geliştirici, bir dize alan ve Boolean veya hata mesajı döndüren bir işlev yazar. Bu yaklaşım, mantık üzerinde tam kontrol sağlar ancak her alan ve her koşul için kod yazılmasını gerektirir.

İkinci yaklaşım, Android'in yerleşik sınıflarını kullanmaktır. Örneğin, Patterns.EMAIL_ADDRESS.matcher(email).matches() bir e-postayı standart bir desene göre doğrular. Patterns.PHONE.matcher(phone).matches() bir telefon numarasını doğrular. TextUtils.isEmpty() boş olup olmadığını kontrol eder. Bu yöntemler, harici bağımlılıklar eklemeden temel senaryoları kapsar.

Üçüncü yaklaşım, doğrulama kütüphaneleridir. InputValidator, AndroidValidator veya Commons Validator gibi kütüphaneler, hazır ek açıklamalar ve doğrulama zincirleri sağlar. Geliştirici kuralları bildirimsel olarak tanımlar: @Email, @NotEmpty, @MinLength(6). Kütüphane doğrulamayı kendisi gerçekleştirir ve bir hata listesi döndürür. Bu, geliştirmeyi hızlandırır ancak bir bağımlılık ekler.

E-posta, telefon ve şifre doğrulama

E-posta için standart doğrulama, @ sembolünün, alan adı kısmının varlığını ve boşluk ile Kiril karakterlerinin olmamasını kontrol etmeyi içerir. Android, çoğu meşru e-posta adresini kapsayan Patterns.EMAIL_ADDRESS sağlar. Ancak belirli bir doğrulama gerekiyorsa (örneğin, yalnızca kurumsal alan adları), özel bir düzenli ifade yazılmalıdır. E-posta, her karakterden sonra değil, giriş tamamlandıktan sonra doğrulanır.

Telefon numarası bir ülke veya bölge maskesine göre doğrulanır. Uluslararası numaralar için E.164 biçimi kullanılır: +ülke kodu, operatör kodu, numara. Google'ın libphonenumber kütüphanesi, telefon doğrulama için endüstri standardıdır. Koda göre ülkeyi belirler, numaranın uzunluğunu ve biçimini kontrol eder. Android'de, temel doğrulama için PhoneNumberUtils.isGlobalPhoneNumber kullanılabilir.

Şifre için birden çok karmaşıklık kriteri vardır: minimum uzunluk, büyük ve küçük harflerin, rakamların, özel karakterlerin varlığı. Android'de şifre doğrulama için yerleşik bir sınıf yoktur — her proje kendi gereksinimlerini tanımlar. Tipik olarak, bir şifre düzenli ifade veya bir dizi koşul aracılığıyla doğrulanır. Hata mesajında kesin gereksinimleri açıklamamak önemlidir: “Şifre çok basit”, “Büyük harf ve rakam gereklidir” ifadesinden daha iyidir.

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)
}

Örnekte, validatePassword bir isValid alanı ve isteğe bağlı bir hata mesajı ile ValidationResult döndürür. Bu yaklaşım, kompozisyon için uygundur: birden çok kontrol sırayla gerçekleştirilir ve bulunan ilk hata döndürülür. E-posta ve telefon doğrulaması aynı prensibi izler — her biri bir mesaj veya başarı ile bir sonuç döndürür.

Doğrulama ne zaman yapılmalı?

Doğrulama zamanlaması UX'i kritik şekilde etkiler. Üç strateji vardır: her karakterden sonra doğrulama (anlık), odak kaybından sonra (onFocusLost) ve form gönderiminde (onSubmit). Her strateji farklı senaryolar için uygundur. Anlık doğrulama, katı kısıtlamaları olan alanlar için iyidir — telefon numarası, PIN kodu. OnFocusLost e-posta ve ad için uygundur. OnSubmit zorunlu alanlar için uygundur.

Material Design Guidelines'a göre, stratejilerin birleştirilmesi önerilir: bir alan odak kaybında ve form gönderiminde doğrulanmalıdır. Anlık doğrulama, kısıtlama belirgin olduğunda uygundur — örneğin, maksimum alan uzunluğu. E-posta için her karakterden sonra bir hata gösterilirse, kullanıcı girişi bitirmeden bir mesaj görecektir. Bu rahatsız edicidir ve dönüşümü düşürür.

İlk hata kuralı: bir form gönderilirken, yalnızca ilk geçersiz alan için hata gösterin. Kullanıcıyı 10 hatalık bir liste ile boğmayın. İlk hata düzeltildikten sonra, bir sonraki hata gösterilebilir. Bu adım adım rehberlik, bilişsel yükü azaltır ve kullanıcının formu daha hızlı doldurmasına yardımcı olur.

Doğrulama için araçlar ve kütüphaneler

Android SDK, Validate için temel araçlar sağlar: e-posta ve telefon için Patterns, boşluk kontrolü için TextUtils, isteğe bağlı desenler için düzenli ifadeler. 1-3 alanlı projeler için bu yeterlidir. Ancak 10+ alanlı formlarda, manuel doğrulama bakımı zorlaşır — her yeni alan ayrı bir işlev ve güncellenmiş gönderme mantığı gerektirir.

Popüler doğrulama kütüphaneleri: Android Saripaar (@Email, @NotEmpty, @Password ek açıklamaları), Apache Commons Validator (e-posta, URL, kredi kartı numarası doğrulama), reaktif doğrulama için RxBinding + RxJava. Saripaar, doğrudan giriş alanlarına ek açıklamalar koymanıza ve doğrulamayı tek satırda çağırmanıza olanak tanır: validator.validate(). Kütüphane, setError aracılığıyla otomatik olarak hataları gösterir.

Google, TextInputLayout ile Material Design Components kullanılmasını önerir. setError, setHelperText ve setCounterEnabled aracılığıyla yerleşik doğrulama, üçüncü taraf kütüphaneler olmadan temel senaryoları kapsar. Karmaşık projeler (fintech, sağlık) için bir kombinasyon kullanmak daha iyidir: Material Components + Clean Architecture'ın domain katmanından desenlerle özel doğrulama.

Alan doğrulamada yaygın hatalar

İlk hata, giriş başlamadan önce hata göstermektir. Bir alan zorunluysa ancak kullanıcı doldurmaya başlamadıysa, “Alan zorunludur” göstermeyin. Bu, yanlış bir sorun algısı yaratır. Bir hata yalnızca kullanıcı alanla etkileşime girdikten sonra görünmelidir: yazmaya başladı, alandan çıktı, formu göndermeye çalıştı.

İkinci hata, net olmayan bir hata mesajıdır. Mesaj belirli olmalı ve sorunun nasıl çözüleceğini önermelidir. “Geçersiz e-posta” kötüdür. “E-posta @ ve bir alan adı içermelidir, örneğin user@example.com” iyidir. Kullanıcı, belgelere başvurmadan tam olarak neyin yanlış olduğunu ve nasıl düzelteceğini anlamalıdır.

Üçüncü hata, açıklama yapmadan gönderimi engellemektir. Doğrulama hataları nedeniyle gönder düğmesi etkin değilse, kullanıcı hangi alanların geçersiz olduğunu görebilmelidir. Mesajsız gri bir düğme, kullanıcı için bir çıkmaz sokaktır. Her zaman hatalı alanları vurgulayın ve her geçersiz alanın yanında hata metnini gösterin.