Corrutinas: dos corredores y un hilo que no se bloquea

Prerrequisitos. Kotlin básico —funciones, lambdas, clases— y saber armar una pantalla sencilla en Compose con Column, Row, Button y remember { mutableStateOf(...) }. Si hiciste la Práctica 2, vas sobrado.

Relación con el reto. Todo lo que tu proyecto haga contra una base de datos o contra la red va a pasar por aquí. Hoy no hay ni una cosa ni la otra: delay() simula el trabajo lento para que el tema sea la concurrencia y nada más.

Lo que vas a construir

Cuando termines, esto tiene que ser cierto

1. Las dos barras avanzan al mismo tiempo, no una después de la otra.
2. El botón cambia a “Arrancar” exactamente cuando el segundo corredor termina.
3. “Pausa” detiene la carrera y conserva el avance; “Reiniciar” la manda a cero.
4. Mientras la carrera corre, la interfaz no se siente trabada.

Parte 0 · 30 min · en Kotlin PlaygroundEl taller de conceptos

Abre https://play.kotlinlang.org y no cierres esa pestaña en media hora. Sin proyecto, sin emulador, sin Gradle: solo main() y la salida.

En Playground, activa kotlinx.coroutines en el menú de la derecha (el desplegable de librerías). Sin eso, delay no existe.

P0.1 — Síncrono, y el primer delay6 min

Empieza por lo aburrido:

fun main() {
    println("Arranca la carrera")
    println("Jugador 1 en la meta")
}

Las dos líneas salen al instante y en orden. Eso es código síncrono: una cosa, luego la otra.

Ahora mete una espera:

import kotlinx.coroutines.*

fun main() {
    runBlocking {
        println("Arranca la carrera")
        delay(1000)
        println("Jugador 1 en la meta")
    }
}

Tarda un segundo. Dos piezas nuevas:

delay(1000) es una función de suspensión: pausa la corrutina un segundo. No es Thread.sleep. La diferencia es todo el tema de hoy.

runBlocking { } construye una corrutina y bloquea el hilo hasta que termina todo lo que hay dentro. Es la puerta de entrada desde código normal — y es para aprender y para pruebas, no para una app. En Android nunca vas a escribir runBlocking.

P0.2 — suspend6 min

Saca las esperas a sus propias funciones:

import kotlinx.coroutines.*

suspend fun correJugadorUno() {
    delay(1000)
    println("Jugador 1 en la meta")
}

suspend fun correJugadorDos() {
    delay(1000)
    println("Jugador 2 en la meta")
}

fun main() {
    runBlocking {
        println("Arranca la carrera")
        correJugadorUno()
        correJugadorDos()
        println("Se acabó")
    }
}

Córrelo y cuenta los segundos: son dos, no uno.

El modificador suspend marca una función que puede pausarse y reanudarse. Solo se puede llamar desde otra función suspend o desde dentro de una corrutina — por eso main() necesita el runBlocking.

Y fíjate en lo importante: aunque las dos funciones son suspend, corrieron una después de la otra. Suspender no es correr en paralelo.

suspend no significa “esto va en paralelo”. Significa “esto se puede pausar”.

P0.3 — launch, la primera concurrencia6 min

fun main() {
    runBlocking {
        println("Arranca la carrera")
        launch { correJugadorUno() }
        launch { correJugadorDos() }
        println("Se acabó")
    }
}

Ahora tarda un segundo, y la salida sale desordenada respecto a lo que escribiste:

Arranca la carrera
Se acabó
Jugador 1 en la meta
Jugador 2 en la meta

launch { } arranca una corrutina nueva y regresa de inmediato, sin esperarla. Por eso “Se acabó” se imprime antes que las metas: es lanzar y olvidarse.

Lo que sí espera es el runBlocking: no termina hasta que sus corrutinas hijas terminan. Ahí está la palabra estructurada de “concurrencia estructurada” — nadie se queda huérfano.

