Kotlin Collections and Functional Programming

An imperative loop that filters, sorts, groups and maps a list can easily take 25 lines and three mutable variables. The same logic as a Kotlin collection pipeline is often five lines, with no mutation and clear intent. This guide covers the operators you'll use constantly in Android code, and when to reach for sequences or immutable collections.

Read-only vs mutable collections

val tags: List<String> = listOf("kotlin", "compose")         // read-only interface
val cart: MutableList<String> = mutableListOf("p1")           // mutable
val updated = tags + "flow"                                   // creates a NEW list

List is a read-only view, not a deep guarantee of immutability. The underlying object might be mutable elsewhere. For UI state, create new lists rather than mutating, and consider kotlinx.collections.immutable (persistentListOf, ImmutableList) when you want truly immutable types that Compose treats as stable.

A real pipeline: API data to UI sections

data class Txn(val id: String, val amountPaise: Long, val status: String, val at: LocalDateTime)
data class TxnSection(val date: LocalDate, val totalPaise: Long, val items: List<Txn>)

fun toSections(txns: List<Txn>): List<TxnSection> =
    txns
        .filter { it.status != "FAILED" }
        .sortedByDescending { it.at }
        .groupBy { it.at.toLocalDate() }          // Map<LocalDate, List<Txn>>, insertion-ordered
        .map { (date, items) -> TxnSection(date, items.sumOf { it.amountPaise }, items) }

LazyColumn {
    sections.forEach { section ->
        stickyHeader(key = section.date) { DateHeader(section.date, section.totalPaise) }
        items(section.items, key = { it.id }) { txn -> TxnRow(txn) }
    }
}

The operators you'll use most

fold and reduce

data class Stats(val count: Int = 0, val totalPaise: Long = 0, val refunds: Int = 0)

val stats = txns.fold(Stats()) { acc, t ->
    acc.copy(
        count = acc.count + 1,
        totalPaise = acc.totalPaise + t.amountPaise,
        refunds = acc.refunds + if (t.status == "REFUNDED") 1 else 0,
    )
}

Prefer specific operators (sumOf, count) when they fit. Use fold when you compute several values in one pass.

Efficient lookups: avoid O(n²)

// ❌ For each order, scan all products: slow for large lists
val rows = orders.map { o -> o to products.first { it.id == o.productId } }

// ✅ Build a map once, then O(1) lookups
val productsById = products.associateBy { it.id }
val rows2 = orders.mapNotNull { o -> productsById[o.productId]?.let { p -> o to p } }

Sequences: lazy evaluation

List operations are eager: each step creates a full intermediate list. asSequence() makes them lazy, processing one element at a time through the whole chain, and stopping early when possible.

val firstTenMatches = hugeList.asSequence()
    .filter { it.matches(query) }
    .map { it.toUi() }
    .take(10)              // stops as soon as 10 are found
    .toList()

Use sequences for large collections with several steps, or when you short-circuit with take or first. For small lists (typical UI lists of tens or hundreds of items), plain lists are usually just as fast and simpler.

Android-specific tips

• Transform data outside composables, in the ViewModel or with remember(key), so pipelines don't rerun on every recomposition.
• Move heavy processing off the main thread (withContext(Dispatchers.Default)) for thousands of items.
• Prefer SQL for filtering and aggregating large datasets in Room, rather than loading everything into memory and filtering in Kotlin.

Common mistakes

• Using first { } when nothing may match, which throws NoSuchElementException. Use firstOrNull.
• Mutating a list while iterating over it.
• Chaining filter then count when count { } does it in one pass.
• Exposing MutableList in UI state.

Frequently asked questions

Conclusion

Kotlin's collection API lets you express data transformations as small, readable, mutation-free pipelines. Learn the dozen core operators, build maps for lookups, use sequences for large or short-circuiting chains, and keep heavy transformations out of composables.

Next step: write your own reusable operators with Extension and Higher-Order Functions.