Validate: co to jest, walidacja pól wejściowych i implementacja w Android

Co to jest walidacja pola w Android?

Walidacja pola — to sprawdzenie jednej konkretnej wartości wprowadzonej przez użytkownika pod kątem zgodności z określonymi regułami. Każde pole ma swój typ danych: email, liczba, telefon, hasło, tekst. Dla każdego typu istnieją własne kryteria: format, długość, zakres wartości, obowiązkowość. Walidacja pola odpowiada na pytanie: czy wprowadzone dane w tym polu są poprawne?

Różnica między walidacją pola a walidacją formularza polega na tym, że pole sprawdzane jest niezależnie od innych pól. Email sprawdzany jest według wzorca email, telefon — według wzorca telefonu. Jeśli pole jest nieprawidłowe, użytkownik widzi błąd właśnie dla tego pola. Formularz może pozostać niewysłany, nawet jeśli jedno pole nie przeszło walidacji. Walidacja pola to element składowy pełnej walidacji formularza.

Według badań UX, użytkownicy oczekują zobaczenia błędu walidacji nie później niż 1-2 sekundy po zakończeniu wprowadzania. Opóźnienie powyżej 3 sekund jest odbierane jako problem z aplikacją. Dlatego walidacja przez TextWatcher w czasie rzeczywistym jest preferowana nad sprawdzaniem tylko po kliknięciu przycisku wysyłania.

Podstawowe metody walidacji pól

Istnieją trzy główne podejścia do walidacji pól w Android. Pierwsze — ręczne sprawdzanie przez instrukcje warunkowe (if, when). Deweloper pisze funkcję, która przyjmuje ciąg znaków i zwraca Boolean lub komunikat o błędzie. To podejście daje pełną kontrolę nad logiką, ale wymaga pisania kodu dla każdego pola i każdego warunku.

Drugie podejście — używanie wbudowanych klas Android. Na przykład Patterns.EMAIL_ADDRESS.matcher(email).matches() sprawdza email według standardowego wzorca. Patterns.PHONE.matcher(phone).matches() — numer telefonu. TextUtils.isEmpty() — sprawdza pustość. Te metody pokrywają podstawowe scenariusze bez podłączania zewnętrznych zależności.

Trzecie podejście — biblioteki walidacji. Biblioteki takie jak InputValidator, AndroidValidator czy Commons Validator dostarczają gotowych adnotacji i łańcuchów sprawdzeń. Deweloper opisuje reguły deklaratywnie: @Email, @NotEmpty, @MinLength(6). Biblioteka sama wykonuje sprawdzenie i zwraca listę błędów. To przyspiesza rozwój, ale dodaje zależność.

Walidacja email, telefonu i hasła

Dla email standardowe sprawdzenie obejmuje obecność znaku @, domeny i brak spacji oraz cyrylicy. Android udostępnia Patterns.EMAIL_ADDRESS, który pokrywa większość legalnych adresów email. Jeśli jednak wymagane jest specyficzne sprawdzenie (np. tylko domeny korporacyjne), trzeba napisać niestandardowe wyrażenie regularne. Email waliduje się po zakończeniu wprowadzania, a nie po każdym znaku.

Numer telefonu sprawdzany jest według maski kraju lub regionu. Dla numerów międzynarodowych używany jest format E.164: +kod kraju, kod operatora, numer. Biblioteka libphonenumber od Google to standard branżowy do walidacji telefonów. Określa kraj po kodzie, sprawdza długość i format numeru. W Android można użyć PhoneNumberUtils.isGlobalPhoneNumber do podstawowego sprawdzenia.

Hasło ma kilka kryteriów złożoności: minimalna długość, obecność wielkich i małych liter, cyfr, znaków specjalnych. W Android nie ma wbudowanej klasy do sprawdzania hasła — każdy projekt określa własne wymagania. Zazwyczaj hasło sprawdzane jest przez wyrażenie regularne lub zestaw warunków. Ważne, aby nie ujawniać dokładnych wymagań w komunikacie o błędzie: „Hasło jest zbyt proste" jest lepsze niż „Wymagana wielka litera i cyfra".

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

