original image by Clément Falize

Scalable Architecture For Big Mobile Projects

Today we will talk about architectural decisions that are more complex and global than the architecture of the presentation layer (like MVP, MVVM, MVI, etc). We will talk about how to build an extensive application and make this an efficient workplace for dozens or hundreds of developers. With these techniques, your application will be able to scale to any size regardless of how much code you’ve written.

Principles for Scalable Large Project

First of all, let’s define the principles that we are going to have to develop a large application.

1. Reduction in dependencies. Any changes should affect as little code as possible.
2. Reusability of code. It should be easy for a developer to reuse some parts of code without copy-paste.
3. Scalability. It should be easy for a developer to add new functionality for existing code.
4. Stability. We need to have a possibility to disabled some block of code using feature toggles. This can save us if we need to disable outdated features for some old app version or avoid bugs and crashes in the new one, especially if we’ve decided to use a trunk-based development approach on the project.
5. Responsibility. The project should be decomposed into modules. In that case, we will be able to assign a code owner for each particular module. It will help us to deal with a code review. And this point can be applied not only to big parts of the application as Gradle or Pod modules but also for regular features that might have different owners.

Component

Here is a typical profile screen. Usually, we take some presentation layer architecture (the ones starting with MV) and create Presenter/ViewModel/Interactor/Something classes for the screen.

This technique is okay for small teams, but when our team starts growing, this clear architecture becomes a source of mess.
For example, my team experienced trouble when it has grown dramatically. Developers started to write code; everyone changed the same classes and affect each other. The whole team experienced problems with merging branches. Some business logic becomes broken as a side effect of not directly related changes. We had to rewrite and update our unit-tests so frequently.

The other thing is the more complex the screen, the more events are emitted by a user (i.e., taps, search, swipes) and the system (i.e., loading, updates, notifications). At some point in time, there are so many events on the screen. And in this situation, it isn’t easy to understand what is happening on the screen right now and how the screen looks. It’s hard to show the correct UI state, keeping in mind all possible things that might occur on the screen.

To solve this, we can make a new rule. Each screen should be decomposed into small parts — components. Every component should contain a minimum amount of code and be as isolated from the others as much as possible.

Component Requirements

1. Sole responsibility. One component should represent only one business object.
2. Simple implementation. The component should contain as little code as possible.
3. Independence. The component should not have to know anything about the other components on the app and the screen.
4. Anonymous communications. All communications among components should be organized via a dedicated entity, which in turn observes incoming events from components and knows nothing about which component sent an event.
5. Determined UI state. Keeping the UI state will help us to restore the screen state and clearly understand what the app shows to the user at any point in time.
6. Unidirectional data flow. The component state should be uniquely defined and immutable. It also means that our app will use one-way binding data flow and have a single point of truth that is only able to change the state.
7. Configurable remotely. It should be possible to configure components from the server. At least, make it possible to deactivate a component at any point in time using feature toggles. For example, the business could decide not to show a price component anymore.

How Components Work

1. The component receives data (i.e., DomainObject or “External State”) from an external source (let’s call it a Service).
2. The application applies the component’s business logic to input data, and we make a new UI State.
3. Then, the application shows this brand new UI state to the user.
4. If the user interacts with the component (they tap on a button, swipe, etc.), we create a new Action. This Action will be provided to the entity responsible for the business logic of the component.
5. The business logic will decide whether it should make a new UI state immediately or pass the Action to some Service.
6. The other components can observe the data from Service and update it accordingly (point #1).

Screen Architecture

As we defined before, components on the same screen know nothing about each other, but they can send Actions to common entities called Services. Components, in turn, observe data changes from Services.

There can be two types of Services:

• Global Services which we use for the whole app (e.g. UserService, PaymentsService, CartService)
• Local Services that we use only for a single screen (e.g. ProductDetailsService, OrderListService)

To be fair with you, I also have to mention that you can use any presentation layer architecture you like (MVP/MVC/MVVM/MVI or something else entirely) on your components project. At the same time, you should keep in mind that each component has to satisfy the requirements mentioned above.

State Machine

The architecture of such a screen inherently is a state machine, which receives Actions (events) from UI and internal app Services. Based on input data, it creates Data State. Components, in turn, process this Data State and show results on the UI.

So, let’s define new entities:

• Middleware — this is where the business logic goes. Middleware processes incoming Actions and produces a new state. It can also create a new Action to communicate with the other Middlewares or external entities.
• Reducer — this entity gets the current state and merges it with the new one which it received from Middleware. Then, the Reducer sends the merged state for all of the subscribers.

Depending on the approach that you decided to use, you can use one Middleware or Reducer for the whole application or a screen, or each business entity can have its own Middleware and Reducer.

You can find more details regarding this approach in these places: Flux, Redux, MVI

BTW, for components you may also use the same structure to make the whole app consistent:

Server-Driven UI

As long as we have autonomous components where we can feed some input data (DomainObject) to be displayed on the UI, we can receive a list of these components from a server and configure screen structure dynamically. The main advantage of this approach is the possibility to change content on a screen dynamically without uploading a new application version to Play Store or App Store. The marketing team will be so glad to hear it!

We will receive a list of components from the server. Each component will have information about the position on the screen and the required data for work.

Here is an example of a response:

Conclusion

• Decompose your solid screen to small components responsible for one business object.
• Use rules (mentioned in the article) to make these components robust.
• Use parent objects (Services in our case) for communication among components.
• Unidirectional data flow and Single Point of Truths make your app more stable. It will also save time during bug fixing and debugging.
• Code owners assigned to a particular component or feature will make your codebase more sustainable and with a better quality of code.

Questions?

I’ve participated in the development of massive projects using this architectural approach. And I’m open to your questions regarding architecture itself and some technical details on how we implemented it for the Android app.