Guide to Android App Architecture: Google's Recommendation and Best Practices

 

Opening Note!

Among numerous discussions and debates on the Internet these days about the suitable architecture to follow and adapt, Google recently published a detailed blog to follow best practices while we are articulating the Android App. App architecture defines the backbone of scalable, maintainable, and high-performance Android apps. In this article, I am trying to curate the key principles from Google’s official guide, ideal for an app architecture. The purpose of this article is to clarify architectural patterns and highlight universal best practices.

Resources referenced:

Common factors to design architecture

1. Tackle various config changes

  • An Android App must run on a wide variety of available devices in the global market i.e., phones, tablets, foldables, and various orientations.
  • Configuration changes like screen rotation, recreate activities. We must use ViewModels to preserve UI state and make sure to provide a smooth experience to users.
  • Hardcoding the dimensions while designing UI must be avoided to ensure responsive UI using responsive layouts and adaptive containers.

2. Android App’s Resource Constraints and Process Death

  • Android devices have limitations in consideration of resource availability, and it may terminate App Processes in the background.
  • In case of process death, if we are not handing the app’s state properly, we will have to compromise with the current app state, it’ll be lost. 
  • One very popular mechanism available SavedStateHandle in ViewModels to recover UI state and maintain user experience after unexpected process terminations.

3. Design for Variable Launch Conditions

  • There are multiple ways, an app can be launched, when user tap on the launcher icon, via deeplink (form some web page or another app), or automatically when baclgroundn services starts it. 
  • Because of above behaviour, Android App’s basic components like Activity, Service, Receiver, and Provider may be created or destroyed anytime in any order by the Operating System.
  • So, we should not keep any important data in Activity or Service variables, because we might loose it if the OS kills or restarts them. Instead, we can save and restore data properly using a rob app architecture like ViewModel, Repository, or persistent storage.

Layers of Separation: Structural Foundations

1. Separation of Concerns

This means we must be dividing our app into clear modules, so each module will hold its own specific responsibilities.

  • UI Layer: It must only handleswhat the user visualizes on screen — like the buttons, text, and visuals. It also keeps short-term UI state (like if a button is selected).
  • Domain Layer (Optional): It must hold the main app logic, usecases basically. It fills the gap between the User’s expectation from the app and the way the app works.
  • Data Layer: It must handle the fetching and saving information — from various resources like the Internet (APIs), local databases, system services, or sensors.

Benefits:

  • Clarity: Each class/function has a distinct home.
  • Isolation: Bugs remain contained within their respective layer.
  • Testing: Enables fast unit testing of business logic, minimal UI tests for rendering.

2. Single Source of Truth

  • Each and every important piece of data in our app should be driven from only one source, which helps to avoid confusion and data mismatch. 
  • For example, UI will be rendered taking the data from only the Database, not from the API source directly. 
  • We should not be keeping multiple copies of the same data set at different places; instead, we should have only one clear source.

3. Unidirectional Data Flow (UDF)

In this pattern, data flows in only one direction, which makes the app’s flow clear and predictable.

  • User actions or events (like clicking a button or typing text) start from the UI and move to the ViewModel.
  • The ViewModel updates the data and sends the new state back to the UI.

Because of this one-way flow, the UI only shows what the current state is — it doesn’t change data on its own.
This makes the app easier to understand, test, and debug. Architectural Patterns: Clean vs. Google-Recommended.                                

  • Clean Architecture keeps business logic isolated, enabling faster changes to data sources without affecting core logic.
  • Google’s recommended structure is pragmatic, suitable for small to medium projects.
  • For apps expected to scale past 100k lines or for teams >5, use a distinct Domain Layer.

Data Models: Driving UI and Persisting State

  • UI should reflect persistent models (local DB, API, Preferences) but not every fleeting state needs full persistence.
  • For temporary UI states (e.g., dialog visibility), use ViewModel’s SavedStateHandle instead of local DB.

Events, Actions, and State: Clarity in Communication

  • State: Persistent values (e.g., isLoading, data).
  • Actions: UI → ViewModel communications (button clicks, text changes).
  • Events: One-time ViewModel → UI notifications (navigations, error snackbars).
  • Not all UI events should become persistent state — avoid repeatable actions (e.g., error snackbar after screen rotation).

If you have reached till here, hoping you found this blog useful 🙌🏻. Kindly share your valuable feedback/suggestions with me on below links.

EmailId: vikasacsoni9211@gmail.com

LinkedIn: https://www.linkedin.com/in/vikas-soni-052013160/

Happy Learning ❤️

Comments

Post a Comment

Popular posts from this blog

Optimize Jetpack Compose: Performance & Best Practices

Image
      Jetpack Compose offers a declarative approach to building UIs in Android. However, like any UI framework, optimization is key to achieving smooth performance and a great user experience. This detailed guide expands on the provided checklist, offering in-depth explanations and practical code examples for each optimization technique. I. Core Principles: Laying the Foundation for Performance Use Stable Types:  Compose relies on stable types to efficiently track changes and minimize recompositions. A stable type guarantees that if two instances of the type are equal according to  equals() , they will always be equal. Using unstable types can force unnecessary recompositions.   // Stable data class (recommended) data   class   User ( val  name: String,  val  age:  Int ) // Unstable list (avoid directly in Compose state) // Use SnapshotStateList instead val users = remember { mutableStateListOf<User>() } // Cor...
Read more

From ‘Master’ to ‘Main’: The Meaning Behind Git’s Naming Shift

Image
                             Git changed its default branch name from master to main due to concerns about inclusivity and to remove references to terms with problematic historical connotations. The term master has been associated with slavery, and many tech communities sought to use more neutral and inclusive language. Reason for the Change: Inclusivity & Sensitivity- Many organizations aimed to remove racially charged terminology from software development. Consistency Across Communities- Other projects and platforms, such as Github, Gitlab, and software frameworks, also made similar changes. Modern Naming Conventions- main is a cleaner and more intuitive name, as it represents the primary branch of a repository. Interesting Facts —  It wasn’t originally about slavery  — The term Git did not originate from the master/slave concept used in computing. It likely came from Bitkeeper , a version contro...
Read more

Play Store Uploads with Fastlane Supply - 4

Image
If you’ve ever manually uploaded an APK or AAB to the Google Play Store, you know it can be a tedious process. From filling out all the necessary metadata to selecting the correct APK version, it can feel like a lot of repetitive work. But with Fastlane Supply , you can automate this entire process — making your app releases smoother, faster, and error-free. In this section, we’ll explore how Fastlane Supply works and how to set it up to upload your Android app directly to the Play Store with ease. Step 1: Set Up Google Play API Access Before you can upload your app with Fastlane Supply , you need to set up Google Play API access . This ensures that Fastlane can communicate with the Play Store and upload your APK or AAB. Here’s how you can set up API access: Create a Google Cloud project : Go to the Google Cloud Console. Create a new project. Enable the Google Play Developer API : In the Cloud Console, search for and enable the Google Play Developer API . Create a service account ...
Read more