Form Validation är processen att kontrollera alla formulärfälts korrekthet innan data skickas till servern. Till skillnad från validering av ett enskilt fält tar Form Validation hänsyn till samband mellan fält: lösenordsbekräftelse, ett fälts beroende av ett annat, villkorlig obligatoriskhet. Enligt data från Google Developers, 2026 ska Form Validation kontrollera hela formuläret vid skickning och ge användaren en sammanfattning av alla fel. Korrekt formulärvalidering ökar registreringskonverteringen med 25-35% och minskar antalet inmatningsfel.
Huvudpunkter
Form Validation är en process som garanterar att all data som användaren matar in i formuläret uppfyller affärskraven innan de skickas till servern. Formulärvalidering omfattar kontroll av varje fält individuellt, samt korskontroller: matchar lösenordet bekräftelsen, är minst en kryssruta markerad, är alla obligatoriska fält ifyllda, är datumet korrekt (t.ex. födelsedatum inte i framtiden).
Skillnaden från enkel fältvalidering är att Form Validation behandlar formuläret som en helhet. Den kan blockera skickning om ett villkorligt fält inte är ifyllt, eller visa en sammanfattning av fel i en dialogruta. I komplexa formulär (registrering, beställning, enkät) är formulärvalidering ett separat logiklager som testas oberoende av UI:t.
Enligt UX-forskning från NN Group slutför användare ifyllning av formulär 3 gånger oftare om de ser fel direkt efter skickning, istället för efter varje fält individuellt. Bäst resultat ger dock en kombination: omedelbar validering av enkla fält (längd, format) + fullständig kontroll vid skickning för korsfält och affärslogik.
Fältvalidering svarar på frågan: är inmatningen i detta specifika fält korrekt? E-post har formatet user@domain.com, telefon består av siffror, lösenord är längre än 6 tecken. Fältvalidering är isolerad — den är oberoende av andra fält och kan utföras i realtid. Resultat: fel för ett specifikt fält eller frånvaro av fel.
Formulärvalidering svarar på frågan: kan formuläret skickas i sin helhet? Den tar inte bara hänsyn till varje fält utan även till deras kombinationer: lösenord och bekräftelse måste matcha, startdatum kan inte vara senare än slutdatum, summan av fält måste vara 100%. Formulärvalidering utförs vid skickning och returnerar ett allmänt resultat: formuläret är giltigt eller inte.
Arkitekturmässigt placeras fältvalidering i UI-lagret (fragment, ViewModel) och formulärvalidering i domänlagret (use case, interactor). Detta möjliggör återanvändning av formulärvalidering i olika UI-komponenter och testning utan emulator. I Clean Architecture är formulärvalidering en affärsregel, inte UI-logik.
| Kriterium | Fältvalidering | Formulärvalidering |
|---|---|---|
| Kontrollobjekt | Ett fält | Alla fält + deras samband |
| Utförandetid | I realtid / vid fokusförlust | Vid formulärskickning |
| Resultat | Fel för specifikt fält | Allmän formulärstatus + fellista |
| Arkitekturlager | UI-lager | Domänlager |
Det finns två huvudmetoder för Form Validation. Den första — imperativ: utvecklaren skriver en funktion som sekventiellt kontrollerar varje fält och samlar en lista med fel. Denna metod är enkel att förstå, men koden växer med varje nytt fält. För ett formulär med 5 fält är den imperativa metoden fortfarande bekväm, för 15 fält — redan problematisk.
Den andra metoden — deklarativ: valideringsregler beskrivs med annotationer eller konfiguration. Biblioteket går själv igenom alla fält, tillämpar regler och returnerar resultatet. Exempel: @Email-annotation över fältet emailData, @ConfirmPassword över bekräftelsefältet. Deklarativ metod förkortar valideringskoden 3-5 gånger och gör den läsbar.
Den tredje metoden — reaktiv med RxJava eller Kotlin Flow. Varje fält representeras som Observable eller StateFlow. Formulärvalidering prenumererar på ändringar av alla fält och räknar om det allmänna tillståndet vid varje ändring. Skickaknappen blir automatiskt aktiv när alla fält är giltiga. Denna metod kräver förståelse för reaktiv programmering, men ger den mest flytande UX.
Betrakta ett registreringsformulär med tre fält: e-post, lösenord och lösenordsbekräftelse. Formulärvalidering omfattar: kontroll av e-post via Patterns.EMAIL_ADDRESS, kontroll av lösenord för minsta längd 8 tecken och förekomst av siffra, kontroll av matchning mellan lösenord och bekräftelse. Först när alla tre kontroller passerar kan formuläret skickas.
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)
}
I exemplet tar validateRegistration emot formulärets data class och returnerar ValidationResult. Om minst en kontroll misslyckas returneras false med ett motsvarande meddelande. Hanteringen av skickaknappen baseras på Result: om isValid = true är knappen aktiv. För realtidsuppdatering av tillståndet kan LiveData<ValidationResult> användas och knappen uppdateras vid varje ändring av något fält.
Reaktiv metod med Kotlin Flow möjliggör automatisk omräkning av formulärtillståndet. Varje fält representeras som MutableStateFlow<String>, och combine sammanfogar dem till en Flow<ValidationResult>. Prenumeration i UI:t uppdaterar skickaknappen utan manuellt valideringsanrop. Detta mönster rekommenderas av Google för Jetpack Compose och MVVM-arkitektur.
Android Saripaar — det populäraste valideringsbiblioteket för Android. Möjliggör direkt annotation av fält och vyer: @Email, @NotEmpty, @Password(min = 8, scheme = Password.Scheme.ALPHA_NUMERIC). Validering anropas med en rad validator.validate() med callback. Saripaar ställer automatiskt in felet via setError på EditText. Biblioteket stöder även anpassade annotationer för specifika affärsregler.
RxBinding + RxJava — reaktiv metod utan separat valideringsbibliotek. Varje fält publicerar ändringar via RxTextView.textChanges(). Operatorn combineLatest kombinerar alla fält och beräknar den allmänna statusen. Fördel: full kontroll över valideringspipelinen, möjlighet att lägga till debounce, throttle, filter. Nackdel: kräver kunskap om RxJava.
Material Design Components — inbyggt stöd för TextInputLayout och TextInputEditText. Biblioteket tillhandahåller inte validering i sig, men ger UI för att visa fel: setError(), setHelperText(), setCounterEnabled(). För själva valideringen krävs fortfarande manuell logik eller Saripaar. Material Components ansvarar för visning, inte för kontroll.
Första misstaget — endast validering på klientsidan. Form Validation på klientsidan är avsedd för UX, inte för säkerhet. En angripare kan skicka en begäran direkt till API:t och kringgå valideringen. Servern måste kontrollera alla fält igen. Klientvalidering bör inte vara det enda skyddet — det är ett extra lager för användarens bekvämlighet, inte för datasäkerhet.
Andra misstaget — blockera skickaknappen utan meddelanden. Om knappen är inaktiv måste användaren se vilka fält som behöver korrigeras. Grå knapp utan förklaring — en av de vanligaste orsakerna till låg formulärkonvertering. Visa alltid fältfel bredvid dem, även om knappen är blockerad. Användaren måste förstå vad som hindrar skickningen.
Tredje misstaget — ignorera korsfält. Validering av varje fält individuellt är otillräcklig. Fält kan vara beroende av varandra: lösenord och bekräftelse, startdatum och slutdatum, land och stad. Form Validation måste kontrollera dessa samband. Endast kontroll av enskilda fält skapar en falsk känsla av säkerhet — formuläret kan skickas med inkonsekventa data.
| Misstag | Konsekvens | Lösning |
|---|---|---|
| Endast klientvalidering | Säkerhetsrisk | Obligatorisk serverkontroll |
| Knapp utan meddelanden | Låg formulärkonvertering | Visa fältfel |
| Inga korskontroller | Inkonsekventa data | Validering av fältsamband |
| För frekventa kontroller | Irritation hos användaren | Debounce och kontroll vid fokusförlust |
Vanliga frågor
Fältvalidering kontrollerar ett enskilt värde baserat på format eller längd. Form Validation kontrollerar alla fält tillsammans, inklusive korskontroller: lösenordsmatchning, fälts beroende av varandra. Fältvalidering utförs i UI-lagret, Form Validation — i domänlagret som en affärsregel.
Använd reaktiv metod: kombinera alla fält i en Flow eller Observable och prenumerera på ändringar. Vid varje ändring av något fält, räkna om formulärets allmänna status. Om statusen är giltig — är knappen aktiv. Använd Kotlin Flow med combine eller RxJava med combineLatest för automatisk uppdatering.
Android Saripaar — bästa valet för deklarativ validering med annotationer. Om projektet använder RxJava — ger RxBinding reaktiv metod utan separat bibliotek. För enkla formulär räcker manuell validering med Patterns och TextUtils utan externa beroenden.
Obligatoriskt. Klientvalidering förbättrar UX men ger inte säkerhet. Servern måste kontrollera all data igen eftersom API:t är direkt tillgängligt. Lita aldrig endast på klientvalidering för skydd mot felaktig eller skadlig data.
I Jetpack Compose, använd Kotlin Flow eller StateFlow för att lagra tillståndet för varje fält. Valideringsfunktionen tar emot formulärtillståndet och returnerar ValidationResult. Skickaknappen prenumererar på den allmänna statusen. För att visa fel, använd isError i OutlinedTextField eller TextField Compose.
Sammanfattning
Vi utvecklar en mobil applikation nyckelfärdigt
IT Sectr skapar iOS- och Android-applikationer för startups och företag sedan 2017. Vi ger dig råd och föreslår den bästa lösningen.
Läs också