Validate: Was es ist, Eingabefeldvalidierung und Implementierung in Android

Was ist Feldvalidierung in Android?

Feldvalidierung ist die Überprüfung eines einzelnen vom Benutzer eingegebenen Werts gemäß den festgelegten Regeln. Jedes Feld hat seinen eigenen Datentyp: E-Mail, Nummer, Telefon, Passwort, Text. Jeder Typ hat seine eigenen Kriterien: Format, Länge, Wertebereich, Pflichtfeld. Die Feldvalidierung beantwortet die Frage: Ist die Eingabe in diesem Feld korrekt?

Der Unterschied zwischen Feldvalidierung und Formularvalidierung besteht darin, dass ein Feld unabhängig von anderen Feldern geprüft wird. E-Mail wird gegen ein E-Mail-Muster validiert, Telefon gegen ein Telefonmuster. Wenn ein Feld ungültig ist, sieht der Benutzer einen Fehler für dieses spezifische Feld. Das Formular kann ungesendet bleiben, selbst wenn ein Feld die Validierung nicht besteht. Die Feldvalidierung ist der Baustein für die vollständige Formularvalidierung.

Laut UX-Forschung erwarten Benutzer, einen Validierungsfehler spätestens 1-2 Sekunden nach Abschluss der Eingabe zu sehen. Eine Verzögerung von mehr als 3 Sekunden wird als Anwendungsproblem wahrgenommen. Deshalb ist die Echtzeit-Validierung über TextWatcher der Überprüfung nur beim Drücken der Senden-Schaltfläche vorzuziehen.

Wichtigste Methoden der Feldvalidierung

Es gibt drei Hauptansätze für die Feldvalidierung in Android. Der erste ist die manuelle Überprüfung durch bedingte Operatoren (if, when). Der Entwickler schreibt eine Funktion, die einen String entgegennimmt und einen Boolean oder eine Fehlermeldung zurückgibt. Dieser Ansatz gibt volle Kontrolle über die Logik, erfordert aber das Schreiben von Code für jedes Feld und jede Bedingung.

Der zweite Ansatz ist die Verwendung integrierter Android-Klassen. Beispielsweise validiert Patterns.EMAIL_ADDRESS.matcher(email).matches() eine E-Mail gegen ein Standardmuster. Patterns.PHONE.matcher(phone).matches() validiert eine Telefonnummer. TextUtils.isEmpty() prüft auf Leerheit. Diese Methoden decken grundlegende Szenarien ab, ohne externe Abhängigkeiten hinzuzufügen.

Der dritte Ansatz sind Validierungsbibliotheken. Bibliotheken wie InputValidator, AndroidValidator oder Commons Validator bieten vorgefertigte Annotationen und Validierungsketten. Der Entwickler beschreibt Regeln deklarativ: @Email, @NotEmpty, @MinLength(6). Die Bibliothek selbst führt die Validierung durch und gibt eine Liste von Fehlern zurück. Dies beschleunigt die Entwicklung, fügt aber eine Abhängigkeit hinzu.

Validierung von E-Mail, Telefon und Passwort

Für E-Mail umfasst die Standardvalidierung die Prüfung auf das @-Symbol, einen Domainteil und das Fehlen von Leerzeichen und kyrillischen Zeichen. Android stellt Patterns.EMAIL_ADDRESS zur Verfügung, das die meisten legitimen E-Mail-Adressen abdeckt. Wenn jedoch eine spezifische Validierung erforderlich ist (z. B. nur Unternehmensdomänen), muss ein benutzerdefinierter regulärer Ausdruck geschrieben werden. Die E-Mail wird nach Abschluss der Eingabe validiert, nicht nach jedem Zeichen.

Die Telefonnummer wird gegen eine Länder- oder Regionsmaske validiert. Für internationale Nummern wird das Format E.164 verwendet: +Ländercode, Betreibercode, Nummer. Die Bibliothek libphonenumber von Google ist der Industriestandard für die Telefonvalidierung. Sie bestimmt das Land anhand des Codes, prüft die Länge und das Format der Nummer. In Android kann PhoneNumberUtils.isGlobalPhoneNumber für die grundlegende Validierung verwendet werden.

Das Passwort hat mehrere Komplexitätskriterien: Mindestlänge, Vorhandensein von Groß- und Kleinbuchstaben, Ziffern, Sonderzeichen. Android hat keine integrierte Klasse für die Passwortvalidierung — jedes Projekt definiert seine eigenen Anforderungen. Typischerweise wird ein Passwort durch einen regulären Ausdruck oder eine Reihe von Bedingungen validiert. Es ist wichtig, genaue Anforderungen in der Fehlermeldung nicht preiszugeben: „Passwort ist zu einfach“ ist besser als „Ein Großbuchstabe und eine Ziffer sind erforderlich“.

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