P0.4 — async y await6 min

launch no devuelve nada. Cuando sí necesitas el resultado, se usa async:

import kotlinx.coroutines.*

suspend fun tiempoJugadorUno(): String {
    delay(1000)
    return "1: 12.4 s"
}

suspend fun tiempoJugadorDos(): String {
    delay(1000)
    return "2: 11.8 s"
}

fun main() {
    runBlocking {
        println("Arranca la carrera")
        val uno: Deferred<String> = async { tiempoJugadorUno() }
        val dos: Deferred<String> = async { tiempoJugadorDos() }
        println("${uno.await()} — ${dos.await()}")
        println("Se acabó")
    }
}

Un segundo en total, y la salida en orden.

async devuelve un Deferred<T>: la promesa de que el valor va a estar. await() es donde lo cobras — y ahí sí se espera.

P0.5 — coroutineScope6 min

Falta empaquetar: que “la carrera” sea una operación que por dentro hace dos cosas a la vez.

suspend fun resultados(): String = coroutineScope {
    val uno = async { tiempoJugadorUno() }
    val dos = async { tiempoJugadorDos() }
    "${uno.await()} — ${dos.await()}"
}

fun main() {
    runBlocking {
        println("Arranca la carrera")
        println(resultados())
        println("Se acabó")
    }
}

coroutineScope { } crea un ámbito y no regresa hasta que todas sus corrutinas hijas terminaron. Desde fuera, resultados() es una función suspendida normal: quien la llama no se entera de que por dentro hubo concurrencia.

Esa es la idea que vas a usar el resto de la práctica.

Bloque A · 20 minLa app y el corredor

Cierra Playground. De aquí en adelante es Android Studio.

A1 — Proyecto nuevo5 min

Empty Activity (Compose), paquete mx.tec.racetracker.

mx/tec/racetracker/
├─ MainActivity.kt
├─ RaceParticipant.kt   ← el corredor: estado y la función suspend
└─ ui/
   └─ RaceTrackerApp.kt ← la pantalla y el arranque de la carrera

No hace falta agregar ninguna dependencia: kotlinx-coroutines ya viene con Compose, y LaunchedEffect es parte de androidx.compose.runtime.

A2 — El corredor10 min

Una clase, un dato y una función que tarda.

package mx.tec.racetracker

import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableIntStateOf
import androidx.compose.runtime.setValue
import kotlinx.coroutines.delay

class RaceParticipant(
    val name: String,
    val maxProgress: Int = 100,
    val progressDelayMillis: Long = 100L,
    private val progressIncrement: Int = 1
) {
    var currentProgress by mutableIntStateOf(0)
        private set

    /** Avanza de a poco hasta la meta. Tarda, pero no bloquea el hilo. */
    suspend fun run() {
        while (currentProgress < maxProgress) {
            delay(progressDelayMillis)
            currentProgress += progressIncrement
        }
    }

    fun reset() {
        currentProgress = 0
    }
}

Tres cosas que vale la pena mirar despacio:

private set. Igual que en el ViewModel de la Práctica 2: desde fuera se lee el avance, pero solo el corredor lo cambia.

mutableIntStateOf y no mutableStateOf. Para un Int existe la versión especializada, que evita empaquetar el número en un objeto en cada cambio. Aquí son cientos de cambios por carrera.

El while con delay adentro. Ese ciclo se ve como código bloqueante y no lo es: en cada vuelta suelta el hilo 400 ms.

A3 — La pantalla5 min

package mx.tec.racetracker.ui

import androidx.compose.foundation.layout.*
import androidx.compose.material3.*
import androidx.compose.runtime.*
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp
import mx.tec.racetracker.RaceParticipant

