Android App Architecture: State, ViewModel and Data Layers

Separate the screen from data access

The UI presents the current state and accepts events such as Add, Complete or Retry. Data access belongs behind a clear boundary rather than scattered across click handlers. For a small project, draw the path from the user event to the stored record and back to the visible list. If you cannot explain that path, another abstraction is unlikely to solve the confusion.

Define screen states before choosing classes

List the states the user can encounter: loading, content, an empty collection and a recoverable error. Include the selected filter and any unsaved input only where needed. Keep a clear owner for each value. Updating the database and refreshing the screen should follow an intentional path, rather than relying on several unrelated mutable copies.

Understand ViewModel limits

A ViewModel can hold screen-related state across configuration changes, but it is not permanent storage and does not itself preserve everything after process death. Decide separately what needs saved-state support and what belongs in persistent storage. Test the interruption that matters to the feature instead of assuming one successful rotation covers every case.

Keep repositories focused

A repository provides a boundary for a type of app data and coordinates its sources. A task repository might read local records and apply updates while the screen reacts to the result. Add a separate domain layer when shared or complex rules justify it. The official Android architecture guide describes these responsibilities; the smallest clear design is a sensible starting point.

Compose changes UI expression, not data ownership

Compose describes UI from state. It still needs sensible ownership, event handling and lifecycle-aware work. A remembered value is not a general-purpose database. Review the Compose state guidance and distinguish recomposition from activity recreation and process recreation. Existing View-based apps need the same clear decisions even though their UI code differs.

Investigate stale data with a trace

Suppose a completed task remains visible after an update. Check whether the event ran, the repository saved the intended record, the updated result reached the state owner and the UI observed it. Keep the record identifier in the reproduction notes. Changing several layers at once can hide the original cause and create a second defect.

Review the design through tests

Exercise an empty result, failed load, repeated action and relevant interruption. Keep logic checks separate from full-device interaction checks where practical. Document the responsibilities and known recovery limits in the README. Continue with the Android learning roadmap or use the project checklist to apply the design to a small app.