Im Beispiel gibt validatePassword ein ValidationResult mit einem isValid-Feld und einer optionalen Fehlermeldung zurück. Dieser Ansatz ist für die Komposition praktisch: Mehrere Prüfungen werden nacheinander durchgeführt und der erste gefundene Fehler wird zurückgegeben. Die E-Mail- und Telefonvalidierung folgt dem gleichen Prinzip — jede gibt ein Ergebnis mit einer Nachricht oder Erfolg zurück.

Wann sollte die Validierung durchgeführt werden?

Der Validierungszeitpunkt beeinflusst die UX erheblich. Es gibt drei Strategien: Validierung nach jedem Zeichen (sofort), nach Fokusverlust (onFocusLost) und beim Absenden des Formulars (onSubmit). Jede Strategie eignet sich für verschiedene Szenarien. Die sofortige Validierung ist gut für Felder mit strengen Einschränkungen — Telefonnummer, PIN-Code. OnFocusLost ist für E-Mail und Name geeignet. OnSubmit ist für Pflichtfelder geeignet.

Laut den Material Design Guidelines wird empfohlen, Strategien zu kombinieren: Ein Feld sollte bei Fokusverlust und auch beim Absenden des Formulars validiert werden. Die sofortige Validierung ist angemessen, wenn die Einschränkung offensichtlich ist — beispielsweise die maximale Feldlänge. Wenn für E-Mail nach jedem Zeichen ein Fehler angezeigt wird, sieht der Benutzer eine Nachricht, bevor er die Eingabe beendet. Das ist ärgerlich und reduziert die Conversion.

Die erster-Fehler-Regel: Beim Absenden eines Formulars zeigen Sie einen Fehler nur für das erste ungültige Feld an. Überfordern Sie den Benutzer nicht mit einer Liste von 10 Fehlern. Nach der Korrektur des ersten Fehlers kann der nächste angezeigt werden. Diese schrittweise Anleitung reduziert die kognitive Belastung und hilft dem Benutzer, das Formular schneller auszufüllen.

Werkzeuge und Bibliotheken für die Validierung

Das Android SDK bietet grundlegende Werkzeuge für Validate: Patterns für E-Mail und Telefon, TextUtils für Leerheitsprüfung, reguläre Ausdrücke für beliebige Muster. Für Projekte mit 1-3 Feldern ist dies ausreichend. In Formularen mit 10+ Feldern wird die manuelle Validierung jedoch schwer wartbar — jedes neue Feld erfordert eine separate Funktion und aktualisierte Übermittlungslogik.

Beliebte Validierungsbibliotheken: Android Saripaar (Annotationen @Email, @NotEmpty, @Password), Apache Commons Validator (E-Mail-, URL-, Kreditkartennummern-Validierung), RxBinding + RxJava für reaktive Validierung. Saripaar ermöglicht es, Annotationen direkt auf Eingabefelder zu setzen und die Validierung mit einer Zeile aufzurufen: validator.validate(). Die Bibliothek zeigt Fehler automatisch über setError an.

Google empfiehlt die Verwendung von Material Design Components mit TextInputLayout. Die integrierte Validierung über setError, setHelperText und setCounterEnabled deckt grundlegende Szenarien ohne Drittanbieter-Bibliotheken ab. Für komplexe Projekte (Fintech, Gesundheitswesen) ist eine Kombination besser: Material Components + benutzerdefinierte Validierung mit Mustern aus der Domain-Ebene von Clean Architecture.

Häufige Fehler bei der Feldvalidierung

Der erste Fehler ist das Anzeigen eines Fehlers vor Beginn der Eingabe. Wenn ein Feld erforderlich ist, der Benutzer aber noch nicht mit der Eingabe begonnen hat, zeigen Sie nicht „Feld ist erforderlich“ an. Dies erzeugt ein falsches Problemgefühl. Ein Fehler sollte erst erscheinen, nachdem der Benutzer mit dem Feld interagiert hat: mit der Eingabe begonnen, das Feld verlassen oder versucht hat, das Formular abzusenden.

Der zweite Fehler ist eine unklare Fehlermeldung. Die Meldung sollte spezifisch sein und einen Vorschlag zur Behebung des Problems enthalten. „Ungültige E-Mail“ ist schlecht. „Die E-Mail muss @ und eine Domain enthalten, z. B. user@example.com“ ist gut. Der Benutzer sollte verstehen, was genau falsch ist und wie es behoben werden kann, ohne auf die Dokumentation zurückgreifen zu müssen.

Der dritte Fehler ist das Blockieren des Sendens ohne Erklärung. Wenn die Senden-Schaltfläche aufgrund von Validierungsfehlern inaktiv ist, sollte der Benutzer sehen, welche Felder ungültig sind. Ein grauer Knopf ohne Meldungen ist eine Sackgasse für den Benutzer. Markieren Sie immer Felder mit Fehlern und zeigen Sie den Fehlertext neben jedem ungültigen Feld an.