How to choose Android architecture mode

1. Introduction

I have to sigh that the architecture of Android has evolved very fast in recent years. For example, the architecture that I have been exposed to in the past few years of work already has MVC, MVP, and MVVM. Just when I was about to apply MVVM to my own project, I found that Google quietly updated the developer documentation (Application Architecture Guide | Android Developers | Android Developers (google.cn)). This is an article that guides how to use MVI. So why was this article updated and what does it want to express? What is the Compose mentioned in it? Are the existing MVC, MVP, and MVVM not enough? What is the difference between MVI and these existing architectures?

Some people would say that no matter what architecture, it is all about " decoupling ". This statement is correct, but high coupling is only a phenomenon. What means can be used to reduce coupling? Is the program convenient for unit testing after reducing coupling? If I do decoupling based on MVC, MVP, and MVVM, can I do it thoroughly?

Let me tell you the answer first. MVC, MVP, and MVVM cannot achieve complete decoupling, but MVI+Compose can achieve complete decoupling, which is the focus of this article. This article combines specific code and cases to simplify complex problems, and combines many technical blogs to make a unified summary. I believe you will gain a lot after reading it.

The purpose of this article is to explain MVI+Compose in a simple and easy-to-understand way. You can first imagine such a business scenario. If it were you, which architecture would you choose?

Business scenario considerations

1. Log in using your phone number
2. After logging in, verify whether the specified account A
3. If it is account A, then click the like button

The above three steps are executed sequentially. Mobile phone number login, account verification, and likes are all performed after interacting with the server to obtain the corresponding return results before proceeding to the next step.

Before starting to introduce MVI+Compose, you need to proceed step by step and understand the shortcomings of each architectural model to understand why Google proposed MVI+Compose.

Before we officially start, let's take a look at how the architecture patterns have evolved according to when they were proposed. Each pattern is often not proposed based on Android, but evolved based on the server or front end, which also shows that the design ideas are similar:

2. Is the architectural model past tense?

2.1 MVC has been around for a long time

The MVC model was proposed too long ago, as early as 1978, so it must not be used for Android. Android's MVC architecture is mainly derived from the server-side SpringMVC. Between 2007 and 2017, MVC occupied a dominant position. The MVC architecture model we currently see in Android is as follows.

The meanings of these parts of the MVC architecture are as follows. You can find a lot of explanations on the Internet.

The MVC architecture is divided into the following parts

• [Model layer]: Mainly responsible for network requests, database processing, I/O operations, that is, the data source of the page
• [View layer]: corresponds to the XML layout file and the dynamic view part of the Java code
• [Controller]: Mainly responsible for business logic, which is undertaken by Activity in Android

(1) MVC code example

Let's take a login verification example to see how the MVC architecture is generally implemented.

This is the controller

