Introducing Trio | Part II
Article Summary
Airbnb's Android team just solved one of mobile architecture's hardest problems: navigation in massive, modularized apps. Their solution? Store navigation state right in the ViewModel.
In Part II of their Trio framework series, Airbnb engineers Eli Hart, Ben Schwab, and Yvonne Wong reveal how they built a Compose-based navigation system that works across 2000+ modules. This isn't your typical navigation library.
Key Takeaways
- Navigation stack lives in ViewModel State, enabling atomic updates with business logic
- Custom Router system with compile-time validation ensures type safety across modules
- ViewModels get Activity access via Flow to handle intents without leaking references
- Fragment interop allows gradual migration during years-long Compose transition
- KSP processor validates Router-to-Trio mappings at compile time preventing runtime errors
Airbnb's Trio framework treats navigation as state, making complex screen flows testable, type-safe, and perfectly suited for large modularized codebases.
About This Article
Airbnb's codebase has over 2000 modules, and feature modules that need to communicate without direct instantiation create circular dependency risks. This threatens build speeds and makes ownership boundaries unclear.
Trio's Router system uses Dagger multibinding with KSP compile-time validation. Feature modules connect through navigation modules with a 'nav' suffix, which decouples them and eliminates circular dependencies while keeping type safety intact.
The Router's createTrio function matches Arguments and Props types at compile time, preventing navigation errors at runtime. This lets large modularized applications handle cross-module screen transitions reliably.