Building Reactive Component Systems with Kotlin
Article Summary
Zsolt Kocsi from Bumble reveals how his team tamed the chaos of reactive Android components. The secret? Two minimal interfaces and a powerful abstraction that makes subscription management disappear.
This is part two of Bumble's deep dive into their MVICore architecture. Kocsi tackles a critical challenge: as reactive components multiply in your codebase, how do you manage the explosion of subscriptions and lifecycles without drowning in boilerplate?
Key Takeaways
- Built system on just two RxJava interfaces: ObservableSource<T> and Consumer<T>
- Binder class auto-manages subscriptions across Android lifecycles (create/destroy, start/stop)
- Custom lifecycles work beyond Android: dialog display, async operations, DI scopes
- Binding code reads like sentences, providing high-level system overview
- Subscriptions automatically re-subscribe and dispose across multiple lifecycle cycles
By abstracting subscription management into a Binder with flexible lifecycle support, Bumble's team separated the concern of connecting components from managing their lifecycles, resulting in concise, readable reactive systems.
About This Article
Badoo's reactive codebase had grown messy with observables and subscriptions scattered across many levels. This made it hard to manage lifecycles and dispose of subscriptions properly as Android components went through their start, stop, resume, and pause cycles.
Zsolt Kocsi's team built a Binder class that takes care of subscriptions automatically. It maps lifecycle events like BEGIN and END signals to subscription state, so developers don't have to manually dispose of subscriptions anymore.
The Binder lets developers write reactive component connections in just a few lines of code that are easy to read. As the number of components grows, this high-level overview becomes increasingly valuable.