W przykładzie validatePassword zwraca ValidationResult z polem isValid i opcjonalnym komunikatem o błędzie. Takie podejście jest wygodne do kompozycji: kilka sprawdzeń wykonywanych jest sekwencyjnie i zwracany jest pierwszy znaleziony błąd. Walidacje email i telefonu budowane są według tej samej zasady — każda zwraca wynik z komunikatem lub sukcesem.

Kiedy wykonywać walidację?

Moment walidacji krytycznie wpływa na UX. Istnieją trzy strategie: walidacja po wprowadzeniu każdego znaku (instant), po utracie fokusu (onFocusLost) i przy wysyłaniu formularza (onSubmit). Każda strategia jest odpowiednia dla różnych scenariuszy. Instant-walidacja jest dobra dla pól z ścisłymi ograniczeniami — numer telefonu, kod PIN. OnFocusLost — dla email i nazwy. OnSubmit — dla pól obowiązkowych.

Według Material Design Guidelines, zaleca się łączenie strategii: pole powinno być sprawdzane przy utracie fokusu, a także przy wysyłaniu formularza. Instant-walidacja jest odpowiednia, gdy ograniczenie jest oczywiste — na przykład maksymalna długość pola. Jeśli pokazywać błąd po każdym znaku dla email, użytkownik zobaczy komunikat, jeszcze nie kończąc wprowadzania. To denerwuje i obniża konwersję.

Zasada pierwszego błędu: przy wysyłaniu formularza pokazuj błąd tylko dla pierwszego nieprawidłowego pola. Nie zasypuj użytkownika listą 10 błędów. Po poprawieniu pierwszego błędu można pokazać następny. To prowadzenie krok po kroku zmniejsza obciążenie poznawcze i pomaga użytkownikowi szybciej wypełnić formularz.

Narzędzia i biblioteki do walidacji

Android SDK udostępnia podstawowe narzędzia do Validate: Patterns dla email i telefonu, TextUtils do sprawdzania pustości, wyrażenia regularne dla dowolnych wzorców. Dla projektów z 1-3 polami to wystarczy. Jednak w formularzach z 10+ polami ręczna walidacja staje się trudna do utrzymania — każde nowe pole wymaga osobnej funkcji i aktualizacji logiki wysyłania.

Popularne biblioteki walidacji: Android Saripaar (adnotacje @Email, @NotEmpty, @Password), Commons Validator od Apache (sprawdzanie email, URL, numeru karty kredytowej), RxBinding + RxJava do reaktywnej walidacji. Saripaar pozwala zawiesić adnotacje bezpośrednio na polach wejściowych i wywołać walidację jedną linią: validator.validate(). Biblioteka automatycznie pokazuje błędy przez setError.

Google zaleca używanie Material Design Components z TextInputLayout. Wbudowana walidacja przez setError, setHelperText i setCounterEnabled pokrywa podstawowe scenariusze bez zewnętrznych bibliotek. Dla złożonych projektów (fintech, medycyna) lepiej użyć kombinacji: Material Components + niestandardowa walidacja z wzorcami z warstwy domenowej Clean Architecture.

Błędy przy walidacji pól

Pierwszy błąd — pokazywanie błędu przed rozpoczęciem wprowadzania. Jeśli pole jest obowiązkowe, ale użytkownik jeszcze nie zaczął go wypełniać, nie pokazuj „Pole jest obowiązkowe". To stwarza fałszywe wrażenie problemu. Błąd powinien pojawiać się dopiero po tym, jak użytkownik wchodził w interakcję z polem: zaczął wprowadzać, wyszedł z pola, próbował wysłać formularz.

Drugi błąd — niezrozumiały komunikat o błędzie. Komunikat powinien być konkretny i podpowiadać, jak naprawić problem. „Nieprawidłowy email" — źle. „Email musi zawierać @ i domenę, np. user@example.com" — dobrze. Użytkownik powinien zrozumieć, co dokładnie jest nie tak i jak to naprawić, bez sięgania do dokumentacji.

Trzeci błąd — blokowanie wysyłania bez wyjaśnienia. Jeśli przycisk wysyłania jest nieaktywny z powodu błędów walidacji, użytkownik powinien widzieć, które pola są nieprawidłowe. Szary przycisk bez komunikatów to ślepa uliczka dla użytkownika. Zawsze podświetlaj pola z błędami i pokazuj tekst błędu obok każdego nieprawidłowego pola.