Modularization Flashcards
BUILD & TOOLING › Gradle
- What is modularization in Android and what two properties define a good module?
- Organizing a codebase into separate Gradle modules. A good module has high cohesion (related code, one clear responsibility) and low coupling (independent, minimal knowledge of others).
- Name the main module types in a modular Android app and their roles.
- app (entry point, root navigation, provides DI implementations), feature (UI + ViewModel for a screen/destination), data (repositories, data sources, models), core/common (shared UI, network, analytics, utils), and test modules.
- What is the correct dependency direction, and what is the key forbidden dependency?
- app depends on features; features depend on data and core; data depends on core. Features must NOT depend on other features, and dependencies must never be cyclic.
- Difference between Gradle api and implementation, and which to prefer?
- implementation hides the transitive dependency from consumers; api exposes it transitively. Prefer implementation: it shrinks the public surface and avoids recompiling dependents when internals change. Use api only when consumers must reference the dependency's types directly.
- How should two feature modules communicate without depending on each other?
- Via a mediator (usually the app module) or a shared data module. Pass primitive IDs through navigation, then each feature loads the full object from the shared data module, keeping a single source of truth and low coupling.
- How does navigation work across modules in a modular app?
- The app module owns root navigation; features expose destinations and receive only primitive arguments (e.g. an ID), not domain objects. The ViewModel reads the ID from SavedStateHandle and fetches data from a shared module.
- How is Hilt dependency injection typically split across modules?
- Feature/data modules declare what they need and define interfaces; the app module wires the concrete implementations, often per build variant (e.g. debugImplementation vs releaseImplementation, or a mock for androidTest).
- What is dependency inversion in a modular Android project and why use it?
- High-level modules depend on an abstraction module (interfaces + models), not on a concrete implementation module. It enables swapping implementations, easier mocking in tests, and avoids recompiling consumers when an implementation changes.
- What are the downsides of over-modularizing, and when is modularization not worth it?
- Too many fine-grained modules add build configuration overhead and boilerplate; too few recreate a monolith. For small codebases that won't grow much, the overhead can outweigh the benefits.