@Composable
fun RaceTrackerScreen(
    playerOne: RaceParticipant,
    playerTwo: RaceParticipant,
    isRunning: Boolean,
    onRunStateChange: (Boolean) -> Unit,
    onReset: () -> Unit,
    modifier: Modifier = Modifier
) {
    Column(
        modifier = modifier.fillMaxSize().padding(24.dp),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text("Carrera", style = MaterialTheme.typography.headlineMedium)
        Spacer(Modifier.height(32.dp))

        StatusIndicator(playerOne)
        Spacer(Modifier.height(16.dp))
        StatusIndicator(playerTwo)

        Spacer(Modifier.height(32.dp))
        Row(horizontalArrangement = Arrangement.spacedBy(12.dp)) {
            Button(onClick = { onRunStateChange(!isRunning) }) {
                Text(if (isRunning) "Pausa" else "Arrancar")
            }
            OutlinedButton(onClick = onReset) { Text("Reiniciar") }
        }
    }
}

@Composable
private fun StatusIndicator(participant: RaceParticipant, modifier: Modifier = Modifier) {
    Column(modifier.fillMaxWidth()) {
        Row(
            modifier = Modifier.fillMaxWidth(),
            horizontalArrangement = Arrangement.SpaceBetween
        ) {
            Text(participant.name, style = MaterialTheme.typography.titleMedium)
            Text("${participant.currentProgress} %")
        }
        Spacer(Modifier.height(6.dp))
        LinearProgressIndicator(
            progress = { participant.currentProgress / participant.maxProgress.toFloat() },
            modifier = Modifier.fillMaxWidth().height(8.dp)
        )
    }
}

Bloque B · 30 minArrancar la carrera, y el bug

B1 — LaunchedEffect10 min

Ya tienes una función suspend y una pantalla. Falta el puente: quién llama a run().

No puede ser el onClick, porque un onClick no es una corrutina. Y tampoco puede ser el cuerpo del composable, porque eso se ejecuta en cada recomposición — decenas de veces por segundo.

La pieza es LaunchedEffect:

@Composable
fun RaceTrackerApp() {
    val playerOne = remember { RaceParticipant(name = "Jugador 1", progressIncrement = 1) }
    val playerTwo = remember { RaceParticipant(name = "Jugador 2", progressIncrement = 2) }
    var raceInProgress by remember { mutableStateOf(false) }

    if (raceInProgress) {
        LaunchedEffect(playerOne, playerTwo) {
            playerOne.run()
            playerTwo.run()
            raceInProgress = false
        }
    }

    RaceTrackerScreen(
        playerOne = playerOne,
        playerTwo = playerTwo,
        isRunning = raceInProgress,
        onRunStateChange = { raceInProgress = it },
        onReset = {
            playerOne.reset()
            playerTwo.reset()
            raceInProgress = false
        }
    )
}

Y en MainActivity:

setContent {
    RaceTrackerTheme {
        Surface(modifier = Modifier.fillMaxSize()) {
            RaceTrackerApp()
        }
    }
}

LaunchedEffect hace tres cosas por ti:

1. Lanza una corrutina cuando el composable entra en la composición, así que dentro de sus llaves ya puedes llamar funciones suspend.
2. No la relanza mientras sus llaves —aquí playerOne y playerTwo— no cambien. Sin eso, cada recomposición arrancaría otra carrera.
3. La cancela cuando el composable sale de la composición. Ese if (raceInProgress) no es decorativo: al ponerse en false, el LaunchedEffect desaparece y la corrutina se cancela sola. Es lo que hace funcionar el botón de Pausa.

B2 — 🔴 El bug8 min

No lo arregles todavía. Míralo.

B3 — launch: los dos a la vez12 min

if (raceInProgress) {
    LaunchedEffect(playerOne, playerTwo) {
        launch { playerOne.run() }
        launch { playerTwo.run() }
        raceInProgress = false
    }
}

Necesitas el import kotlinx.coroutines.launch.

Corre. Las dos barras avanzan juntas y el Jugador 2 llega al doble de velocidad, como debe ser.

