Лекції

Розбираємо, як перейти від прямих викликів до публікації фактів: замість «смикати сусідів за рукав» вчимося емітувати подію та підʼєднувати реакції через список слухачів. На прикладі консольного проєкту BudgetBuddy будуємо модель «один → багато», обговорюємо, чому подія — це факт, а не команда, і фіксуємо контракт: payload, синхронність, порядок виклику, оброблення помилок і керування підписками. Наприкінці — типові помилки та способи їх уникнути.

Розбираємо мінімальний подієвий механізм у Kotlin: хто такий слухач (функція типу (T) -> Unit), як зберігати підписників у MutableList, як улаштовані методи subscribe і emit, навіщо потрібен параметр типу T і які обмеження має «найпростіша» реалізація (без відписок, без обробки винятків і без захисту від модифікації списку під час розсилки).

Розбираємося, чому в подіях важлива відписка, чому «та сама» лямбда зазвичай є іншим об’єктом і як у Kotlin працює посилкова ідентичність функцій. Реалізуємо Event<T>, де subscribe повертає токен відписки ( () -> Unit) через замикання, обговоримо дублікати підписок і акуратну роботу з посиланнями на функції через ::.

Розбираємося, чому наївний emit() по «живому» списку слухачів ламається в реальному коді; як виправити це через snapshot ( listeners.toList()); чому try/ catch варто ставити навколо кожного обробника; і що означає реентерабельність (вкладені виклики emit()). Наприкінці збираємо надійний Event<T>, вбудовуємо його в мінітрекер витрат і фіксуємо контракт та типові помилки.

Розбираємося, як використовувати SharedFlow у Kotlin як «шину подій»: чим відрізняються MutableSharedFlow і SharedFlow, як улаштована підписка через collect і чому «відписка» зазвичай зводиться до Job.cancel(). Окремо пояснюємо роль параметра replay (наприклад, replay = 1) для «пізніх» підписників і показуємо, як не втратити підписку через винятки всередині обробника.