Validate: wat is het, validatie van invoervelden en implementatie in Android

Wat is veldvalidatie in Android?

Veldvalidatie — is het controleren van één specifieke waarde die door de gebruiker is ingevoerd op conformiteit met vastgestelde regels. Elk veld heeft zijn eigen gegevenstype: e-mail, nummer, telefoon, wachtwoord, tekst. Voor elk type bestaan eigen criteria: formaat, lengte, waardebereik, verplichting. Veldvalidatie beantwoordt de vraag: is de invoer in dit veld correct?

Het verschil tussen veldvalidatie en formuliervalidatie is dat het veld onafhankelijk van andere velden wordt gecontroleerd. E-mail wordt gecontroleerd volgens het e-mailpatroon, telefoon — volgens het telefoonpatroon. Als een veld ongeldig is, ziet de gebruiker de fout precies voor dat veld. Het formulier kan onverzonden blijven, zelfs als één veld de controle niet heeft doorstaan. Veldvalidatie is de bouwsteen voor volledige formuliervalidatie.

Volgens UX-onderzoek verwachten gebruikers een validatiefout uiterlijk 1-2 seconden na het voltooien van de invoer te zien. Een vertraging van meer dan 3 seconden wordt ervaren als een probleem met de applicatie. Daarom heeft realtime validatie via TextWatcher de voorkeur boven alleen controleren bij het klikken op de verzendknop.

Belangrijkste methoden voor veldvalidatie

Er zijn drie hoofdbenaderingen voor veldvalidatie in Android. De eerste — handmatige controle via conditionele operatoren (if, when). De ontwikkelaar schrijft een functie die een string ontvangt en Boolean of een foutmelding retourneert. Deze benadering geeft volledige controle over de logica, maar vereist het schrijven van code voor elk veld en elke voorwaarde.

De tweede benadering — gebruik van ingebouwde Android-klassen. Bijvoorbeeld, Patterns.EMAIL_ADDRESS.matcher(email).matches() controleert e-mail volgens het standaardpatroon. Patterns.PHONE.matcher(phone).matches() — telefoonnummer. TextUtils.isEmpty() — controleert op leegte. Deze methoden dekken basisscenario's zonder externe afhankelijkheden aan te sluiten.

De derde benadering — validatiebibliotheken. Bibliotheken zoals InputValidator, AndroidValidator of Commons Validator bieden kant-en-klare annotaties en controlemogelijkheden. De ontwikkelaar beschrijft de regels declaratief: @Email, @NotEmpty, @MinLength(6). De bibliotheek voert zelf de controle uit en retourneert een lijst met fouten. Dit versnelt de ontwikkeling, maar voegt een afhankelijkheid toe.

Validatie van e-mail, telefoon en wachtwoord

Voor e-mail omvat de standaardcontrole de aanwezigheid van het @-teken, het domeingedeelte en de afwezigheid van spaties en cyrillisch schrift. Android biedt Patterns.EMAIL_ADDRESS, dat de meeste legitieme e-mailadressen dekt. Als echter een specifieke controle nodig is (bijvoorbeeld alleen bedrijfsdomeinen), moet een aangepaste reguliere expressie worden geschreven. E-mail wordt gevalideerd na het voltooien van de invoer, niet na elk teken.

Telefoonnummer wordt gecontroleerd volgens de masker van het land of de regio. Voor internationale nummers wordt de E.164-indeling gebruikt: +landcode, operatorcode, nummer. De bibliotheek libphonenumber van Google is de industriestandaard voor telefoonvalidatie. Het bepaalt het land aan de hand van de code, controleert de lengte en het formaat van het nummer. In Android kun je PhoneNumberUtils.isGlobalPhoneNumber gebruiken voor basiscontrole.

Wachtwoord heeft verschillende complexiteitscriteria: minimale lengte, aanwezigheid van hoofd- en kleine letters, cijfers, speciale tekens. In Android is er geen ingebouwde klasse voor wachtwoordcontrole — elk project bepaalt zijn eigen vereisten. Meestal wordt het wachtwoord gecontroleerd via een reguliere expressie of een reeks voorwaarden. Het is belangrijk om de exacte vereisten niet prijs te geven in de foutmelding: „Wachtwoord is te eenvoudig” is beter dan „Hoofdletter en cijfer vereist”.

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

