Validate: vad är det, validering av inmatningsfält och implementering i Android

Vad är fältvalidering i Android?

Fältvalidering — är kontroll av ett specifikt värde som användaren har angett för överensstämmelse med fastställda regler. Varje fält har sin egen datatyp: e-post, nummer, telefon, lösenord, text. För varje typ finns egna kriterier: format, längd, värdeintervall, obligatorisk. Fältvalidering svarar på frågan: är inmatningen i detta fält korrekt?

Skillnaden mellan fältvalidering och formulärvalidering är att fältet kontrolleras oberoende av andra fält. E-post kontrolleras enligt e-postmönstret, telefon — enligt telefonmönstret. Om ett fält är ogiltigt ser användaren felet just för det fältet. Formuläret kan förbli oinskickat även om ett fält inte klarar kontrollen. Fältvalidering är byggstenen för fullständig formulärvalidering.

Enligt UX-forskning förväntar sig användare att se ett valideringsfel senast 1-2 sekunder efter att inmatningen är klar. En fördröjning på mer än 3 sekunder uppfattas som ett problem med applikationen. Därför är realtidsvalidering via TextWatcher att föredra framför kontroll endast vid knapptryckning för inskickning.

Huvudmetoder för fältvalidering

Det finns tre huvudsakliga angreppssätt för fältvalidering i Android. Första — manuell kontroll via villkorsoperatorer (if, when). Utvecklaren skriver en funktion som tar emot en sträng och returnerar Boolean eller ett felmeddelande. Detta angreppssätt ger full kontroll över logiken, men kräver att kod skrivs för varje fält och varje villkor.

Andra angreppssättet — användning av inbyggda Android-klasser. Till exempel kontrollerar Patterns.EMAIL_ADDRESS.matcher(email).matches() e-post enligt standardmönstret. Patterns.PHONE.matcher(phone).matches() — telefonnummer. TextUtils.isEmpty() — kontrollerar om det är tomt. Dessa metoder täcker grundläggande scenarier utan att ansluta externa beroenden.

Tredje angreppssättet — valideringsbibliotek. Bibliotek som InputValidator, AndroidValidator eller Commons Validator tillhandahåller färdiga annoteringar och kontrollkedjor. Utvecklaren beskriver reglerna deklarativt: @Email, @NotEmpty, @MinLength(6). Biblioteket utför själv kontrollen och returnerar en lista med fel. Detta påskyndar utvecklingen, men lägger till ett beroende.

Validering av e-post, telefon och lösenord

För e-post omfattar standardkontrollen förekomst av @-tecknet, domändelen och frånvaro av mellanslag och kyrilliska tecken. Android tillhandahåller Patterns.EMAIL_ADDRESS som täcker de flesta legitima e-postadresser. Om specifik kontroll dock krävs (till exempel endast företagsdomäner) måste ett anpassat reguljärt uttryck skrivas. E-post valideras efter att inmatningen är klar, inte efter varje tecken.

Telefonnummer kontrolleras enligt landets eller regionens mask. För internationella nummer används formatet E.164: +landskod, operatörskod, nummer. Biblioteket libphonenumber från Google är branschstandarden för telefonvalidering. Den bestämmer landet baserat på koden, kontrollerar numrets längd och format. I Android kan du använda PhoneNumberUtils.isGlobalPhoneNumber för grundläggande kontroll.

Lösenord har flera komplexitetskriterier: minsta längd, förekomst av stora och små bokstäver, siffror, specialtecken. I Android finns ingen inbyggd klass för lösenordskontroll — varje projekt bestämmer sina egna krav. Vanligtvis kontrolleras lösenordet via ett reguljärt uttryck eller en uppsättning villkor. Det är viktigt att inte avslöja de exakta kraven i felmeddelandet: „Lösenordet är för enkelt" är bättre än „Stor bokstav och siffra krävs".

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

I exemplet returnerar validatePassword ett ValidationResult med fältet isValid och ett valfritt felmeddelande. Detta angreppssätt är bekvämt för komposition: flera kontroller utförs sekventiellt och det första funna felet returneras. E-post- och telefonvalideringar byggs enligt samma princip — var och en returnerar ett resultat med ett meddelande eller framgång.

När ska validering utföras?

Valideringstillfället påverkar UX kritiskt. Det finns tre strategier: validering efter varje tecken (instant), efter fokusförlust (onFocusLost) och vid inskickning av formuläret (onSubmit). Varje strategi passar olika scenarier. Omedelbar validering är bra för fält med strikta begränsningar — telefonnummer, PIN-kod. OnFocusLost — för e-post och namn. OnSubmit — för obligatoriska fält.

Enligt Material Design Guidelines rekommenderas att kombinera strategier: fältet bör kontrolleras vid fokusförlust, samt vid inskickning av formuläret. Omedelbar validering är lämplig när begränsningen är uppenbar — till exempel fältets maximala längd. Om fel visas efter varje tecken för e-post kommer användaren att se meddelandet innan inmatningen är klar. Detta irriterar och minskar konverteringen.

Regeln om första felet: vid inskickning av formuläret, visa felet endast för det första ogiltiga fältet. Överväldiga inte användaren med en lista på 10 fel. Efter att det första felet har korrigerats kan nästa visas. Denna steg-för-steg-vägledning minskar den kognitiva belastningen och hjälper användaren att fylla i formuläret snabbare.

Verktyg och bibliotek för validering

Android SDK tillhandahåller grundläggande verktyg för Validate: Patterns för e-post och telefon, TextUtils för att kontrollera om det är tomt, reguljära uttryck för godtyckliga mönster. För projekt med 1-3 fält är detta tillräckligt. I formulär med 10+ fält blir dock manuell validering svår att underhålla — varje nytt fält kräver en separat funktion och uppdatering av inskickningslogiken.

Populära valideringsbibliotek: Android Saripaar (annoteringar @Email, @NotEmpty, @Password), Commons Validator från Apache (kontroll av e-post, URL, kreditkortsnummer), RxBinding + RxJava för reaktiv validering. Saripaar gör det möjligt att placera annoteringar direkt på inmatningsfält och anropa validering med en rad: validator.validate(). Biblioteket visar automatiskt fel via setError.

Google rekommenderar att använda Material Design Components med TextInputLayout. Inbyggd validering via setError, setHelperText och setCounterEnabled täcker grundläggande scenarier utan externa bibliotek. För komplexa projekt (fintech, medicin) är det bättre att använda en kombination: Material Components + anpassad validering med mönster från domänlagret i Clean Architecture.

Vanliga fel vid fältvalidering

Första felet — visa fel innan inmatning påbörjas. Om ett fält är obligatoriskt men användaren inte har börjat fylla i det, visa inte „Fältet är obligatoriskt". Detta skapar en falsk känsla av problem. Felet bör visas först efter att användaren har interagerat med fältet: börjat mata in, lämnat fältet, försökt skicka formuläret.

Andra felet — otydligt felmeddelande. Meddelandet måste vara specifikt och föreslå hur problemet kan åtgärdas. „Ogiltig e-post" — dåligt. „E-post måste innehålla @ och domän, till exempel user@example.com" — bra. Användaren måste förstå vad som är fel och hur det åtgärdas utan att konsultera dokumentationen.

Tredje felet — blockera inskickning utan förklaring. Om inskickningsknappen är inaktiv på grund av valideringsfel måste användaren kunna se vilka fält som är ogiltiga. En grå knapp utan meddelanden är en återvändsgränd för användaren. Markera alltid fält med fel och visa feltexten bredvid varje ogiltigt fält.