Bloque C · 25 minEsperar y cancelar

C1 — El segundo bug10 min

Este es más sutil que el del Bloque B, y por eso importa más.

Arranca la carrera y mira el botón: dice “Pausa” apenas un instante y vuelve a decir “Arrancar” de inmediato, con las dos barras todavía a la mitad.

El estado raceInProgress está mintiendo.

launch { playerOne.run() }
launch { playerTwo.run() }
raceInProgress = false

C2 — coroutineScope7 min

Hace falta algo que espere a las dos corrutinas antes de seguir. Ya lo conoces:

if (raceInProgress) {
    LaunchedEffect(playerOne, playerTwo) {
        coroutineScope {
            launch { playerOne.run() }
            launch { playerTwo.run() }
        }
        raceInProgress = false
    }
}

Import: kotlinx.coroutines.coroutineScope.

coroutineScope { } no devuelve el control hasta que todas sus corrutinas hijas terminaron. La línea de abajo se convierte, por fin, en “cuando acabe la carrera”.

launch lanza. coroutineScope espera. La concurrencia se pide; la espera también.

C3 — Cancelar sin romper nada8 min

Cuando tocas “Pausa”, el LaunchedEffect cancela sus corrutinas. Cancelar en Kotlin se hace lanzando una CancellationException dentro de la corrutina, y eso tiene una consecuencia que conviene conocer antes de toparse con ella.

Prueba a envolver el ciclo en un try/catch mal escrito:

// ❌ A PROPÓSITO MAL
suspend fun run() {
    try {
        while (currentProgress < maxProgress) {
            delay(progressDelayMillis)
            currentProgress += progressIncrement
        }
    } catch (e: Exception) {
        println("algo pasó")
    }
}

Con eso, “Pausa” deja de funcionar bien: atrapaste la CancellationException y te la quedaste, así que la corrutina cree que la cancelación no ocurrió.

La forma correcta:

suspend fun run() {
    try {
        while (currentProgress < maxProgress) {
            delay(progressDelayMillis)
            currentProgress += progressIncrement
        }
    } catch (e: CancellationException) {
        // Se registra si hace falta, pero SIEMPRE se vuelve a lanzar:
        // es como el sistema de corrutinas sabe que la cancelación surtió efecto.
        throw e
    }
}

Import: kotlin.coroutines.cancellation.CancellationException.

Paso D · 13 minDónde vive cada corrutina

Los últimos minutos son de mapa, no de teclado.

El ámbito decide el ciclo de vida6 min

Toda corrutina vive dentro de un CoroutineScope, y ese ámbito está atado a algo que muere:

La regla que amarra todo: cuando el ámbito muere, cancela a todos sus hijos. Por eso no tuviste que escribir ni una línea para que “Pausa” funcione.

Los hilos, y por qué no los tocaste7 min

Un dispatcher decide en qué hilo corre una corrutina. Hay tres:

Se cambia con withContext:

suspend fun cargarResultados(): List<String> = withContext(Dispatchers.IO) {
    // aquí ya estamos en un hilo de trabajo
    leerDelDisco()
}

Hoy no usaste ninguno, y no fue un descuido: delay no bloquea, así que el hilo principal nunca estuvo ocupado. Si hubieras puesto Thread.sleep(400) en lugar de delay(400), la app se habría congelado — barras trabadas y botones que no responden.

Extensión para entregar — la quiniela

Los tres cambios de esta sección son parte de la entrega, y se hacen fuera de clase. La práctica en el salón termina en el Paso D; esto es lo que demuestra que entendiste lo que hiciste.

La idea: antes de arrancar, el usuario apuesta por un corredor. Si acierta, suma un punto. El marcador se conserva carrera tras carrera.

1. Un tercer corredor

Agrega al Jugador 3 a la carrera y a la pantalla.

