Google Recommendation for Android Application Development Architecture

The article focuses on Google’s recommendation for android application development architecture and its advantages, the importance of clean code architecture, and how to build a high-quality Android application using clean architecture.

Selecting the right architecture for mobile application development is a tough job. Although there are so many different architectural and design patterns available for quality application development, each has its pros and cons.

If the developer doesn’t follow the right architecture, the application tends to become unmaintainable, unscalable, poorly integrated with other software, and also limits opportunities for improvement.  While with a clean architecture, developers can efficiently build robust, scalable, and

maintainable applications.

Users experiences

A typical Android project consists of more than one application running in the background with various application components. To function smoothly, applications must adapt to different types of user-driven workflows, as one request triggers another request to perform the desired task.

For example, when you want to share a photo on the WhatsApp application, it automatically triggers the camera app to take a photo or gallery application to choose the photos you want to share.

However, during the process, the user may be interrupted by a phone call or any notifications. But after handling the interrupts the user automatically returns to the previous process. Therefore it is important to handle such flows correctly for a better user experience.

Also, the operating system may kill some app processes to run high priority processes, resulting in loss of data or state of running application. To avoid this, app data and state shouldn’t be stored in the app component and all the app components must be kept independent.

Clean code architecture

Let us understand the concept of clean architecture.

It was first introduced in the year 2012 by Robert C. Martin colloquially called “Uncle Bob”. Clean architecture is the philosophy of software design that separates design components such as business logic, interface adapters, framework, and drivers into the ring levels and also conforms to the dependency rules to create a system that is maintainable, testable, and highly scalable.

Here the code dependency can only come from outer levels to inward. Also, the data formats must be kept separated among each level.

Clean code architecture principles

This principle demonstrates how one should build their app.

• Separation of concerns

The principle is based on separating the design components into different sections. For example, UI-based components should only contain the logic that handles the interaction between UI and Operating System.

To provide a smooth user experience, every module, class, or function in the application should not be dependent on another component. In short, all the components in the application should be loosely arranged to avoid degraded performance.

• Drive UI from model

The next important principle is to derive your UI from a model, preferably a persistent model. They are responsible for handling the data for an application. They are independent of the user interface components and the background app component and thus unaffected by the app’s lifecycle.

Popular architecture for Android application development

MVC(Model View Controller)

The Model View Controller is one of the most widely used architectural patterns used for application development. Each component of MVC has its unique responsibility.

• The Model is responsible for structuring the data it receives from the data controller.
• The View is responsible for the data presentation of the model in a particular format.
• The Controller is responsible for handling the user interactions. The controller receives the input from the user, validates it, and then passes the input to the model.

Technical implementation issues

The code layers are interdependent even if the MVC design is implemented correctly and there is no precise parameter to handle UI logic.

MVP(Model View Presenter)

MVP pattern constitutes three components – Model, View, and Presenter.

• The Model defines the data to be displayed upon in the user interface.
• The view is a passive interface that displays data and routes user commands to the presenter.
• The Presenter acts upon the model and the view. It retrieves data from the model and formats it for display in the view.

Technical implementation issues

The problem here is, the View and the Presenter often interact with each other and are therefore tightly connected components.

MVVM(Model-View-View-Model)

The problem in the MVP  is solved in the MVVM pattern. It facilitates the separation of UI (View) from the business logic for the simple application.

Google has recommended MVVM architecture with the encapsulated components for building robust, production-quality applications. According to Google, this recommendation is a good starting point for most situations and workflows.

Recommendation by Google: Components of  app architecture

The following figure represents how the models will interact with each other after an application is designed. In the figure, you can see that each component depends only on the component that is one layer below it.  

For example, activities and fragments depend only on a View model. The repository is the only class that depends on multiple other classes.

Source: developer. android.com

Such a design pattern is capable of providing better performance and a smoother user experience. This is because the user information is continuously updated by the repository module in the background so even if the network call fails, the user can resume the app and see the information that the app persists locally.

Basic components and toolsets of MVVM architecture

Jetpack

Jetpack is the toolset recommended by Google to build an Android application. It consists of libraries such as Live Data, ViewModel, DataBinding, Navigation Component, and Room.

UI Layer in MVVM

On the lowest level, there is Activity/Fragment, followed by ViewModel that exposes the LiveData class. Next to the View Model, we can find Repositories that utilize the Room library to store data locally.

View Model as a cache layer

Most of the time when the mobile screen is rotated, Activity/ Fragment is destroyed and recreated again. This problem is solved by the View Model.  View Model acts as a first cache layer and enables View to grab data from View Model without initiating any network calls.

Live Data(Lifecycle Aware)

Live Data is an observable data holder class. Live Data contains information on communication with the LifeCycleOwner, such as activities, fragments, and services. It only updates app component observers that are in the running lifecycle state.

When Views are updated, the View Model should not hold a direct reference to Views. Here the Live Data can be used to hold View information whenever it is destroyed. When the View is destroyed, it is removed from the observer’s array that prevents null pointer exceptions.

Repository as the data source

The repository is responsible for providing information to the View Model. It fetches the information from the remote data sources, then caches it locally and passes the same on the network whenever requested, rather than making frequent network calls.

Room

Jetpack recommends the Room library as it takes the responsibility for creating an SQLite table to retrieve and store data locally. It provides an abstraction layer between the SQLite database and the object data. With Room, it is easy to write clean code as it reflects errors on compile-time and not in run time which is difficult to track.

Network source

Google recommends the Retrofit library to fetch the data from the network. It simplifies downloading of JSON and XML data from the WEB APIs.

Network bound resource

Network bound resource is the implementation of the repository logic created by Google. The same logic is implemented by the Room library to cache data locally.

Advantages of Google recommended architecture

• Easy to fix life cycle bugs

View Model component helps to fix the majority of the configuration bug issues. In addition, the Live Data helps to solve the problem of null pointer exceptions by updating destroyed views.

• Separates Activities/ Fragment from business logic

View Model acts as a central component for fetching the information. It decouples Activities/Fragments from the business logic by shifting all the code from Activities/Fragment to the View Model.

• Test each component

One of the advantages of a clean architecture is testability. User interface and interactions can be tested by creating an Android UI instrumentation test using the Expresso library. View Model class and User Repository can be tested using the JUnit test.  Also, you can create a fake implementation for more complex test cases.

Clean Code architecture by DhiWise

If you are concerned about implementing a clean code architecture for your next project, DhiWise can be the best solution. DhiWise is a developer-centric platform designed for mobile and web application development.

DhiWise generates 100% clean code and saves your time and money in training for clean code architecture. It provides support for advanced technologies such as Node.js, MongoDB, Kotlin, and React.js (Coming soon). Among them, Kotlin is the most popular technology used by android developers.

DhiWise further provides support for  MVVM architecture with Kotlin(Recommended by Google for Android development) to fast-track the application development process while maintaining the code quality.

The clean code architecture(MVVM) and Kotlin technology allow you to build applications faster with the decoupled components in an organized manner. That way the code gets easier to understand, modify, manage and test.