MVI

이번에 Jetpack Compose를 이용한 프로젝트를 진행하면서 MVI 패턴을 처음 사용하였다. 이전의 프로젝트에서는 MVVM 패턴을 적용했었기 때문에 신세계였다. MVVM 패턴을 사용할 때는 뷰가 데이터를 관찰하는 것에 신경을 많이 썼었는데 MVI 패턴을 사용하면서 상태관리 부분에 많이 신경을 썼다.

MVI 패턴에 대해서 자세히 알아보지 않고 프로젝트를 진행했었기 때문에 많이 헤멨었는데 이번 기회에 제대로 공부해서 정리하는 게 좋겠다는 생각을 하여 정리해본다.

Why MVI?

안드로이드 앱은 상태의 집합이라고 볼 수 있다. 작은 화면에서도 여러 상태가 존재한다.

위의 화면에는 여러 상태가 존재한다.

• 광고 배너 보여줌 유무
• 각 아이템 클릭 여부
• 로딩 바 보여줌 유무
• 스크롤 상태

대충 생각나는건 이 만큼 있는데 이거 말고 더 있을 것이다. 여튼 이런 상태들로 화면이 구성되는데 규모가 커지면 데이터의 흐름이 복잡해지면서 상태를 관리하기 힘들어 질 수 있고 상태의 변화에 따라 뷰 업데이트, 비즈니스 로직을 동시에 처리하면서 코드가 복잡해진다.

(예전에 진행한 프로젝트에서 이미지 6장을 서버에 전송하는 과정에서 비동기로 처리하면 앱이 자꾸 터져서 runBlocking으로 이미지를 전송하는 방법을 사용한 적이 있다. 이때 이미지를 전송하는 과정에서 프로그레스 바를 화면에 보여주는 동작을 이미지 전송 상태에 따라서 처리하려 했지만 runBlocking 때문에 동작하지 않아서 제거했던 적이 있음)

 

그리고 Jetpack Compose는 뷰의 상태에 따라 Recomposition 하기 때문에 상태 관리가 중요해졌다.

이러한 이유들 때문에 MVI 패턴을 사용하기 시작했다.

 

What is MVI?

MVI는 Model, View Intent의 약자이다.

• Model: 앱의 단일 상태
  Model는 intent로 부터만 생성되어야 되기 때문에 불변적이여야 한다.
  상태를 불변적이어야 상태가 우리가 예상할 수 있는 범위 내에 있을 수 있다.
• View: UI 사용자와의 상호작용의 결과로 이벤트를 Intent로 전달한다.
• Intent: 사용자의 동작 View로 부터 받은 이벤트를 처리하여 상태를 생성한다.

MVI 패턴은 단방향 흐름으로 구성된다. View에서 사용자 동작을 Intent로 넘기면 이 동작 처리해서 UI의 상태를 업데이트 하고 이를 바탕으로 View를 업데이트 한다.

 

SideEffect

위에서 설명했던 대로만 동작하면 좋겠지만 그렇지 않다. 서버 통신, 백그라운드 작업 같은 상태를 변화할 필요가 없는 작업들은 위의 순환에 포함될 수 없다. 이러한 작업들은 SideEffect로 처리를 하게된다.

ex) 화면 이동, 토스트 메시지…

intent와 model 사이의 과정에서 SideEffect 과정을 진행한다.