MVC architecture to implement login process-controller

 public class MvcLoginActivity extends AppCompatActivity { private EditText userNameEt; private EditText passwordEt; private User user; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_mvc_login); user = new User(); userNameEt = findViewById(R.id.user_name_et); passwordEt = findViewById(R.id.password_et); Button loginBtn = findViewById(R.id.login_btn); loginBtn.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View view) { LoginUtil.getInstance().doLogin(userNameEt.getText().toString(), passwordEt.getText().toString(), new LoginCallBack() { @Override public void loginResult(@NonNull com.example.mvcmvpmvvm.mvc.Model.User success) { if (null != user) { // 这里免不了的，会有业务处理//1、保存用户账号//2、loading消失//3、大量的变量判断//4、再做进一步的其他网络请求Toast.makeText(MvcLoginActivity.this, " Login Successful", Toast.LENGTH_SHORT) .show(); } else { Toast.makeText(MvcLoginActivity.this, "Login Failed", Toast.LENGTH_SHORT) .show(); } } }); } }); } }

This is the model

MVC architecture to implement login process-model

 public class LoginService { public static LoginUtil getInstance() { return new LoginUtil(); } public void doLogin(String userName, String password, LoginCallBack loginCallBack) { User user = new User(); if (userName.equals("123456") && password.equals("123456")) { user.setUserName(userName); user.setPassword(password); loginCallBack.loginResult(user); } else { loginCallBack.loginResult(null); } } }

The example is very simple, mainly doing the following things

• Write a special tool class LoginService to make network requests doLogin, verify whether the login account is correct, and then return the verification result.
• The activity calls LoginService and passes the account information to the doLogin method. After obtaining the result, it performs the corresponding business operation.

(2) Advantages and disadvantages of MVC

MVC is sufficient in most simple business scenarios. Its main advantages are as follows:

1. Clear structure and clear division of responsibilities
2. Reduce coupling
3. Facilitates component reuse

However, as time goes by, your MVC architecture may slowly evolve into the following pattern. Take the above example, it is relatively simple if you only do login, but when your page implements login account verification and likes, there will be more methods. When sharing a view or operating a data source together, variables will appear everywhere and views will be called everywhere. I believe everyone has experienced this.

Inevitably, MVC has the following problems

In the final analysis, when using MVC in Android, the scope of Model, View, and Controller is always unclear, because there is an inseparable dependency relationship between them. So the following problems are always unavoidable:

• There is still a dependency relationship between View and Model. Sometimes, for the sake of convenience, Model and View are passed back and forth, making the coupling between View and Model extremely high. Low coupling is one of the object-oriented design standards. For large projects, high coupling can be painful, which requires a lot of effort in development, testing, and maintenance.
• Then at the Controller layer, the Activity sometimes has to manage the View and control the interaction with the user, acting as a Controller. It is conceivable that if there is a slight irregularity in the writing, the Activity will become very complicated and will have more and more functions.

We have spent a certain amount of space introducing MVC so that everyone can have a deep understanding of what the Model, View, and Controller in MVC should each accomplish, so that the subsequent architecture will have meaning when it continues to evolve.

2.2 The Origin of MVP Architecture

(1) What problem does MVP solve?

In October 2016, Google officially provided sample code for the MVP architecture to demonstrate the usage of this model, making it the most popular architecture.

Compared with MVC, MVP moves the complex logic processing of Activity to another class (Presenter) . At this time, Activity is the View in the MVP mode. It is responsible for initializing UI elements, establishing the association between UI elements and Presenter (such as Listener), and also handles some simple logic itself (complex logic is handled by Presenter).

Then MVP also divides the code into three parts:

Structure Description

• View : corresponds to Activity and XML, is only responsible for displaying UI, interacts only with the Presenter layer, and is not coupled with the Model layer;
• Model : responsible for managing business data logic, such as network requests and database processing;
• Presenter : Responsible for handling a large number of logical operations to avoid bloating of Activity.

Let's take a look at the MVP architecture diagram:

The main difference from MVC

View does not interact directly with Model, but indirectly interacts with Model through interaction with Presenter. In MVC, View can interact directly with Model.

Usually, View and Presenter are one-to-one, but complex View may bind multiple Presenters to handle logic. The Controller returns to its origin, and its primary responsibility is to load the layout of the application and initialize the user interface, and accept and process operation requests from users. It is behavior-based and can be shared by multiple Views. The Controller can be responsible for deciding which View to display.

The interaction between Presenter and View is carried out through interfaces, which is more conducive to adding unit testing.

(2) MVP code diagram

① Let’s look at the package structure diagram first

picture

② Create Bean

MVP architecture implements login process-model

 public class User { private String userName; private String password; public String getUserName() { return ... } public void setUserName(String userName) { ...; } }

③ Establish the Model interface (processing business logic, here refers to data reading and writing), write the interface method first, then write the implementation

MVP architecture implements login process-model

 public interface IUserBiz { boolean login(String userName, String password); }

④ Create a presenter (the main controller that operates the model and view through the iView and iModel interfaces). The activity can delegate all logic to the presenter, so that the Java logic is separated from the activity.

MVP architecture implements login process-model

 public class LoginPresenter{ private UserBiz userBiz; private IMvpLoginView iMvpLoginView; public LoginPresenter(IMvpLoginView iMvpLoginView) { this.iMvpLoginView = iMvpLoginView; this.userBiz = new UserBiz(); } public void login() { String userName = iMvpLoginView.getUserName(); String password = iMvpLoginView.getPassword(); boolean isLoginSuccessful = userBiz.login(userName, password); iMvpLoginView.onLoginResult(isLoginSuccessful); } }

⑤ The View view creates a view, which is used to update the view status in the UI. Here are the methods that need to operate the current view, which is also the interface IMvpLoginView

MVP architecture implements login process-model

 public interface IMvpLoginView { String getUserName(); String getPassword(); void onLoginResult(Boolean isLoginSuccess); }

⑥ Implement the IMvpLoginView interface in the activity, operate the view in it, and instantiate a presenter variable.

MVP architecture implements login process-model

 public class MvpLoginActivity extends AppCompatActivity implements IMvpLoginView{ private EditText userNameEt; private EditText passwordEt; private LoginPresenter loginPresenter; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_mvp_login); userNameEt = findViewById(R.id.user_name_et); passwordEt = findViewById(R.id.password_et); Button loginBtn = findViewById(R.id.login_btn); loginPresenter = new LoginPresenter(this); loginBtn.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View view) { loginPresenter.login(); } }); } @Override public String getUserName() { return userNameEt.getText().toString(); } @Override public String getPassword() { return passwordEt.getText().toString(); } @Override public void onLoginResult(Boolean isLoginSuccess) { if (isLoginSuccess) { Toast.makeText(MvpLoginActivity.this, getUserName() + " Login Successful", Toast.LENGTH_SHORT) .show(); } else { Toast.makeText(MvpLoginActivity.this, "Login Failed", Toast.LENGTH_SHORT).show(); } } }

