Migrating to a Single-Activity Architecture in a Modular App
summary
Migration reduces a 60+ activity monolith to a small set of hosts using Android Navigation: teams convert flows into nav graphs, merge 60→~12 then replace many with subnavigation activity with dynamic nav graph IDs and a composable subnavigation activity, use Hilt and a GraphFactory interfaces in shared module to avoid cyclic deps, scope shared ViewModels to navGraphs, fix a navigateUp deep‑link relaunch bug by overriding behavior, and deliver faster builds and steadier releases over one year.
AI-written summary · about
chapters (15)
- 0:00Single-activity architecture intro
- 3:13Why migrate to single activity
- 8:52Ownership mindset and tech debt
- 13:05Chain of pearls strategy
- 15:58Merging activities into nav graphs
- 18:07Subnavigation activity for modular flows
- 21:18Cyclic dependencies with shared interfaces
- 22:45Adopting Jetpack Compose
- 24:50Composable subnavigation activity
- 26:58Back stack challenges and fixes
- 30:51Shared ViewModels benefits
- 33:20Key takeaways from migration
- 34:46Communication during tech changes
- 36:11Adaptability and automation
- 37:35Q&A
related talks
42mRoad to Single Activity
39mSingle activity: Why, when, and how
46mModern Android: How to ditch Activities and Fragments
06m10 best practices for moving to a single activity
36mNavigation and the Single Activity: Learnings from a Skeptic
37mSingle Activity by Example
26mSingle activity navigation so simple even I can understand it
37mForging the path from monolith to multi-module app