Designing Android Architecture So You Don't Rewrite Everything Later
Dieser Artikel ist bisher nur auf Englisch verfügbar.
Most Android rewrites don't happen because the original code was badly written line by line — they happen because a handful of early structural decisions made change expensive.
The decision that matters most: separate logic from UI
Business logic living directly inside an Activity, Fragment, or Composable is the single most common reason apps eventually need a costly rewrite — it becomes untestable in isolation and impossible to change without risking the UI, and vice versa.
You don't need to adopt a fully-realized architecture pattern on day one, but keeping logic in separate classes (a ViewModel, a repository, plain use-case classes) from the very start — even loosely — keeps the door open to formalizing that into MVVM or a similar pattern later, without a rewrite.
A minimal, defensible starting structure
ui/ — Activities, Fragments, Composables — display only
viewmodel/ — state holding, exposes what the UI needs
repository/ — data access (network, database), hides the source from the rest of the app
data/ — models, database entities, API response typesThis isn't a rigid framework — it's a minimum bar: UI code doesn't talk to a database or network API directly, it goes through a layer that can change independently.
Decisions that are genuinely hard to reverse later
- Database choice and schema design — migrating data models after real user data exists is meaningfully harder than designing them thoughtfully up front. See our Room vs SharedPreferences vs DataStore comparison for the actual trade-offs.
- Whether offline support is considered from the start — retrofitting offline-first behavior into an app built assuming constant connectivity is a substantial rework, not an incremental addition. See our offline-first guide.
- Navigation structure — a deeply nested, ad-hoc navigation setup becomes expensive to restructure once many screens depend on its current shape.
Decisions that are cheap to change later (don't over-engineer these)
- Specific UI component choices, styling systems, minor library swaps for things like image loading — these are usually contained enough to change without touching the rest of the app.
- Exact folder naming conventions — helpful for consistency, not architecturally load-bearing.
The practical takeaway
Spend your early design effort on the decisions that are expensive to reverse (logic/UI separation, data layer design, offline strategy) and consciously don't over-invest in the ones that are cheap to change later. Getting this balance backward — perfecting styling conventions while business logic lives directly in Activities — is a common and avoidable trap.
Starting a new Android project and want a second opinion on the architecture before writing much code? Get in touch — this is a cheap conversation to have early and an expensive mistake to fix late.
Häufige Fragen
Do I need MVVM for a small app?
Not necessarily on day one, but separating your UI from your business logic from the very start (even loosely) makes it dramatically easier to adopt a fuller pattern like MVVM later, versus retrofitting separation into tightly coupled code.
What's the single most expensive architectural mistake?
Putting business logic directly inside Activities/Fragments (or Composables) with no separation layer — this is the pattern that most reliably forces a rewrite once the app grows past a small size, because logic and UI become impossible to change independently.
Is Jetpack Compose relevant to this decision?
Yes — Compose makes UI and state management more explicit, which actually reinforces the case for separating business logic from UI from the start, since Compose's recomposition model punishes tightly coupled logic more visibly than the older View system did.