Collections: List, Set and Map

Why collections?

Apps rarely deal with one value. A cart has many items, a class has many students, a city has many pin codes. A collection holds many values of one type in a single variable. Choosing the right one makes code simpler and faster.

Lists

fun main() {
    val cities = listOf("Chennai", "Madurai", "Coimbatore")   // read-only
    println(cities[0])              // Chennai
    println(cities.size)            // 3
    println("Madurai" in cities)    // true
    println(cities.getOrNull(9))    // null instead of a crash

    val cart = mutableListOf("milk", "bread")                  // mutable
    cart.add("eggs")
    cart.remove("bread")
    cart[0] = "curd"
    println(cart)                   // [curd, eggs]
}

Positions in a list start at 0, so the first item is cities[0] and the last is cities[cities.size - 1], or simply cities.last(). The in operator checks whether a value is present anywhere in the list.

Sets

val tags = mutableSetOf("veg", "spicy", "veg")
println(tags)              // [veg, spicy]: the duplicate is ignored
println(tags.add("spicy")) // false: already there

Maps

fun main() {
    val pinToCity = mapOf("600001" to "Chennai", "110001" to "New Delhi")
    println(pinToCity["600001"])               // Chennai
    println(pinToCity["999999"])               // null: missing key
    println(pinToCity.getOrDefault("999999", "Unknown"))

    val stock = mutableMapOf("rice" to 40, "dal" to 25)
    stock["rice"] = 35                          // update
    stock["sugar"] = 10                         // add
    for ((item, qty) in stock) println("$item: $qty")
}

Arrays versus lists

Kotlin also has Array<T> (arrayOf), a fixed-size container you mostly meet when calling Java APIs or using vararg. In everyday Kotlin and Android code, prefer List and MutableList: they have more helpful functions, work better with Compose and are what most libraries expect.

Creating empty collections

When a collection starts empty, the compiler cannot guess the item type from values, so you give it: mutableListOf<String>(), emptyList<Int>(), mutableMapOf<String, Int>(). Forgetting the type gives the error "Not enough information to infer type variable T".

Read-only is not immutable

List<T> is a read-only view: it has no add or remove functions. But if the same list object is also referenced as a MutableList somewhere else, it can still change behind your back. For UI state in Android, expose read-only types (List) and keep the mutable one private inside the class that owns it.

class Cart {
    private val _items = mutableListOf<String>()
    val items: List<String> get() = _items       // others can read, not change

    fun add(item: String) { _items.add(item) }
}

Common mistakes

• Trying to add to a listOf(...) list: there is no add function. Use mutableListOf.
• Using list[i] with untrusted indexes. Use getOrNull(i).
• Forgetting that map[key] can be null. Handle it with ?: or getOrDefault.
• Exposing a MutableList publicly so any code can change it. Expose List instead.