Tema 1 · Fundamentos y origen de los eventos

Esta sesión práctica aplica el mismo vocabulario en tres sitios distintos:

El vocabulario de hoy

En pde-plantilla la respuesta ya se intuye: escribís cosas como boton.setOnClickListener { ... } y nunca llamáis vosotros a esa lambda. Alguien la llama. En consola vamos a construir ese "alguien" a mano para ver qué hay dentro.

Este es el punto de partida, en versión plegada (el contenido de las ramas viene después):

fun main() {
    val tareas = mutableListOf<String>()
    var salir = false

    while (!salir) {                                  // 1. el bucle que espera
        println("\n--- Agenda de tareas ---")
        println("1. Añadir tarea")
        println("2. Listar tareas")
        println("3. Eliminar tarea")
        println("4. Salir")
        print("Elige una opción: ")

        when (readLine()?.trim()) {                   // 2. punto de bloqueo  3. el bucle decide
            "1" -> { /* añadir tarea */ }
            "2" -> { /* listar tareas */ }
            "3" -> { /* eliminar tarea */ }
            "4" -> { salir = true; println("Hasta luego.") }  // 4. la única salida
            else -> println("Opción no reconocida.")
        }
    }
}

1. El bucle que espera. Mientras nadie elija «Salir», el programa vuelve a preguntar. Nadie le avisa de nada: es él quien pregunta, una y otra vez.
2. El punto de bloqueo. readLine() detiene el programa hasta que el usuario pulsa Intro. Es la única fuente de sucesos, y está enterrada dentro del bucle.
3. El bucle decide. El when compara un texto y elige la rama. La lógica de qué hacer vive dentro del propio bucle.
4. La única salida. Poner salir = true es lo único que rompe el ciclo: el programa termina cuando él mismo lo decide.

Ahora las ramas desplegadas:

"1" -> {
    print("Descripción de la tarea: ")
    val desc = readLine() ?: ""          // ¡vuelve a leer del teclado dentro de la reacción!
    tareas.add(desc)
    println("Tarea añadida.")
}
"2" -> {
    if (tareas.isEmpty()) println("No hay tareas.")
    else tareas.forEachIndexed { i, t -> println("$i: $t") }
}
"3" -> {
    print("Índice a eliminar: ")
    val idx = readLine()?.toIntOrNull()
    if (idx != null && idx in tareas.indices) {
        tareas.removeAt(idx)
        println("Tarea eliminada.")
    } else {
        println("Índice no válido.")
    }
}

Esto es lo que se ve en la consola de pde-consola tras dos vueltas del bucle:

--- Agenda de tareas ---
1. Añadir tarea
2. Listar tareas
3. Eliminar tarea
4. Salir
Elige una opción: 1
Descripción de la tarea: Estudiar eventos
Tarea añadida.

--- Agenda de tareas ---
1. Añadir tarea
2. Listar tareas
3. Eliminar tarea
4. Salir
Elige una opción: 2
0: Estudiar eventos

--- Agenda de tareas ---
...
Elige una opción: ▌

Tres observaciones:

• Lo que teclea el usuario es la única información que entra en el programa, y solo se lee cuando el programa lo pide, nunca antes.
• El menú se repinta en cada vuelta: es el programa quien lleva la iniciativa.
• El cursor parpadea: programa parado. Está bloqueado en readLine(). No hace nada más hasta que pulses Intro: ni cuenta el tiempo, ni escucha la red, ni lee un sensor.

Reescribimos el mismo programa separando cuatro piezas. El bucle deja de decidir y pasa a entregar:

Y alrededor, el bucle de eventos en main(), que solo pide un evento y lo entrega.

Antes de leer nada del teclado, definimos qué puede pasar:

// --- Evento: qué puede pasar, con los datos que necesite cada caso ---
sealed class EventoAgenda {
    data class AnadirTarea(val descripcion: String) : EventoAgenda()
    object ListarTareas : EventoAgenda()
    data class EliminarTarea(val indice: Int) : EventoAgenda()
    object Salir : EventoAgenda()
    object OpcionInvalida : EventoAgenda()
}