Hazlo primero como venías: una tercera variable, un tercer launch, un tercer StatusIndicator. Cuando funcione, mira las tres variables juntas y decide si no era una lista. Esa decisión, y por qué la tomaste, va en la bitácora.

2. La apuesta

Antes de arrancar, el usuario elige a uno de los tres como su candidato a ganar. Mientras la carrera corre, la elección no se puede cambiar.

Con las velocidades fijas de hoy —1, 2 y 3— el Jugador 3 gana siempre y apostar no tiene sentido. Así que cada carrera tiene que sortear las velocidades de los tres corredores al arrancar. Sin eso, los otros dos puntos de la extensión no miden nada.

3. El marcador de aciertos

Al terminar la carrera, la app dice quién ganó y si el usuario acertó. Si acertó, el marcador sube un punto.

El marcador cuenta aciertos sobre carreras corridas —“3 de 7”— y sobrevive a todas las carreras de la sesión. “Reiniciar” pone la carrera en cero, no el marcador: para eso agrega un botón aparte.

Criterios de aceptación

1. Corren tres barras a la vez, con velocidades distintas en cada carrera.
2. No se puede apostar con la carrera en curso, ni arrancar sin haber apostado.
3. Al terminar, la app declara ganador y actualiza el marcador solo si acertaste.
4. El marcador se conserva entre carreras y al girar el teléfono.
5. Sigue sin haber un solo Thread.sleep, y “Pausa” sigue funcionando.

Retos para casa

Opcionales, en orden de dificultad. Van después de la extensión.

1. Velocidad configurable. Un Slider que cambie progressDelayMillis antes de arrancar.
2. Cancelar solo a uno. Un botón por corredor que lo saque de la carrera sin afectar a los otros. (Pista: launch devuelve un Job, y Job tiene cancel().)
3. Trabajo de verdad. Cambia el delay por un cálculo pesado real dentro de withContext(Dispatchers.Default) y comprueba que la interfaz sigue fluida.
4. Podio completo. No solo el ganador: primero, segundo y tercero, en orden de llegada.
5. Racha. Además del marcador, cuántos aciertos seguidos lleva el usuario.

Problemas comunes

IA en esta práctica — nivel tutor

Permitido: explicar, diagnosticar, contrastar tu diseño. Prohibido: generar el código de los entregables.

• “Explícame la diferencia entre Thread.sleep(1000) y delay(1000) en términos de qué pasa con el hilo. Sin código.”
• “Tengo dos launch seguidos y la línea de abajo se ejecuta antes de tiempo. Explícame por qué, sin corregirme el código.”
• “¿Por qué hay que volver a lanzar CancellationException en lugar de tragársela?”

Y como en la Práctica 2: verifica rompiendo el código a propósito. Los pasos B2, C1 y el checkpoint final son exactamente eso.

Rúbrica

Defensa oral — 2 min, aleatoria, obligatoria para acreditar

1. Quita el coroutineScope y deja los dos launch. ¿Qué se rompe y por qué?
2. ¿Por qué run() no puede llamarse desde un onClick?
3. ¿Quién cancela las corrutinas cuando tocas “Pausa”? Nadie escribió cancel().
4. Si delay no bloquea el hilo, ¿qué hilo estaba usando la carrera?
5. ¿Cuándo usarías async en vez de launch en esta app?
6. En tu quiniela, ¿cómo supiste quién llegó primero? ¿Por qué no bastaba con await()?

Entregables

1. Repositorio con un commit por bloque: bloque-a, bloque-b, bloque-c, paso-d, y uno más llamado quiniela con la extensión.
2. Video de 40 s: arrancar, pausar a media carrera, reanudar y terminar, mostrando el botón.
3. Video de 40 s de la quiniela: apostar, correr dos carreras seguidas —una acertando y otra no— y girar el teléfono para mostrar que el marcador sigue ahí.
4. docs/bitacora.md con los ejercicios 0, B2 y C1, más la decisión sobre la lista de corredores.