Android Architecture series · Part 1 of 10
Android Architecture for First-Timers: Why It Matters
Architecture sounds scary, but the idea is small: decide where code lives so a team can keep shipping for years. This first part explains the goals and gives you one simple picture that the rest of the series reuses.
- Goal: one consistent architecture for faster delivery with quality.
- Also: easy change, low onboarding cost, scalable team and features.
- Template: View, Logic, Data. Every named architecture is a variation.
- Choice: there is no winner; adopt the benefits, not the label.
Contents
1. Why do we need an architecture at all?
Imagine your first Android app. One screen, one Activity. You put the button click, the network call, the JSON parsing and the list update all in the same file. It works, and it ships fast. Six months later there are 40 screens, 6 developers, and a 3,000-line MainActivity that nobody dares to touch.
Think of a restaurant kitchen. In a tiny food stall, one person takes orders, cooks and washes dishes. In a restaurant that serves 500 people, you need stations: someone takes orders, someone cooks, someone stores ingredients. Each station has clear jobs and clear hand-offs. Software architecture is the same idea: who does what, and who is allowed to talk to whom.
An architecture is not a library you install. It is an agreement inside the team about where code lives. A good agreement gives you these benefits:
| Goal | What it means in plain words |
|---|---|
| One consistent architecture | Every screen is built the same way, so the team delivers faster with quality. Nobody reinvents the structure for each feature. |
| Evolutionary change | The design supports change in the future. You can swap a database, a network library or a UI toolkit without rewriting the app. |
| Less onboarding cost | A new teammate learns the pattern once and can then read any screen. |
| Easy to change and maintain | A bug or a new rule touches one small place, not twenty files. |
| Scalable team size | Five people can work in parallel without constant merge conflicts, because they own different pieces. |
| Scalable feature size | Feature number 100 costs about the same to add as feature number 10. |
| Modularity, cohesion, readability, testability | Small pieces (modular), each doing one related job (cohesive), easy to read, and easy to check with automated tests (testable). |
Architecture is a tool to deliver faster with good quality for a long time. If a rule does not help one of the goals above, question it.
2. The common template: View, Logic, Data
Here is the secret that makes this whole series simple: almost every Android architecture is the same three boxes with different names. Google’s own Guide to app architecture describes the same idea as a UI layer, an optional domain layer and a data layer.
When people say M, V and P (or M, V and VM), they usually mean:
- M = Model = the data layer. Data classes, protobuf messages, repositories, the database, remote API calls and caches.
- V = View = the UI layer.
Activity,Fragment, adapters, dialogs, XML layouts, Compose functions, and a ViewProxy (a small wrapper around a view; you will meet it in Part 2). - P (or VM, or Interactor) = the logic layer. The code that decides what should happen: validate the input, ask the data layer, turn the result into something the view can show.
Rule of the three boxes: the View never talks to the database or the network. The Data layer never knows that a screen exists. All decisions live in the middle box.
3. The menu of options
There is no single winner. The popular choices over the years:
| Name | Stands for | One-line idea |
|---|---|---|
| MVC | Model View Controller | The original. A controller connects the view and the model. On Android the Activity often becomes both view and controller. (In older notes this is sometimes written “MCP (old)”; the classic old one is MVC.) |
| MVP | Model View Presenter | A presenter holds the logic and tells the view what to show through an interface. |
| MVVM | Model View ViewModel | A ViewModel exposes state; the view observes it. Google’s recommended direction. |
| VIPER | View Interactor Presenter Entity Router | Five small roles, each with one job, including a Router for navigation. |
| Redux / MVI | View Action Store State Reducer | One state object, changed only by actions through a reducer. Data flows in one direction. |
The list keeps changing over time, because every option has pros and cons and the platform itself moves (Jetpack, Kotlin, Compose). So do not hunt for the “perfect” name. Focus on adopting the maximum benefits: the goals in section 1.
4. Using it to clean up a big old codebase
These architectures are also a plan for revamping a large codebase. You do not rewrite everything. You move one screen at a time:
- Pick one screen. Extract its data access into a repository (section 3 box).
- Move its decisions out of the
Activityinto a presenter or ViewModel. - Leave the
Activityas a thin view. - Repeat for the next screen. Old and new screens live together until the old ones are gone.
Along the way you apply SOLID, the Repository pattern, dependency injection and other design patterns that Part 2 and Part 6 explain. Clean code is the by-product, not a separate project.
5. What this series covers
- Why architecture (this part).
- Principles and patterns: SOLID, KISS, DRY, Proxy, Scheduler, Repository.
- MVC and MVP, with ViewProxy.
- MVVM and Redux (MVI).
- VIPER and splitting into modules.
- Plumbing: dependency injection, coroutines and Rx, lifecycle, errors.
- Data and config changes: Room, Retrofit, gRPC, microservices, rotation, language, font and screen size.
- Testing (TDD) and the proof that all of these are secretly the same thing.
- Converting between architectures: step-by-step recipes, code and diagrams for moving from any one to any other.