// --- Estado: lo único que persiste entre eventos ---
class EstadoAgenda {
    val tareas = mutableListOf<String>()
    var enMarcha = true
}

• Un tipo cerrado de sucesos: con sealed class solo existen estos cinco eventos. El compilador obliga al receptor a tratarlos todos en el when.
• El evento lleva sus datos: AnadirTarea transporta la descripción; EliminarTarea, el índice. Ya no hay que volver a preguntar dentro de la reacción.
• El estado, fuera del bucle: lo que cambia entre evento y evento. En Android será remember { mutableStateOf(...) } o un campo de la Activity.

Fíjate en que ListarTareas o Salir son object: no necesitan datos, basta con una única instancia. AnadirTarea y EliminarTarea son data class porque cada evento lleva información distinta.

La fuente: leerEvento()

// --- Fuente: traduce entrada bruta de teclado en un evento con significado ---
fun leerEvento(): EventoAgenda {
    println("\n--- Agenda de tareas ---")
    println("1. Añadir tarea")
    println("2. Listar tareas")
    println("3. Eliminar tarea")
    println("4. Salir")
    print("Elige una opción: ")
    return when (readLine()?.trim()) {
        "1" -> {
            print("Descripción de la tarea: ")
            EventoAgenda.AnadirTarea(readLine() ?: "")
        }
        "2" -> EventoAgenda.ListarTareas
        "3" -> {
            print("Índice a eliminar: ")
            EventoAgenda.EliminarTarea(readLine()?.toIntOrNull() ?: -1)
        }
        "4" -> EventoAgenda.Salir
        else -> EventoAgenda.OpcionInvalida
    }
}

• Sigue leyendo del teclado, pero es el único sitio del programa donde ocurre: todo readLine() vive aquí.
• Traduce, no ejecuta: pide los datos que el evento necesita y lo construye. No añade, no borra, no lista.
• Hasta el error es un evento: una opción desconocida se devuelve como OpcionInvalida y ya decidirá el receptor.

El receptor: manejar()

// --- Receptor: un manejador por tipo de evento ---
fun manejar(evento: EventoAgenda, estado: EstadoAgenda) {
    when (evento) {
        is EventoAgenda.AnadirTarea -> {
            estado.tareas.add(evento.descripcion)
            println("Tarea añadida.")
        }
        is EventoAgenda.ListarTareas -> {
            if (estado.tareas.isEmpty()) println("No hay tareas.")
            else estado.tareas.forEachIndexed { i, t -> println("$i: $t") }
        }
        is EventoAgenda.EliminarTarea -> {
            if (evento.indice in estado.tareas.indices) {
                estado.tareas.removeAt(evento.indice)
                println("Tarea eliminada.")
            } else {
                println("Índice no válido.")
            }
        }
        is EventoAgenda.Salir -> {
            estado.enMarcha = false
            println("Hasta luego.")
        }
        is EventoAgenda.OpcionInvalida -> println("Opción no reconocida.")
    }
}

• Un when sobre el tipo de evento: cinco eventos, cinco reacciones. Si olvidas uno, no compila.
• Solo toca el estado e imprime. No lee del teclado: los datos ya vienen dentro del evento (evento.indice ya está listo).
• Salir también es una reacción: no hay break ni return escondido; cambia enMarcha y el bucle terminará solo.

// --- Bucle de eventos: ya no decide QUÉ hacer,
//     solo obtiene un evento y lo entrega ---
fun main() {
    val estado = EstadoAgenda()
    while (estado.enMarcha) {
        val evento = leerEvento()   // pide un evento
        manejar(evento, estado)     // lo entrega
    }
}

Cuatro líneas que no saben nada de tareas:

1. Sigue habiendo un while. Estamos en consola: nadie nos avisa, así que alguien tiene que preguntar. Pero el bucle ya no contiene ni un solo "1", "2" o "3".
2. Pide un evento. La fuente se encarga de esperar y traducir.
3. Lo entrega. El receptor se encarga de reaccionar. main() no sabe qué significa ninguno de los eventos.

Hemos pasado de un bucle que decide a un bucle que entrega. Añadir una opción nueva ya no toca esta parte.

