[Android] liveData, stateFlow와 함께 보는 MVVM에 대한 고찰

출처: unsplash.com

 

이번 포스팅에서는 저번 포스팅에서 언급했다시피, clean architecture와 함께 실무에서 반필수적으로 사용되는 디자인 패턴인 mvvm에 대해 공부해서 적어보고자 한다.

마찬가지로 공부하면서 참고한 포스팅도 같이 링크로 남겨 놓겠다.

 

MVVM은 무엇일까?

MVVM에 관해서는 찾아보면 자료가 많이 나오기 때문에 간단하게 정의해 보면,

MVC와 MVP에서 view와 엮이는 의존성을 해결하기 위해 view model을 도입한 디자인 패턴.
MVVM은 model, view, view model의 약자다.

 

여기서 view model과 view는 1 : n의 관계를 가질 수 있다는 특징을 지닌다.

 

MVVM을 왜 쓰는 걸까?

mvvm 디자인 패턴은 다음과 같은 장점을 가진다.

1. 의존성 최소화
   view는 view model을 알지만, view model은 view를 모르고, view model은 model을 알지만, model은 view model을 모른다.
   이러한 단방향 의존성으로 인해 각 요소의 수정이 다른 요소에 미치는 영향이 줄어든다.
2. 관심사의 분리
   activity, fragment에 모든 코드를 작성해 앱 동작 속도 저하, 유지보수의 어려움, 메모리 관리의 어려움이 생기는 기존의 코드의 문제점을 해결해 준다.
   각 요소의 역할이 명확해져 가독성과 유지 보수성이 향상된다.
   한 로직에서 문제가 발생해도 다른 부분에 미치는 영향을 최소화할 수 있다.
3. 반응형 프로그래밍
   activity, fragment에서 live data와 data binding을 이용해 데이터가 바뀔 때, 그것에 반응하는 동작을 수행하게 할 수 있다.
   view model의 데이터와 연결된 view의 ui는 view model의 데이터가 변경될 때마다, 그에 맞는 ui를 짤 수 있다는 뜻이다.

위 장점이 있어서 mvvm의 사용을 지향하는 듯하다.

결론은 view와 model의 의존성을 분리해 의존성을 최소화하고, ui에 모두 작성되었던 코드를 다른 요소로 옮겨 관심사를 분리하고 live data, data binding과 함께 사용해 반응형 프로그래밍 방식의 개발이 가능하기 때문에 mvvm을 사용한다.

 

더 많은 정보는 아래의 글들을 참고 바란다.

Android에서 MVVM 패턴이 중요한 이유

Android에서 MVVM 패턴이 중요한 이유

Android에서의 MVVM은 무엇이고 왜 사용하는가

Android에서의 MVVM은 무엇이고 왜 사용하는가

[Android] MVVM 패턴과 적용방식

[Android] MVVM 패턴과 적용방식

 

MVVM의 구조

1. model
   데이터에 대한 처리, 데이터 관련 비즈니스 로직을 처리.
   view에 대한 로직은 가지지 않아야 한다.
    ↳ db, api 접근에 대한 처리를 진행하거나, db, api 접근에 대한 result data class를 정의한다.
2. view
   ui를 정의한다.
   view model의 데이터에 따라 그에 맞는 ui로 변경한다.
    ↳ view model의 live data 데이터를 observe 해서 데이터에 따른 ui로 변경한다.
3. view model
   view와 model 사이의 매개체.
   view의 상태, ui에 대한 로직 구현.
    ↳ model에서 불러온 api 접근에 대한 데이터를 live data를 통해 view로 넘겨준다.

 

더 자세한 정보는 아래의 글 참고.

[Android/Design Pattern] MVVM 디자인 패턴에 대해 알아보자!

[Android/Design Pattern] MVVM 디자인 패턴에 대해 알아보자!

 

MVVM에서의 liveData, stateFlow

mvvm을 공부하다 보면 역시 꼭 같이 언급되는 개념 중 하나가 live data이다.

live data는 android jetpack 라이브러리의 기능 중 하나로,

데이터의 변경을 관찰할 수 있는 data holder 클래스이다.
일반적인 observable과는 달리, android의 생명주기를 알고 있다. 그래서 생명주기가 started 또는 resumed 상태일 때만 데이터를 업데이트한다.
observer 객체와 함께 사용된다. live data의 데이터에 변화가 일어났을 때, 등록된 observer에 변화를 알리고, observer의 onChanged() 메서드가 실행된다.

 

결국은 데이터를 들고 있다가 변경될 때 observer에서 변경된 값을 알 수 있게 해주는 역할을 하고 있다.

설명에 나와있는 것처럼, 많은 장점을 가지고 있다.

 

하지만 live data를 쭉 파고 들어가다 보면 state flow라는 개념도 쉽게 찾아볼 수 있다.

state flow는 coroutine flow의 하위 클래스로, 상태를 나타내는 값을 지속적으로 배출할 수 있다.
초기 상태가 있어야 하며, collect를 중단하지 않고 생명주기가 destroy 될 때까지 값을 불러온다.

 

state flow 관련 자료들을 보면 항상 live data와 엮이면서 state flow를 사용하는 게 좋다고 한다.

어떤 점이 live data보다 나은지 알아보자.

 

liveData vs stateFlow

state flow는 live data에 비해 아래와 같은 장점이 있다.

1. coroutine scope(코루틴 범위)에서 안전하게 사용.
   activity, fragment가 destroy 되거나 view가 분리된 경우 데이터 누출을 방지할 수 있다.
2. 불변성 보장.
   live data와는 달리 state flow에서는 값을 변경할 수 없으며, 새로운 상태 값을 배출할 때마다 새로운 객체가 생성된다.
   예기치 않은 값 변경을 방지할 수 있다.

 

그러면 live data는 어떤 단점이 있길래 state flow에 밀려서 안 쓰이게 되는 걸까?

1. 비동기 스트림에 부적합.
   live data의 관찰은 오직 main thread에서만 진행되기 때문에 android clean architecture의 data layer에서 live data를 이용해 데이터 스트림을 처리하려고 하면 한계가 생긴다.
2. clean architecture의 domain에서 사용하기 부적합.
   일반적으로 clean architecture의 domain layer는 의존성을 가지지 않는 순수한 kotlin/java 코드로 이루어져야 하는 layer이다.
   live data는 aac 라이브러리이기 때문에 domain layer에서 사용하면 clean architecture 원칙에 위배된다.

 

live data의 단점들은 모두 state flow를 사용하면 해결이 가능한 문제들이다.

• state flow는 coroutine 기반이기 때문에 비동기 스트림에 적합하다.
• state flow는 순수한 kotlin 표준 라이브러리이기 때문에 clean architecture 원칙에 위배되지 않는다.

 

더 자세한 정보를 알고 싶으면 아래 포스팅에 더 자세한 정보가 있다.

[Android] LiveData에 대해 알아보자

[Android] LiveData에 대해 알아보자

StateFlow란?

StateFlow 란?

[Android] LiveData... 넌 누구냐?

[Android] LiveData...넌 누구냐?

[Android] LiveData VS StateFlow, 왜 StateFlow를 써야 할까?

[Android] LiveData VS StateFlow, 왜 StateFlow 를 써야할까?

 

정리

mvvm을 다시 정리해 보면서, 사용하는 이유, 구조별 특징, view model의 반응형 프로그래밍을 위한 live data와 state flow까지 공부할 수 있었다.

state flow를 깊게 들어가려니까 coroutine 관련 개념들이 등장하기 시작했다. 그래서 다음 포스팅 주제는 coroutine이다.