In this article, we will take a deep dive into the best architecture for Kotlin multi-platform mobile. In 2023, as Android developers, we will tend to adopt the MVVM architecture because it is simple, flexible and easy to test. As iOS developers, we may choose MVC, Viper and other architectures. In the Flutter world, BLoC (Business logic components) is a very popular architecture.
Kotlin multi-platform provides cross-platform development, enabling sharing of business and presentation logic in iOS, Android or desktop applications. Here, we further discuss which architecture should be followed and look for a suitable architecture for KMM.
What are we trying to achieve?
In terms of architecture, there is no clear matrix to decide which architecture should be adopted. In the KMM world, the architecture should be flexible enough to accommodate new changes to existing code and support multiple platforms in terms of testability and maintainability.
Simplicity is the key to a successful architecture. We will avoid cumbersome code and pursue simplicity.
Here are some key takeaways:
- Share code as much as possible, whether it is business logic or presentation logic.
- Minimize platform-specific code.
- Facilitates communication between local and shared logic.
- Flexible to accommodate future modifications.
- Follow SOLID principles.
BLoC Architecture
BLoC stands for Business Logic Component Based Architecture and is very popular in the Flutter world. Let's break it down into smaller parts and try to understand its matrix.
business logic component
In BLoC, a business logic component is a simple component that handles business logic. It involves responding to events by which changes to state are modified. To understand this, let's create a simple component and try to implement the business logic.
//GalleryComponent.kt
interface GalleryComponent {
val model: Model
fun onGalleryClick()
fun onDeleteClick()
data class Model(val isLoading: Boolean)
}
//GalleryFeature.kt
class GalleryFeature(): GalleryComponent {
override val model: Model get() = Model()
override fun onGalleryClick() {
//handle click here
}
override fun onDeleteClick() {
//handle click here
}
}
This is not a typical BLoC architecture, if you look closely at GalleryComponent.ktthe or these classes, you will find that the BLoC also involves state, events and consumer components and so on.
We want to keep it simple and not involve additional components that can be easily avoided in Kotlin multiplatform. ViewModel If you're familiar with the MVVM architecture, it's very similar to the MVVM architecture, substituting components for what's in the BLoC architecture .
The BLoC architecture also applies to the world of KMMs by observing its testability, flexibility, and simplicity.
In fact, BLoC poses usage challenges in KMM, since most developers come from the world of Android and iOS. They prefer to work on MVVM instead of adopting the new BLoC pattern, although its behavior is similar to MVVM. If you want to try the BLoC pattern, I recommend you not to use any complex architecture library, because it will be difficult to maintain the overall architecture.
MVI architecture
MVI（Model-View-Intent）Architecture uses intents to separate business logic from presentation logic. In MVI, intents are used to communicate with business logic.
Here, the intent is received from the view and the model is updated by responding to the intent. Under the hood, the price of MVI is the possibility of race conditions, because resolving some bugs caused by race conditions can be very complicated.
In a large codebase, maintaining a large number of intents can be complex. But I like the simplicity of MVI. Here, I've assumed that you're familiar with MVI, so we'll skip the examples and move on to the next step.
MVC or MVP architecture
MVC（Model-View-Controller）or MVP（Model View Presenter）architecture with the same behavior under the hood. In MVC or MVP, a controller or Presenter acts as an intermediary, making modifications to the model in response to events from the view. There is no doubt that MVC or MVP does a good job of separating business logic from presentation logic by using some kind of interactor.
But it will make the code more flexible for testing. But, at the same time, it brings the complexity of the interface and tight coupling between the view and the model. Especially in a large code base, maintaining a large number of interfaces can be very complicated. Ditto, I've already assumed you're familiar with these, so we'll skip the examples and move on to the next step.
MVVM architecture
MVVM（Model-View-ViewModel）The architecture separates business logic from presentation logic, eliminating tight coupling between components. In MVVM, the ViewModel acts as a bridge between the model and the view. It doesn't know anything about views and has no direct references to views.
The ViewModel modifies the model by responding to events from the view. If you're an Android developer, you'll be very familiar with MVVM. MVVM provides the architectural matrix any application needs to succeed. It brings the benefits of flexibility, scalability, and maintainability. But, again, in a large code base, it can be very difficult to maintain a lot of state inside the ViewModel.
Which architecture should be adopted?
As we all know, each architecture has its advantages and disadvantages. But in the end, we need to draw conclusions about which architecture the choice should follow.
To resolve this conflict, you should consider the following key points that will help you choose an architecture based on your needs. If you ask me for my opinion, I suggest considering MVVM architecture because it is simple and easy to understand.
- Is the architecture flexible enough to accommodate future modifications?
- Does the architecture support the application requirements?
- Does the architecture support testability and simplicity?
- Are architectural components open for reading but closed for external modification?
- Is it easy for the team to adopt the architecture?
- Is it a clean and pure architecture with no dependencies on third-party libraries?
Summarize
In Kotlin Multiplatform Mobile, there are various architectural libraries in the market to solve various problems in KMM. In 2023, Circuit architecture, BLoC architecture, Decompose architecture, etc. will be launched, and there are currently a large number of architecture libraries. But should we use these architectures?
An architecture should not depend on any architecture library which creates maintenance problems.
I'd rather consider a simple and clean MVVM architecture, which is easily extensible and open to future modifications, without relying on any other API or library.