(3) Advantages and disadvantages of MVP

Therefore, the Activity is freed from the Controller in MVC, and the Activity mainly displays the View and interacts with the user. Each Activity can implement the View interface IUserView according to the different Views it displays.

By comparing the MVC and MVP codes of the same example, some advantages of the MVP pattern can be confirmed:

• In MVP, the Activity code is not bloated;
• In MVP, changes to the Model (implementation class of IUserModel) will not affect the Activity (View), and the two will not interfere with each other, but in MVC;
• In MVP, the IUserView interface can facilitate testing of Presenter;
• In MVP, UserPresenter can be used in multiple views, but not in Activity in MVC.

But there are still some disadvantages:

• Bidirectional dependency: View and Presenter are bidirectionally dependent. Once the View layer changes, the Presenter also needs to be adjusted accordingly. In the business context, changes in the View layer are a high-probability event;
• Memory leak risk: Presenter holds a reference to the View layer. When the user closes the View layer, but the Model layer is still performing time-consuming operations, there will be a risk of memory leak. Although there is a solution, there are still risks and complexity (weak reference/onDestroy() recycles Presenter).

3. MVVM is actually enough

3.1MVVM idea has existed for a long time

MVVM was originally a UI architecture concept proposed by Microsoft in 2005. Later in 2015, it began to be applied to Android.

The change in the MVVM mode is that the Presenter in the middle is changed to ViewModel. MVVM also divides the code into three parts:

1. View: Activity and Layout XML files, which have the same concept as View in MVP;
2. Model: responsible for managing business data logic, such as network requests and database processing, which is the same as the concept of Model in MVP;
3. ViewModel: stores view state, handles presentation logic, and sets data to observable data containers.

The only difference from MVP is that it uses two-way data binding: changes in the View are automatically reflected in the ViewModel, and vice versa.

The MVVM architecture diagram is as follows:

It can be seen that the main difference between MVVM and MVP is that you don't have to actively refresh the UI. As long as the Model data changes, it will be automatically reflected in the UI. In other words, MVVM is more like an automated MVP.

MVVM's two-way data binding is mainly implemented through DataBinding, but most people should be like me and do not use DataBinding, so the MVVM architecture that everyone eventually uses becomes as follows:

To summarize:

Practical use of MVVM architecture

• View observes the data changes of ViewModel and updates itself. This is actually a single data source rather than two-way data binding, so I did not use the two-way binding feature of MVVM here.
• View interacts with ViewMdoel by calling methods provided by ViewModel.

3.2 MVVM Code Example

(1) Create a viewModel and provide a method login(String userName, String

password)

