Collections im Überblick

Collections sind in Kotlin die Standardwerkzeuge, um mehrere Werte zusammenzufassen. In Android-Apps begegnen sie dir überall: bei Listen auf dem Bildschirm, bei ausgewählten IDs, bei Einstellungen, bei API-Antworten und im State deines ViewModels. Der wichtige Schritt ist nicht, jede Funktion der Standardbibliothek auswendig zu kennen, sondern bewusst zu entscheiden: Brauchst du Reihenfolge, Eindeutigkeit oder schnellen Zugriff über einen Schlüssel?

Was ist das?

Eine Collection ist eine Datenstruktur für mehrere Elemente. Kotlin gibt dir dafür vor allem drei Grundformen: List, Set und Map. Eine List ist eine geordnete Sammlung. Die Reihenfolge ist wichtig, und derselbe Wert darf mehrfach vorkommen. Ein Set ist eine Sammlung eindeutiger Werte. Es beantwortet vor allem die Frage: Ist dieses Element enthalten oder nicht? Eine Map ordnet Schlüssel zu Werten zu. Du fragst also nicht nach Position 3, sondern nach einem bestimmten Schlüssel, zum Beispiel einer User-ID.

Dieses mentale Modell hilft dir im Alltag mehr als eine lange API-Liste. Wenn du Produkte in einer festen Reihenfolge in einer Compose-Liste anzeigen willst, passt meistens eine List. Wenn du merken willst, welche Filter aktiv sind, passt oft ein Set, weil ein Filter nicht doppelt aktiv sein sollte. Wenn du Benutzerprofile nach ihrer ID ablegen willst, ist eine Map naheliegend, weil der Schlüssel direkt zur gesuchten Information führt.

In Kotlin gibt es außerdem unveränderliche und veränderliche Varianten. List, Set und Map beschreiben Sammlungen, die du über diese Referenz nicht verändern kannst. MutableList, MutableSet und MutableMap erlauben Änderungen wie Hinzufügen oder Entfernen. Gerade in Android-Architekturen ist das relevant: Nach außen gibst du häufig unveränderliche Collections aus, während du intern kontrolliert mit veränderlichen Daten arbeitest. So bleibt dein State nachvollziehbarer.

Wie funktioniert es?

List arbeitet positionsbasiert. Du kannst Elemente über ihren Index ansprechen, etwa items[0]. Das ist nützlich, wenn die Reihenfolge Teil der Bedeutung ist: Chat-Nachrichten, Suchergebnisse, Einstellungen in einer UI oder Zeilen in einer LazyColumn. Eine Liste erlaubt Duplikate. Das ist korrekt, wenn mehrere Einträge denselben Text oder denselben Status haben dürfen. Es ist aber problematisch, wenn du eigentlich Eindeutigkeit erwartest und diese nicht prüfst.

Set denkt nicht in Positionen, sondern in Mitgliedschaft. Ein Wert ist enthalten oder nicht enthalten. Wenn du denselben Wert erneut hinzufügst, bleibt er nur einmal vorhanden. Das ist nützlich für markierte IDs, Berechtigungen, Kategorien oder aktivierte Optionen. Ein häufiger Fehler ist, ein List zu verwenden und später überall mit distinct() aufzuräumen. Das kann funktionieren, verdeckt aber oft eine unklare Modellierung. Wenn Eindeutigkeit eine Regel deiner Fachlogik ist, sollte sie schon im Typ sichtbar werden.

Map besteht aus Schlüssel-Wert-Paaren. Jeder Schlüssel ist eindeutig, der Wert kann ersetzt werden. Damit eignet sich eine Map für Lookup-Szenarien: userById[id], settingsByKey[key] oder errorTextByField[fieldName]. Das ist lesbarer und meist effizienter als eine Liste immer wieder nach dem passenden Element zu durchsuchen. In Android kann das besonders in ViewModels, Mappern und UI-State-Klassen helfen, wenn Daten aus mehreren Quellen zusammengeführt werden.

Kotlin-Collections sind stark typisiert. List<String> sagt: Diese Liste enthält Strings. Map<Long, User> sagt: Der Schlüssel ist eine Long, der Wert ist ein User. Diese Typen schützen dich vor vielen Fehlern, bevor die App läuft. Dazu kommen Standardfunktionen wie map, filter, associateBy, groupBy, any und contains. Sie machen Collection-Code kompakt, aber du solltest sie weiterhin bewusst einsetzen. Eine kurze, klare Transformation ist gut. Eine lange Kette aus sechs Operationen kann im Code-Review schwer nachvollziehbar werden.

