Making a mountain out of a module
summary
A small Letterbox client with three screens (feed, film detail, actor detail) is built to test modularization, using feature-based domain/data/remote modules and a shared core. The app uses dynamic feature modules (install, on‑demand, conditional, instant) and finds Dagger Android incompatible with dynamic features so core Dagger or Koin and Dagger modules provide implementations; implementations stay internal, navigation is handled via a navigation library to avoid fragile class name strings, and model mapping is sometimes skipped to reduce boilerplate.
AI-written summary · about
chapters (15)
- 0:00Introduction to modularization
- 1:07Single module app overview
- 2:11Multi-module app approach
- 3:33Dynamic feature modules benefits
- 4:55Clean architecture explained
- 7:48Decoupling layers in architecture
- 9:33Data models in clean architecture
- 10:58Feature module structure
- 12:44Shared logic and base modules
- 13:47Navigation in dynamic features
- 15:10Design systems in modular apps
- 17:40Dependency injection strategies
- 21:09Reducing boilerplate in models
- 22:10Simplifying module structure
- 23:14Project outcomes and next steps
related talks
20mBreaking Down Modularization
32mBuild a modular Android app architecture
39mWhy we failed at modularizing our app. An honest retrospective.
29mForging the Dagger for the modern Android world
46mScalable multi-module architecture for Jetpack Compose apps
35mArchitecture for App Bundles
40mModularizing Android Applications
45mArchitecture for AppBundles