Architecting Android App For Scale

This article talks about brief summary of how we architected our new Android Application for a larger scale of audiences, what are the challenges we faced before and how we won them.

“Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimise the lifetime cost of the system and to maximise programmer productivity.”
― Robert C. Martin, Clean Architecture

Challenges:

1. Company business expanded to different countries, so it will be crucial for every current app, to accommodate all those country related changes, for eg. Currency, timings and business related changes, also features availability as per the countries.
2. Legacy code, old App architecture and design was not scalable for such a radical changes in current features. It will be difficult for anyone to make a change while maintaining its current features. Hence, it will be costly in terms of development hours to make changes.
3. We wanted to adopt new design guidelines and lot of new things on technical side to make app more reactive & faster to deliver seamless experience to the user.
4. Our backend services has upgraded to accommodate bigger changes.
5. Because of fetch once show any time structure used, we were not able to deliver deeplink and smart link kind of features to target and convert more prospective users into sales funnels.
6. We have multiple apps which has almost similar backend services and business logic. It was difficult to comprise same changes in different Apps, also it is more time consuming process.

Old Application Architecture

For example:
App X, Y & Z has same business logic and also uses almost same backend services with little change in request.
As similar business logic and backend services were distributed among different projects, it was difficult for anyone to make same changes in all Apps at same time.

Solutions:

So the elephant in the room was to decide, whether to go with the same app or start new app from scratch.
We listed down following advantages of new application:

1. Backend and business logic will be shared among the different Applications, hence it will be more easy to make country specific changes in all applications with the minimal changes.
2. It will be comprised of latest Android architecture components & guidelines, with latest technologies and design principles.
3. We can have single and small API for single screen while reducing inter dependancies, which will be used efficiently for deeplink purpose, also it will make page loading more faster.

New Application Architecture

For example:
New project is divided into ‘Library Module’ and ‘Application Modules’.
Library module contains all common business and backend logic, which will accept request with small changes, and provide desired results with the minimal changes & application module will be consist of UI logic.

In a room full of top software designers, if two agree on the same thing, that’s a majority.
— Bill Curtis

So we made an unambiguous decision to go for the new app while considering all these benefits.

MVVM (Model-View-ViewModel) Architectural pattern:

“The perfect kind of architecture decision is the one which never has to be made”
― Robert C. Martin

Now it’s our time, to decide an architectural style for our new application. While there are many different architectural approaches available these days like MVP, MVI, etc, we decided to go for ‘MVVM with Clean Architecture pattern’ because it provides ‘low coupling and high cohesion for classes’.

Clean Architecture: The dependency rule is the overriding rule that makes Clean Architecture work. It says that nothing in an inner circle should depend on anything in an outer circle. In particular, application and business rules shouldn’t depend on the UI, database, presenters, and so on. These rules allow us to build systems that are simpler to maintain, as changes in outer circles won’t impact inner ones.

MVVM Architecture

In our project, App modules are comprise of ‘View + View-Model’ and Library module is made up of ‘Model’ part.

As a part of Clean architecture, we made sure that none of the layers will be dependent on previous layer using ‘Android Architecture Components’.

App Module:

It contains all UI and data display related logic, which makes Android UI and related components separated at one place from other entities.

Library Module:

It contains Model part of MVVM pattern. In this we created different modules, like Store management, Product Management, User and Login Management, Cart and Order management etc.

Here, every module has its manager like StoreManager, ProductManager etc. Only These module managers are accessible from ViewModel, so its job is to provide the requested data from respective data sources, such as Database, Cloud Storage or Shared Preferences.

Each module manager only can talk with its respective data storage managers.
For eg. ‘StoreManager’ will talk with ‘StoreApiManager’ for fetching data from server or will talk with ‘StoreDbManager’ to read or write data to the database.

Library Module

While this Architecture has helped us to make solve many business requirements like deeplink, Country expansions etc, it also has made app development more modular and smoother for developers.

“If you think good architecture is expensive, try bad architecture.”
— Brian Foote and Joseph Yoder

Next we will talk about, how these classes in ‘Library Module’ communicates with each other.