Android Architecture Components ViewModel이 왔어요

MVVM 패턴에서 우리는 viewmodel에 UI에 표현할 모든 데이터를 담아 view와 연결합니다

 

view는 단지 viewmodel의 존재만 알고 있으면 됩니다.

 

viewmodel이 데이터베이스나 네트워크를 통해 로드된 데이터를 보관하고 있기때문에

 

view는 그 어떤 비즈니스로직을 가지고 있지 않습니다

 

안드로이드 앱을 개발하다보면 activity나 fragment가 

 

UI코드는 물론 비즈니스코드까지 포함해서 엄청 거대해지는것이 가장 흔한 일중의 하나입니다.

 

그래서 이러한 방법을 통해 view가 비즈니스로직까지 포함하여 너무 뚱뚱해지지 않도록 합니다

 

그렇기에 MVVM 패턴은 안드로이드 앱개발에서 있어서 매우 유용한 패턴중의 하나입니다

 

 

android jetpack의 구성요소중 하나인 ViewModel은

 

이러한 패턴을 좀 더 걱정없이 더 적은 코드로 구현할수 있도록 돕습니다

 

ViewModel의 도우미 클래스를 제공합니다

 

이미 사용하고 있는 ViewModel 역할의 클래스가 있더라도 매우 손쉽게 jetpack의 ViewModel을 적용할수 있습니다.

 

 

안드로이드 시스템은 액티비티나 프래그먼트같은 UI의 수명주기를 관리합니다

 

안드로이드 시스템은 특정상황(화면 회전을 했을때도)에서 UI를 제거하거나 재생성하도록 명령할수도 있습니다

 

시스템에서 UI 를 제거하거나 다시 만들었을때 액티비티나 프래그먼트에 저장된 UI데이터는 손실됩니다

 

하지만 우리는 보관되어있는 ViewModel을 통해서 액티비티나 프래그먼트가 다시 생성되었을때

 

ViewModel을 통해서 원하는 데이터를 다시 UI에 표시할수 있습니다

 

 

이 그림은 activity가 생성된후 회전을 시키고 종료가 될때까지의 수명주기 상태를 보여줍니다

 

activity가 회전되었을때 액티비티가 onDestory되었다가 다시 onCreate되는 것을 볼수 있습니다.

 

만약 UI에 표시할 데이터를 보관해두었다면

 

회전 이후에는 회전 이전의 데이터가 모두 없어져 표시가 되지 않겠지요

 

 

하지만 액티비티의 라이프사이클 오른쪽의 ViewModelScope를 보면

 

액티비티가 중간에 재생성되는것에 개의치 않고 액티비티가 완전히 종료되기 전까지 살아있는것을 볼 수 있습니다

 

이러한 라이프사이클을 가지고 있는 ViewModel에 UI에 표시할 데이터를 보관하고 있다면

 

액티비티가 언제든 없어졌다가 재생성되어도 다시 ViewModel에 있는것을 꺼내와서 표시하면 되기때문에

 

아무런 문제가 없습니다

 

 

ViewModel의 라이프사이클은 ViewModelProvider에 전달되는 Lifecycle로 지정이 되는데

 

Lifecycle이 완전히 종료되기 전까지 ViewModel은 살아있게 됩니다

 

여기서 lifecycle을 좀 더 쉽게 표현하면 액티비티나, 프래그먼트를 말하는데

 

ViewModelProvider에 액티비티를 전달하면 ViewModel은 액티비티와 같은 수명주기를 갖게되고

 

프래그먼트를 전달하면 프래그먼트와 같은 수명주기를 갖게 됩니다

 

실제 ViewModelProvider의 of 메소드를 살펴보면

 

activity가 전달될때와 Fragment가 전달될때가 구분이 되어있습니다

 

 

ViewModelProviders.of(this) 를 호출할때 of() 메소드에 넣은

 

라이프사이클의 종류가 무엇이냐에 따라 이를 통해 가져온 ViewModel의 라이프사이클이 결정됩니다

 

 

코드 예제를 한번 살펴봅시다

 

MasterFragment와 DetailFragment로 2개로 구성된 MainActivity 가 있다고 생각합니다

 

master는 리스트화면이고 detail은 뷰화면일수도 있을겁니다

 

태블릿의 master-detail 뷰일수도 있습니다

 

MainActivity와 MasterFragment, DetailFragment 이 셋은 SharedViewModel의 인스턴스를 공유하여야합니다

 

아래의 예에서는 selected된 아이템을 저장하는 것인데

 

SharedViewModel이 selected된 아이템에 대한 값을 알고 있으므로서

 

MasterFragment는 여러개의 아이템중 selected된 아이템에 하이라이트 표시를 해줄수 있고,

 

DetailFragment는 selected된 아이템의 디테일한 정보를 보여주게 될것입니다.

 

만약 화면의 회전과 같은 안드로이스 시스템이 UI를 새로 만들게 되더라도

 

MainActivity가 완전히 종료되기 전까지는 SharedViewModel이 데이터를 갖고 있으므로

 

재생성된 UI에서도 selected된 아이템을 기억하고 다시 표시해줄수 있습니다

 

 

 

MainActivity에서 ViewModelProviders의 of 메소드에 activity 자신을 파라메터로 넣습니다

 

이제 SharedViewModel은 MainActivity와 같은 생애주기를 갖게 됩니다

 

 

 

 

MasterFragment와 DetailFragment가 재생성이 되던말던, 지지고 볶던간에

 

SharedViewModel은 계속해서 메모리에 살아있기때문에

 

fragment에서 언제든 데이터를 가져올수 있습니다

 

 

 

android viewmodel이 나오기 이전에는

 

우리가 직접 ViewModel을 생성하고 그 라이프사이클을 관리해주었어야했는데

 

이제 그럴필요가 없어졌습니다

 

여러분의 코드가 ViewModelProvider로 인해서 좀 더 비즈니스로직 그 자체에만 집중할수 있게 되었습니다

 

 

실제로 dagger를 통해서 ViewModel 의존성을 관리하고 그 scope를 관리하고

 

서브컴포넌트를 만들고 하는것도 일이었는데

 

ViewModel의 생성부터 해지까지 ViewModelProvider에게 맡김으로서

 

좀 더 수월해졌기도 합니다