Adopting Jetpack Compose Safely
summary
A year and a half of incremental work converts a large app to Jetpack Compose by first unspaghetti-ing viewmodels into a single-state holder (exposed as an observable backed by a BehaviorSubject), adding a public triggerViewEvent API, and providing base activities/fragments that host composables; Gradle is standardized with convention plugins and the Compose BOM plus a version catalog; the Octopus design system becomes Compose-first, views interop remains for compatibility, new features land in Compose, and team velocity and developer happiness measurably improve.
AI-written summary · about
chapters (13)
- 0:00Introduction to Compose adoption
- 1:08Why switch to Jetpack Compose
- 3:13Legacy architecture challenges
- 7:24Preparing the architecture for Compose
- 9:32Redesigning ViewModel for Compose
- 12:02Handling UI events in ViewModel
- 15:59Creating Compose-ready base classes
- 19:29Gradle setup for Compose modules
- 21:37Migrating the design system to Compose
- 26:50Compose-first design system approach
- 29:17Training team on Compose
- 33:12Key takeaways and next steps
- 36:21Q&A and closing
related talks
39mThe journey of adopting Jetpack Compose in Babbel’s App
01h 08mAdopting Jetpack Compose @ Scale
33mMigrating to Jetpack Compose - an interop love story
17mWhat's new in Jetpack Compose
38mFrom Android View to Jetpack Compose — A Guide to Migrating to Jetpack Compose
34mRetrofitting Legacy Code with Jetpack Compose at Scale
25mWhat can we learn from Jetpack Compose?
19mJumping into Jetpack Compose way too early to see what's inside