MVVM architecture to implement login process-model

 public class LoginViewModel extends ViewModel { private User user; private MutableLiveData<Boolean> isLoginSuccessfulLD; public LoginViewModel() { this.isLoginSuccessfulLD = new MutableLiveData<>(); user = new User(); } public MutableLiveData<Boolean> getIsLoginSuccessfulLD() { return isLoginSuccessfulLD; } public void setIsLoginSuccessfulLD(boolean isLoginSuccessful) { isLoginSuccessfulLD.postValue(isLoginSuccessful); } public void login(String userName, String password) { if (userName.equals("123456") && password.equals("123456")) { user.setUserName(userName); user.setPassword(password); setIsLoginSuccessfulLD(true); } else { setIsLoginSuccessfulLD(false); } } public String getUserName() { return user.getUserName(); } }

(2) Declare viewModel in activity and create an observation. Click the button to trigger login(String userName, String password). The persistent observer loginObserver will respond as long as isLoginSuccessfulLD in LoginViewModel changes.

MVVM architecture to implement login process-model

 public class MvvmLoginActivity extends AppCompatActivity { private LoginViewModel loginVM; private EditText userNameEt; private EditText passwordEt; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_mvvm_login); userNameEt = findViewById(R.id.user_name_et); passwordEt = findViewById(R.id.password_et); Button loginBtn = findViewById(R.id.login_btn); loginBtn.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View view) { loginVM.login(userNameEt.getText().toString(), passwordEt.getText().toString()); } }); loginVM = new ViewModelProvider(this).get(LoginViewModel.class); loginVM.getIsLoginSuccessfulLD().observe(this, loginObserver); } private Observer<Boolean> loginObserver = new Observer<Boolean>() { @Override public void onChanged(@Nullable Boolean isLoginSuccessFul) { if (isLoginSuccessFul) { Toast.makeText(MvvmLoginActivity.this, "登录成功", Toast.LENGTH_SHORT) .show(); } else { Toast.makeText(MvvmLoginActivity.this, "登录失败", Toast.LENGTH_SHORT) .show(); } } }; }

3.3 Advantages and Disadvantages of MVVM

Through the above code, we can summarize the advantages of MVVM:

In terms of implementation details, the View and Presenter change from a two-way dependency to a View that can send instructions to the ViewModel, but the ViewModel will not directly call back to the View. Instead, the View monitors data changes through the observer mode, effectively avoiding the shortcomings of MVP's two-way dependency.

But MVVM also has some disadvantages in some cases:

(1) For processes with strong correlation, there are too many liveData and the cost of understanding is high

When the business is more complex, there must be more LiveData to manage in the viewModel. Of course, if you manage these LiveData well and let them handle the business process, there is no big problem, but the cost of understanding will be higher.

(2) Not convenient for unit testing

The viewModel generally processes database and network data and contains business logic. When testing a certain process, there is no way to completely separate the data logic processing flow, which increases the difficulty of unit testing.

So let's take a look at the specific scenarios corresponding to the shortcomings, so that we can further explore the MVI architecture later.

(1) After logging in, you need to verify your account information and then automatically like the button. Then, add several methods to the viewModel, each of which corresponds to a LiveData

MVVM architecture to implement login process-model

 public class LoginMultiViewModel extends ViewModel { private User user; // 是否登录成功private MutableLiveData<Boolean> isLoginSuccessfulLD; // 是否为指定账号private MutableLiveData<Boolean> isMyAccountLD; // 如果是指定账号，进行点赞private MutableLiveData<Boolean> goThumbUp; public LoginMultiViewModel() { this.isLoginSuccessfulLD = new MutableLiveData<>(); this.isMyAccountLD = new MutableLiveData<>(); this.goThumbUp = new MutableLiveData<>(); user = new User(); } public MutableLiveData<Boolean> getIsLoginSuccessfulLD() { return isLoginSuccessfulLD; } public MutableLiveData<Boolean> getIsMyAccountLD() { return isMyAccountLD; } public MutableLiveData<Boolean> getGoThumbUpLD() { return goThumbUp; } ... public void login(String userName, String password) { if (userName.equals("123456") && password.equals("123456")) { user.setUserName(userName); user.setPassword(password); setIsLoginSuccessfulLD(true); } else { setIsLoginSuccessfulLD(false); } } public void isMyAccount(@NonNull String userName) { try { Thread.sleep(1000); } catch (Exception ex) { } if (userName.equals("123456")) { setIsMyAccountSuccessfulLD(true); } else { setIsMyAccountSuccessfulLD(false); } } public void goThumbUp(boolean isMyAccount) { setGoThumbUpLD(isMyAccount); } public String getUserName() { return user.getUserName(); } }

(2) Let's take a look at a processing logic that you may use. After determining that the login is successful, use the variable isLoginSuccessFul to perform loginVM.isMyAccount(userNameEt.getText().toString()); After the account verification is successful, use the variable isMyAccount to perform loginVM.goThumbUp(true);

MVVM architecture to implement login process-model

 public class MvvmFaultLoginActivity extends AppCompatActivity { private LoginMultiViewModel loginVM; private EditText userNameEt; private EditText passwordEt; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_mvvm_fault_login); userNameEt = findViewById(R.id.user_name_et); passwordEt = findViewById(R.id.password_et); Button loginBtn = findViewById(R.id.login_btn); loginBtn.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View view) { loginVM.login(userNameEt.getText().toString(), passwordEt.getText().toString()); } }); loginVM = new ViewModelProvider(this).get(LoginMultiViewModel.class); loginVM.getIsLoginSuccessfulLD().observe(this, loginObserver); loginVM.getIsMyAccountLD().observe(this, isMyAccountObserver); loginVM.getGoThumbUpLD().observe(this, goThumbUpObserver); } private Observer<Boolean> loginObserver = new Observer<Boolean>() { @Override public void onChanged(@Nullable Boolean isLoginSuccessFul) { if (isLoginSuccessFul) { Toast.makeText(MvvmFaultLoginActivity.this, "登录成功，开始校验账号", Toast.LENGTH_SHORT).show(); loginVM.isMyAccount(userNameEt.getText().toString()); } else { Toast.makeText(MvvmFaultLoginActivity.this, "登录失败", Toast.LENGTH_SHORT) .show(); } } }; private Observer<Boolean> isMyAccountObserver = new Observer<Boolean>() { @Override public void onChanged(@Nullable Boolean isMyAccount) { if (isMyAccount) { Toast.makeText(MvvmFaultLoginActivity.this, "校验成功，开始点赞", Toast.LENGTH_SHORT).show(); loginVM.goThumbUp(true); } } }; private Observer<Boolean> goThumbUpObserver = new Observer<Boolean>() { @Override public void onChanged(@Nullable Boolean isThumbUpSuccess) { if (isThumbUpSuccess) { Toast.makeText(MvvmFaultLoginActivity.this, "点赞成功", Toast.LENGTH_SHORT) .show(); } else { Toast.makeText(MvvmFaultLoginActivity.this, "点赞失败", Toast.LENGTH_SHORT) .show(); } } }; }

There is no doubt that this kind of interaction is possible in actual development. When the page is more complex, this kind of variable will also breed. In this scenario, it is necessary to talk about the MVI architecture.

4. Is MVI necessary?

4.1 Origin of MVI

The MVI pattern originated from Cycle.js (a JavaScript framework) in 2014, and became popular in the mainstream JS framework Redux. It was then ported to Android by some big guys (such as mosby, which was originally written in Java).

Since MVVM is the official recommended architecture of Android, why do we need MVI? In fact, the concept of MVI is not proposed in the application architecture guide, but one-way data flow and single data source are mentioned, which is also the characteristic that distinguishes MVVM.

However, I still want to point out that basically everything that MVI can do can also be done as long as you use MVVM to implement it. It’s just that in the content to be discussed below, the encapsulation ideas of MVI can be used directly and are convenient for unit testing.

The idea of ​​MVI: Drive the page with data (in fact, when you apply this idea to various frameworks, your framework will be more elegant)

The MVI architecture consists of the following parts:

1. Model: Mainly refers to the UI state. For example, the page loading state, control position, etc. are all a kind of UI state.
2. View: Same as other Views in MVX, it may be an Activity or any UI carrier unit. The View in MVI refreshes the interface by subscribing to changes in the Model.
3. Intent: This Intent is not the Intent of the Activity. Any operation of the user is packaged into an Intent and sent to the Model layer for data request.

Take a look at the interaction flow chart:

Explain the flow chart:

