MVI( Model - View - Intent )

🛠 MVI Pattern

안드로이드 생태계에서는 대부분 MVVM을 Architecture Pattern으로 선정해왔다.

MVVM을 이용하면 ViewModel은 View를 참조하지 않을뿐만 아니라,

각 컴포넌트들을 기능에 따라 분리시키며 관심사 분리에 따른 개발을 진행할 수 있다.

하지만 MVVM으로 프로덕트를 디벨롭하다보면 애플리케이션의 여러 상태를 제어하지 못해 일어나는 버그들이 많다.

 

✅상태문제

애플리케이션에는 무수한 상태들로 구성되어 있다.
비즈니스 로직에 따라 앱의 상태는 자주 변경되고 관리되며, 이에 따라 UI Rendering이 적절하게 이루어져야 한다.

하지만 앱이 커지고 기능이 많아질 수록 이러한 상태관리가 힘들어지고 의도한 방향으로 제어되지 않을 가능성이 매우 크다.

MVI는 이러한 상태문제를 단방향, 순환 데이터 흐름, 불변 객체를 이용한 단일 상태관리 를 사용하여 해결한다.

 

✅ MVI 구성요소

1️⃣ Model: 앱의 유일한 상태와 데이터를 가지고 있는 불변 객체.
2️⃣ View: 사용자가 볼 수 있는 UI Component
3️⃣ Intent: 앱의 상태를 변경하는 요청

 

MVI는 함수형 프로그래밍에 의존하여 각 계층은 입력을 받고 다음 계층에 출력을 전달한다.

우리는 함수 f(x)가 동일한 입력 x에 대해 동일한 출력결과를 가질 것으로 예상할 수 있다.

이처럼 같은 event에 대해 예측 가능한 State를 얻을 수 있을 수 있는데, Kotlin에서는 이를 구현하기 위해 Sealed Class를 활용한다.

 

✅ Side Effect

Model, View, Intent 3가지 컴포넌트의 순환구조만으로는 앱이 완전하게 구현되기는 어렵다.

여러가지 Background 작업, DB접근, Http 통신 등 여러가지 작업들을 수행해야하는 경우가 많기 때문이다.

 

MVI에서는 이를 SideEffect라고 정의한다.

 

Intent가 들어오게 되면 Model로 값을 전달함과 동시에 SideEffect를 실행시킨다.

해당 작업이 끝나게 되면 결과를 바로 render하는 것이 아니라,

Intent를 사용하여 Model로 값을 던지거나 다른 Intent를 다시 호출 할 수 있다.