¿Y en pde-plantilla, dónde está este while?

No está en vuestro código. Vive dentro de Android: es el bucle de mensajes del hilo principal. Vosotros solo escribís los receptores.

Para cada trozo de código, decide a qué pieza de agendaeventos.kt pertenece: fuente, evento, receptor, estado o bucle.

Queremos una opción nueva, «5. Vaciar agenda», que borre todas las tareas.

En agenda.kt habría que meter una rama "5" -> { ... } en el when del bucle principal: el corazón del programa.

En agendaeventos.kt los cambios quedan repartidos así:

// Evento: un caso más
object VaciarAgenda : EventoAgenda()

// Fuente: una opción más en el menú y en la traducción
println("5. Vaciar agenda")
"5" -> EventoAgenda.VaciarAgenda

// Receptor: una reacción más
is EventoAgenda.VaciarAgenda -> {
    estado.tareas.clear()
    println("Agenda vaciada.")
}

// Bucle main(): ... ¡nada!

En un programa dirigido por eventos basta con añadir un evento y su receptor (y, en consola, enseñar a la fuente a producirlo). El bucle no se entera.

Predice la salida

Con la agenda vacía, el usuario teclea 3 y, cuando le piden el índice, escribe abc.

Sigue el evento: readLine()?.toIntOrNull() devuelve null → el operador ?: lo cambia por -1 → la fuente devuelve EliminarTarea(-1) → el receptor comprueba si -1 está en estado.tareas.indices…

Diez situaciones cotidianas, agrupadas en cinco familias: clic, timeout, mensaje recibido, sensor y cambio de datos. Para cada una hay que rellenar tres columnas:

Intenta resolver cada tarjeta antes de girarla:

En los pasos siguientes repasaremos las diez situaciones con las respuestas del profesor, de dos en dos o de cuatro en cuatro, y nos fijaremos en las trampas típicas: confundir la fuente con el canal, o el evento con el dispositivo que lo produce.

Qué aprender de estas cuatro:

• En los clics la fuente no es solo "el usuario": hay una pieza que capta el suceso (navegador, controlador del ratón, SO). En el doble clic, además, alguien tiene que reconocer el patrón de dos clics seguidos.
• En los timeouts no hay ninguna persona: la fuente es un temporizador. El evento es justamente que no ha pasado nada durante un plazo.

Qué aprender de estas dos:

• En la 05, desde el punto de vista del móvil, la fuente inmediata es el servidor de mensajería que empuja la notificación. Tu amigo escribió el mensaje, pero el suceso que llega al dispositivo lo origina el servidor.
• En la 06 aparece una trampa clásica: la cola no es la fuente. Kafka o RabbitMQ son el canal por el que viaja la notificación. Quien origina el suceso es el servicio de pagos, que publica; quien reacciona es el consumidor suscrito.

Qué aprender de estas dos:

• Aquí la fuente es hardware. Conecta con la lección 1: estímulo físico → detección (polling o interrupción) → driver/controlador → evento software → reacción. En la 07 la respuesta menciona explícitamente "el sensor y su controlador".
• El evento no es "el sensor", sino lo que ha cambiado y con qué datos: la nueva orientación, o el valor de temperatura que ha superado el umbral.
• En la 08 el evento no es cada lectura, sino un suceso con significado: cruzar el umbral. Alguien ha convertido muchas medidas en un único evento relevante.

Qué aprender de estas dos:

• En la 09 un único evento tiene muchos receptores: el listener de cada cliente conectado. La fuente es doble: quien edita y el servidor que propaga.
• La 10 es la más sutil: la fuente es tu propio código. El clic provocó un cambio de estado, y ese cambio de estado es a su vez un evento que escucha otra parte de la interfaz. Un evento produce otro.

Tras pasar por pde-plantilla, pde-consola y la vida real, aparece siempre lo mismo:

Misma estructura en los tres: fuente → evento → receptor. Solo cambia dónde vive el bucle que busca el siguiente suceso y quién repinta la pantalla.

¿Quién escribió el receptor?

Repasa las situaciones con esta pregunta: