Error State — vad är det, visning av felfält och implementering i Android

Vad är felfältsstatus i Android?

Error State är ett speciellt visningsläge för inmatningsfält som aktiveras när inskickad data inte klarar validering. Visuellt innehåller Error State tre komponenter: ändring av fältets ram- eller bakgrundsfärg (vanligtvis röd), uppkomst av ett textmeddelande under fältet med felbeskrivning och valfritt — en ikon eller markering. Syftet med Error State är att omedelbart dra användarens uppmärksamhet till det problematiska fältet och föreslå hur felet ska åtgärdas.

I Android är Error State implementerat på TextInputLayout-nivå från Material Design Components. TextInputLayout omsluter EditText och hanterar dess tillstånd: normal, focused, error, disabled. Metoden setError(String) växlar fältet till feltillstånd, ändrar ramfärg och visar meddelandet. Vid textändring eller anrop av setError(null) återgår fältet till normal.

Enligt Material Design Guidelines ska Error State vara märkbar men inte dominant. Den röda ramfärgen ska kontrastera med normaltillståndet men inte överbelasta gränssnittet. Felmeddelandet ska innehålla specifik information om problemet och hur det löses. Felikonen (t.ex. röd cirkel med utropstecken) förstärker den visuella signalen.

Hur setError fungerar i TextInputLayout

Metoden setError(CharSequence errorText) växlar TextInputLayout till feltillstånd. Parametern errorText är texten som visas under fältet. Om null skickas återställs felet. TextInputLayout hanterar animeringen: feltexten visas med en mjuk övergång, ramen blir röd. Felikonen (som standard ett utropstecken i en cirkel) visas i slutet av fältet.

Viktiga detaljer: setErrorEnabled(true) måste anropas före setError för att reservera utrymme för felmeddelandet. Annars kan layouten hoppa när felet visas eftersom utrymme för meddelandet inte är reserverat. Det rekommenderas att alltid aktivera felstöd i XML via app:errorEnabled="true" för att undvika layoutförskjutning.

Metoden setError återställs automatiskt vid textändring om alternativet setErrorEnabled(true) är aktiverat. Detta beteende är praktiskt för realtidsvalidering: så snart användaren börjar korrigera felet försvinner den röda ramen och fältet återgår till normalt tillstånd. För komplexa scenarier kan denna automatiska återställning dock vara oönskad — hantera felet manuellt i sådana fall.

val til = findViewById<TextInputLayout>(R.id.til_email)

// Aktivera felstöd (ange i XML annars)
til.isErrorEnabled = true

// Ange felmeddelande
til.error = "Invalid email address"

// Rensa fel
til.error = null

// Kontrollera om fel finns
if (til.error != null) {
    // Fältet är i felstatus
}

I exemplet används Kotlin-egenskaper för åtkomst till setError/isErrorEnabled. TextInputLayout uppdaterar automatiskt gränssnittet: ändrar boxStrokeColor-färg, visar felikonen, visar feltexten. Om du ändrar text i EditText återställs felet automatiskt. För manuell återställning, ställ in error = null.

Alternativa sätt att visa fel

Alla projekt använder inte Material Design Components. För anpassad felvisning kan du använda en separat TextView under EditText som blir synlig vid fel. Detta tillvägagångssätt ger full kontroll över stilar och meddelandets placering. Du kan till exempel placera meddelandet till höger om fältet, använda en annan bakgrundsfärg eller lägga till en ikon till vänster om texten.

I Jetpack Compose implementeras Error State via parametern isError i OutlinedTextField eller TextField. När isError = true blir ramen röd och du kan visa feltext via supportingText. Compose har ingen inbyggd automatisk rensning vid textändring — utvecklaren hanterar feltillståndet manuellt via remember och mutableStateOf.

För gruppfel (ett meddelande för flera fält, t.ex. \"Fyll i alla obligatoriska fält\") används Snackbar, Dialog eller ett inline-block högst upp i formuläret. Ett gruppfel ersätter inte Error State för enskilda fält utan kompletterar det. Användaren ser först det allmänna meddelandet och söker sedan efter specifika fält med fel.

Färger, ikoner och felanimering

Error State-färgen i Material Design Components hanteras via attributet boxStrokeErrorColor eller attributet colorError i temat. Som standard används systemets röda färg, men den kan åsidosättas i appens tema eller direkt i TextInputLayout via app:boxStrokeErrorColor="@color/customErrorColor". För stöd av mörkt tema rekommenderas att använda en väljare med olika färger för ljust och mörkt läge.

Felikonen konfigureras via app:errorIconDrawable. Som standard visas ett utropstecken i en cirkel. Den kan ersättas med en anpassad ikon eller helt tas bort genom att ställa in app:errorIconDrawable="@null". Ikonen visas i slutet av TextInputLayout och fungerar som en extra visuell markör. I Material Design 3 är felikonen obligatorisk för tillgänglighet.

Animering av feluppträdande är inbyggd i TextInputLayout: texten visas från nedre delen med en mjuk opacitetsförändring. För anpassad animering, använd Transition API eller MotionLayout. Till exempel drar skakning av fältet vid fel extra uppmärksamhet. Men överdriven användning av animering försämrar användarupplevelsen — mjuk meddelandeuppträdande är tillräckligt.

Hantera felstatus vid validering

Hantering av Error State är uppdelad i två steg: inställning av fel vid fältvalidering och återställning av fel vid korrigering. I det enklaste fallet anropas validering i TextWatcher.afterTextChanged: om värdet är ogiltigt anropas setError med ett felmeddelande. Om det är giltigt — setError(null). TextInputLayout döljer automatiskt felet när setError(null) återställer tillståndet.

För formulärvalidering ställs fel in vid formulärinskickningssteget. Gå igenom alla fält, kontrollera varje, ställ in fel för ogiltiga fält och fokusera på det första felaktiga fältet. Skickaknappen blockeras under denna tid. Om formuläret är stort rekommenderas att rulla skärmen till det första fältet med fel och automatiskt fokusera på det.

Regeln single error focus: vid formulärinskickning, ställ in fokus endast på det första fältet med fel. Användaren korrigerar ett fel i taget, och efter korrigering får nästa fält med fel automatiskt fokus. Detta steg-för-steg tillvägagångssätt minskar kognitiv belastning. Material TextInputLayout fångar inte fokus vid inställning av fel — detta måste göras manuellt via requestFocus().

Misstag vid arbete med Error State

Första misstaget — saknad isErrorEnabled. Om setErrorEnabled inte anropas före setError kan layouten förskjutas när felmeddelandet visas. Detta är särskilt kritiskt om fältet är mitt på skärmen — användaren förlorar rullningspositionen. Aktivera alltid setErrorEnabled(true) i XML via app:errorEnabled="true" eller programmatiskt före inställning av felet.

Andra misstaget — för långt felmeddelande. Lång text bryts till flera rader och kan täcka angränsande fält. Rekommenderad längd på felmeddelande är 20-40 tecken. Om mer information behövs, använd helperText (tips) i normalt tillstånd eller ett verktygstips för ytterligare förklaring. Korthet är grunden för en bra Error State.

Tredje misstaget — ignorera tillgänglighet. Error State måste vara tillgängligt för skärmläsare. TextInputLayout meddelar automatiskt felet via contentDescription, men anpassade implementeringar måste göra detta manuellt. Använd announceForAccessibility() eller android:importantForAccessibility för felmeddelanden. TalkBack-användare bör höra felet omedelbart efter att det visas.