Lectures

We break down how to move from direct calls to publishing facts: instead of “tugging your neighbours by the sleeve”, you learn to emit an event and attach reactions via a list of listeners. Using the console project BudgetBuddy as an example, we build a “one → many” model, discuss why an event is a fact rather than a command, and lock down the contract: payload, synchrony, call order, error handling, and subscription management. Finally, we cover typical mistakes and how to avoid them.

We break down a minimal event mechanism in Kotlin: what a listener is as a function of type (T) -> Unit, how to store subscribers in a MutableList, how subscribe and emit work, why the type parameter T matters, and what limitations the “simplest” implementation has (no unsubscribe, no exception handling, and no protection against modifying the list during dispatch).

Let’s break down why unsubscribing matters in events, why the “same” lambda is usually a different object, and how reference identity of functions works in Kotlin. We’ll implement Event<T>, where subscribe returns an unsubscribe token ( () -> Unit) via a closure, discuss duplicate subscriptions, and careful work with function references via ::.

We break down why a naive emit() over a “live” listener list breaks in real code, how to fix it with a snapshot ( listeners.toList()), why try/ catch must wrap each handler, and what reentrancy means (nested calls to emit()). At the end, we build a reliable Event<T>, integrate it into a mini expense tracker, and lock down the contract and common mistakes.

We break down how to use SharedFlow in Kotlin as an “event bus”: what’s the difference between MutableSharedFlow and SharedFlow, how subscription via collect works, and why “unsubscribing” is usually Job.cancel(). We also explain the role of the replay parameter (for example, replay = 1) for “late” subscribers and show how not to lose a subscription due to exceptions inside the handler.