Für Compose ist noch ein Punkt wichtig: UI wird aus State abgeleitet. Wenn du eine Collection im State hältst, sollte klar sein, wann eine neue Collection entsteht und wann eine bestehende verändert wird. Häufig ist es besser, bei Änderungen eine neue Liste oder ein neues Set zu erzeugen, statt ein bestehendes Objekt still zu mutieren. Dadurch erkennt deine Architektur Änderungen sauberer, und dein Code bleibt leichter testbar.

In der Praxis

Stell dir vor, du baust eine Aufgabenliste. Du willst alle Aufgaben in Reihenfolge anzeigen, ausgewählte Aufgaben eindeutig merken und Aufgaben schnell per ID finden. Dafür können alle drei Collection-Typen gemeinsam sinnvoll sein:

data class Task(
    val id: Long,
    val title: String,
    val done: Boolean
)

data class TaskUiState(
    val tasks: List<Task>,
    val selectedTaskIds: Set<Long>,
    val taskById: Map<Long, Task>
)

fun buildTaskState(tasks: List<Task>, selectedIds: Set<Long>): TaskUiState {
    return TaskUiState(
        tasks = tasks,
        selectedTaskIds = selectedIds,
        taskById = tasks.associateBy { it.id }
    )
}

fun toggleSelection(state: TaskUiState, taskId: Long): TaskUiState {
    val newSelection = if (taskId in state.selectedTaskIds) {
        state.selectedTaskIds - taskId
    } else {
        state.selectedTaskIds + taskId
    }

    return state.copy(selectedTaskIds = newSelection)
}

In diesem Beispiel bleibt die List<Task> für die Anzeige zuständig. Sie bewahrt die Reihenfolge, in der die Aufgaben erscheinen sollen. Das Set<Long> speichert die Auswahl. Eine ID kann dadurch nicht versehentlich doppelt ausgewählt sein. Die Map<Long, Task> erlaubt schnellen Zugriff, wenn du eine Aufgabe anhand ihrer ID brauchst, zum Beispiel für eine Detailansicht oder eine Aktion aus einem Menü.

Eine praktische Entscheidungsregel lautet: Nutze List, wenn die Position oder Sortierung zählt. Nutze Set, wenn Eindeutigkeit zählt. Nutze Map, wenn du regelmäßig über einen Schlüssel zugreifst. Diese Regel ist nicht akademisch. Sie macht deinen Code für andere Entwickler lesbarer, weil der Typ bereits erklärt, welche Eigenschaft wichtig ist.

Eine typische Stolperfalle ist die falsche Verwendung von List als Ersatz für alles. Du speicherst dann zum Beispiel ausgewählte IDs in einer Liste und prüfst mit contains, ob eine ID schon vorhanden ist. Später kommen doppelte Einträge vor, die UI zählt falsch, und du musst an mehreren Stellen korrigieren. Ein Set hätte diese Regel direkt ausgedrückt. Eine andere Stolperfalle ist eine Map, deren Schlüssel nicht wirklich eindeutig ist. Wenn du associateBy { it.title } verwendest und zwei Aufgaben denselben Titel haben, überschreibt der spätere Eintrag den früheren. Für Schlüssel solltest du stabile IDs bevorzugen.

Prüfe auch, ob du veränderliche Collections wirklich brauchst. In einem Repository oder Mapper kann eine lokale MutableList sinnvoll sein, wenn du Daten Schritt für Schritt aufbaust. Im öffentlichen UI-State ist eine unveränderliche List meist besser. So verhinderst du, dass eine andere Schicht die Daten an einer unerwarteten Stelle verändert. Das unterstützt saubere Architektur und macht Unit-Tests leichter.

Zum Üben kannst du eine kleine Funktion schreiben, die eine Liste von Aufgaben in drei Formen umwandelt: sortierte Anzeige, Set der erledigten IDs und Map nach ID. Schreibe danach Tests für doppelte IDs, leere Listen und gleiche Titel. Im Debugger kannst du dir ansehen, wie associateBy reagiert, wenn Schlüssel mehrfach vorkommen. Genau an solchen kleinen Beispielen lernst du, wann ein Collection-Typ zu deinem Problem passt.

Fazit

Collections sind kein Nebenthema in Kotlin, sondern ein Grundbaustein für verständlichen Android-Code. Wenn du zwischen List, Set und Map bewusst wählst, modellierst du Anforderungen direkt im Typ: Reihenfolge, Eindeutigkeit oder Schlüsselzugriff. Prüfe beim nächsten Code-Review eine konkrete Stelle in deinem Projekt und frage dich: Erzählt diese Collection schon, was fachlich gemeint ist? Schreibe dazu einen kleinen Test oder nutze den Debugger, bis du das Verhalten bei Duplikaten, Sortierung und fehlenden Schlüsseln sicher erklären kannst.