In het voorbeeld retourneert validatePassword een ValidationResult met het veld isValid en een optionele foutmelding. Deze benadering is handig voor compositie: meerdere controles worden sequentieel uitgevoerd en de eerste gevonden fout wordt geretourneerd. E-mail- en telefoonvalidaties worden volgens hetzelfde principe gebouwd — elke retourneert een resultaat met een melding of succes.

Wanneer validatie uitvoeren?

Het moment van validatie heeft een kritieke invloed op UX. Er zijn drie strategieën: validatie na elk teken (instant), na focusverlies (onFocusLost) en bij het verzenden van het formulier (onSubmit). Elke strategie is geschikt voor verschillende scenario's. Instant-validatie is goed voor velden met strikte beperkingen — telefoonnummer, pincode. OnFocusLost — voor e-mail en naam. OnSubmit — voor verplichte velden.

Volgens de Material Design Guidelines wordt aanbevolen om strategieën te combineren: het veld moet worden gecontroleerd bij focusverlies en ook bij het verzenden van het formulier. Instant-validatie is geschikt wanneer de beperking duidelijk is — bijvoorbeeld de maximale lengte van het veld. Als voor e-mail na elk teken een fout wordt getoond, ziet de gebruiker de melding nog voordat hij klaar is met invoeren. Dit irriteert en vermindert de conversie.

De eerste fout-regel: toon bij het verzenden van het formulier alleen de fout voor het eerste ongeldige veld. Overlaad de gebruiker niet met een lijst van 10 fouten. Na het corrigeren van de eerste fout kan de volgende worden getoond. Deze stapsgewijze begeleiding vermindert de cognitieve belasting en helpt de gebruiker het formulier sneller in te vullen.

Hulpmiddelen en bibliotheken voor validatie

Android SDK biedt basishulpmiddelen voor Validate: Patterns voor e-mail en telefoon, TextUtils voor het controleren op leegte, reguliere expressies voor willekeurige patronen. Voor projecten met 1-3 velden is dit voldoende. In formulieren met 10+ velden wordt handmatige validatie echter moeilijk te onderhouden — elk nieuw veld vereist een aparte functie en het bijwerken van de verzendlogica.

Populaire validatiebibliotheken: Android Saripaar (annotaties @Email, @NotEmpty, @Password), Commons Validator van Apache (controle van e-mail, URL, creditcardnummer), RxBinding + RxJava voor reactieve validatie. Saripaar maakt het mogelijk annotaties direct op invoervelden te plaatsen en validatie met één regel aan te roepen: validator.validate(). De bibliotheek toont fouten automatisch via setError.

Google beveelt het gebruik van Material Design Components met TextInputLayout aan. Ingebouwde validatie via setError, setHelperText en setCounterEnabled dekt basisscenario's zonder externe bibliotheken. Voor complexe projecten (fintech, medisch) is het beter om een combinatie te gebruiken: Material Components + aangepaste validatie met patronen uit de domeinlaag van Clean Architecture.

Fouten bij veldvalidatie

Eerste fout — het tonen van een fout voordat met invoeren is begonnen. Als een veld verplicht is maar de gebruiker is nog niet begonnen met invullen, toon dan niet „Veld is verplicht”. Dit creëert een valse indruk van een probleem. De fout mag pas verschijnen nadat de gebruiker met het veld heeft geïnterageerd: begon met invoeren, het veld verliet, probeerde het formulier te verzenden.

Tweede fout — onduidelijke foutmelding. De melding moet concreet zijn en aangeven hoe het probleem kan worden opgelost. „Ongeldige e-mail” — slecht. „E-mail moet @ en domein bevatten, bijvoorbeeld user@example.com” — goed. De gebruiker moet begrijpen wat er precies mis is en hoe het te repareren zonder de documentatie te raadplegen.

Derde fout — het blokkeren van verzending zonder uitleg. Als de verzendknop inactief is vanwege validatiefouten, moet de gebruiker kunnen zien welke velden ongeldig zijn. Een grijze knop zonder meldingen is een doodlopende weg voor de gebruiker. Markeer altijd velden met fouten en toon de fouttekst naast elk ongeldig veld.