(1) User operations are notified to the Model in the form of Intent
(2) Model updates State based on Intent. This includes using ViewModel to make network requests and update State. (3) View receives State changes and refreshes the UI.

4.2 MVI Code Examples

Just look at the code

(1) First look at the package structure

picture

(2) The user clicks the button to initiate the login process

loginViewModel.loginActionIntent.send(LoginActionIntent.DoLogin(userNameEt.text.toString(), passwordEt.text.toString())).

Here is an Intent sent out

MVI architecture code-View

 loginBtn.setOnClickListener { lifecycleScope.launch { loginViewModel.loginActionIntent.send(LoginActionIntent.DoLogin(userNameEt.text.toString(), passwordEt.text.toString())) } }

(3) ViewModel monitors Intent

initActionIntent(). Here you can consume the Intent of the button click event

MVI architecture code-Model

 class LoginViewModel : ViewModel() { companion object { const val TAG = "LoginViewModel" } private val _repository = LoginRepository() val loginActionIntent = Channel<LoginActionIntent>(Channel.UNLIMITED) private val _loginActionState = MutableSharedFlow<LoginActionState>() val state: SharedFlow<LoginActionState> get() = _loginActionState init { // 可以用来初始化一些页面或者参数initActionIntent() } private fun initActionIntent() { viewModelScope.launch { loginActionIntent.consumeAsFlow().collect { when (it) { is LoginActionIntent.DoLogin -> { doLogin(it.username, it.password) } else -> { } } } } } }

(4) Use respository to make network requests and update state

MVI Architecture Code-Repository

 class LoginRepository { suspend fun requestLoginData(username: String, password: String) : Boolean { delay(1000) if (username == "123456" && password == "123456") { return true } return false } suspend fun requestIsMyAccount(username: String, password: String) : Boolean { delay(1000) if (username == "123456") { return true } return false } suspend fun requestThumbUp(username: String, password: String) : Boolean { delay(1000) if (username == "123456") { return true } return false } }

MVI architecture code - update state

 private fun doLogin(username: String, password: String) { viewModelScope.launch { if (username.isEmpty() || password.isEmpty()) { return@launch } // 设置页面正在加载_loginActionState.emit(LoginActionState.LoginLoading(username, password)) // 开始请求数据val loginResult = _repository.requestLoginData(username, password) if (!loginResult) { //登录失败_loginActionState.emit(LoginActionState.LoginFailed(username, password)) return@launch } _loginActionState.emit(LoginActionState.LoginSuccessful(username, password)) //登录成功继续往下val isMyAccount = _repository.requestIsMyAccount(username, password) if (!isMyAccount) { //校验账号失败_loginActionState.emit(LoginActionState.IsMyAccountFailed(username, password)) return@launch } _loginActionState.emit(LoginActionState.IsMyAccountSuccessful(username, password)) //校验账号成功继续往下val isThumbUpSuccess = _repository.requestThumbUp(username, password) if (!isThumbUpSuccess) { //点赞失败_loginActionState.emit(LoginActionState.GoThumbUpFailed(username, password)) return@launch } //点赞成功继续往下_loginActionState.emit(LoginActionState.GoThumbUpSuccessful(true)) } }

(5) Monitor state changes in View and refresh the page

MVI Architecture Code-Repository

 fun observeViewModel() { lifecycleScope.launch { loginViewModel.state.collect { when(it) { is LoginActionState.LoginLoading -> { Toast.makeText(baseContext, "登录中", Toast.LENGTH_SHORT).show() } is LoginActionState.LoginFailed -> { Toast.makeText(baseContext, "登录失败", Toast.LENGTH_SHORT).show() } is LoginActionState.LoginSuccessful -> { Toast.makeText(baseContext, "登录成功，开始校验账号", Toast.LENGTH_SHORT).show() } is LoginActionState.IsMyAccountSuccessful -> { Toast.makeText(baseContext, "校验成功，开始点赞", Toast.LENGTH_SHORT).show() } is LoginActionState.GoThumbUpSuccessful -> { resultView.text = "点赞成功" Toast.makeText(baseContext, "点赞成功", Toast.LENGTH_SHORT).show() } else -> {} } } } }

Through this process, we can see that the user clicks the login operation until the page is refreshed, which is a serial operation. In this scenario, the MVI architecture is the most suitable.

4.3 Advantages and Disadvantages of MVI

(1) The advantages of MVI are as follows:

• Better unit testing
  For the above case, using MVI, a one-way data flow, is more appropriate than MVVM and is easier to unit test. Each node is relatively independent and there is no code coupling.
  
  
• Subscribe to a ViewState to get all states and data
  There is no need to manage multiple LiveData like MVVM, you can directly use one state to manage it. Compared with MVVM, this is a new feature.

But MVI itself also has some disadvantages:

• State expansion: All view changes are converted to ViewState, and the corresponding data in different states needs to be managed. In practice, the decision to use a single stream or multiple streams should be based on the degree of correlation between states;
• Memory overhead: ViewState is an immutable class. When the state changes, a new object needs to be created, which has a certain memory overhead;
• Partial refresh: View responds according to ViewState, and it is not easy to implement partial Diff refresh. You can use Flow#distinctUntilChanged() to refresh to reduce unnecessary refreshes.

More importantly, even if there are many one-way data flows encapsulated, it is still inevitable that a newcomer will not follow the one-way data flow and handle the view casually. At this time, Compose should be referenced.

5. Why not use Compose to upgrade MVI

This chapter is the focus of this article.

In 2021, Google released Jetpack Compose 1.0. In 2022, it updated the article application architecture guide. When building the interface layer, the recommended solutions are as follows:

1. UI elements that present data on the screen. You can build these elements using View or Jetpack Compose functions.
2. A state container (such as a ViewModel class) that is used to store data, provide data to the interface, and handle logic.

Why is Compose mentioned here?

• One of the reasons for using Compose <br>Even if you use the MVI architecture, when someone does not follow this design concept, you cannot prevent others from using non-MVI architecture at the code level, which will eventually cause your code to become chaotic.
  
  This means that after you use the MVI architecture to build a page, someone suddenly introduces the MVC architecture. This is inevitable. Compose can perfectly solve this problem.

The following is what makes this article different from other technical blogs. It explains how to use Compose and why to use it in this way. Don’t just read the theory, it’s best to practice it.

5.1 The main function of Compose

Compose can bind the interface view to the data source at the very beginning, so that it cannot be tampered with elsewhere.

How to understand it?

After you have a TextView declared, according to the previous architecture, you can get this TextView and assign any value to its text. This means that TextView may be used not only in the MVI architecture, but also in the MVC architecture.

5.2 Code Examples for MVI+Compose

MVI+Compose architecture code

 class MviComposeLoginActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) lifecycleScope.launch { setContent { BoxWithConstraints( modifier = Modifier .background(colorResource(id = R.color.white)) .fillMaxSize() ) { loginConstraintToDo() } } } } @Composable fun EditorTextField(textFieldState: TextFieldState, label : String, modifier: Modifier = Modifier) { // 定义一个可观测的text，用来在TextField中展示TextField( value = textFieldState.text, // 显示文本onValueChange = { textFieldState.text = it }, // 文字改变时，就赋值给text modifier = modifier, label = { Text(text = label) }, // label是Input placeholder = @Composable { Text(text = "123456") }, // 不输入内容时的占位符) } @SuppressLint("CoroutineCreationDuringComposition") @Composable internal fun loginConstraintToDo(model: ComposeLoginViewModel = viewModel()){ val state by model.uiState.collectAsState() val context = LocalContext.current loginConstraintLayout( onLoginBtnClick = { text1, text2 -> lifecycleScope.launch { model.sendEvent(TodoEvent.DoLogin(text1, text2)) } }, state.isThumbUpSuccessful ) when { state.isLoginSuccessful -> { Toast.makeText(baseContext, "登录成功，开始校验账号", Toast.LENGTH_SHORT).show() model.sendEvent(TodoEvent.VerifyAccount("123456", "123456")) } state.isAccountSuccessful -> { Toast.makeText(baseContext, "账号校验成功，开始点赞", Toast.LENGTH_SHORT).show() model.sendEvent(TodoEvent.ThumbUp("123456", "123456")) } state.isThumbUpSuccessful -> { Toast.makeText(baseContext, "点赞成功", Toast.LENGTH_SHORT).show() } } } @Composable fun loginConstraintLayout(onLoginBtnClick: (String, String) -> Unit, thumbUpSuccessful: Boolean){ ConstraintLayout() { //通过createRefs创建三个引用// 初始化声明两个元素，如果只声明一个，则可用createRef() 方法// 这里声明的类似于View 的id val (firstText, secondText, button, text) = createRefs() val firstEditor = remember { TextFieldState() } val secondEditor = remember { TextFieldState() } EditorTextField(firstEditor,"123456", Modifier.constrainAs(firstText) { top.linkTo(parent.top, margin = 16.dp) start.linkTo(parent.start) centerHorizontallyTo(parent) // 摆放在ConstraintLayout 水平中间}) EditorTextField(secondEditor,"123456", Modifier.constrainAs(secondText) { top.linkTo(firstText.bottom, margin = 16.dp) start.linkTo(firstText.start) centerHorizontallyTo(parent) // 摆放在ConstraintLayout 水平中间}) Button( onClick = { onLoginBtnClick("123456", "123456") }, // constrainAs() 将Composable 组件与初始化的引用关联起来// 关联之后就可以在其他组件中使用并添加约束条件了modifier = Modifier.constrainAs(button) { // 熟悉ConstraintLayout 约束写法的一眼就懂// parent 引用可以直接用，跟View 体系一样top.linkTo(secondText.bottom, margin = 20.dp) start.linkTo(secondText.start, margin = 10.dp) } ){ Text("Login") } Text(if (thumbUpSuccessful) "点赞成功" else "点赞失败", Modifier.constrainAs(text) { top.linkTo(button.bottom, margin = 36.dp) start.linkTo(button.start) centerHorizontallyTo(parent) // 摆放在ConstraintLayout 水平中间}) } }

The key code segment is below:

MVI+Compose architecture code

 Text(if (thumbUpSuccessful) "点赞成功" else "点赞失败", Modifier.constrainAs(text) { top.linkTo(button.bottom, margin = 36.dp) start.linkTo(button.start) centerHorizontallyTo(parent) // 摆放在ConstraintLayout 水平中间})

The text of the TextView is bound to the thumbUpSuccessful variable in the data source when the page is initialized, and the value of this TextView cannot be reassigned elsewhere, and the value can only be modified through this variable thumbUpSuccessful. Of course, using this method also solves the problem that data updates cannot be updated by diff, which is perfect.

5.3 Advantages and Disadvantages of MVI+Compose

The advantages of MVI+Compose are as follows:

• Ensure the uniqueness of the framework <br>Because each view is assigned by the data source at the beginning and cannot be modified by multiple calls at will, it ensures that the framework will not be disrupted at will. It better ensures the characteristics of low coupling of the code.

MVI+Compose also has some disadvantages:

It cannot be called a disadvantage.

Since the Compose implementation interface is implemented purely by kotlin code and does not use the xml layout, in this way, the learning cost will be higher when learning at the beginning. And the performance is still unknown, so it is best not to use it on a first-level page.

6. How to choose the framework mode

6.1 Principles of architecture selection

Through the comparison of so many architectures above, the following conclusions can be summarized.

High coupling is a phenomenon, separation of concerns is a means, easy maintenance and easy testing are the results, and the pattern is a reusable experience.

Let’s summarize the scenarios applicable to the above frameworks:

6.2 The principle of framework selection

1. If your page is relatively simple, for example, it is a network request and then refresh the list, and using MVC is enough.
2. If you have many pages that share the same logic, such as multiple pages have network requests loading, network requests, network requests loading, and network requests failing, using MVP, MVVM, and MVI to encapsulate the interface better.
3. If you need to listen to changes in data sources in multiple places, you need to use LiveData or Flow, that is, MVVM and MVI architectures.
4. If your operation is serial, for example, after logging in, and after logging in, then like it, it is better to use MVI at this time. Of course, MVI+Compose can ensure that your architecture is not easy to be modified.

Do not mix architecture patterns. After a thorough analysis of the page structure, just select a architecture, otherwise the page will become more and more complex and cannot be maintained.

The above is a summary of all framework models, and everyone chooses according to the actual situation. It is recommended to get started with the latest MVI+Compose directly. Although there is a little more learning cost, the idea of ​​Compose is still worth learning from.