안드로이드 mvvm 패턴으로 개발을 하다 보면, 이렇게 하는 것이 맞나? 라는 생각이 종종 들 때가 있습니다.
이와 관련해서 자료를 찾아보니 좋은 블로그를 발견해서 저도 한번 정리해보겠습니다.
https://blog.gangnamunni.com/post/mvvm_anti_pattern/
가장 의문이 드는 경우는 ViewModel에 어디까지 하고, Activitiy에 어디까지 적용해야 하는가? 입니다.
1. ViewModel 안에 안드로이드 프레임워크가 있어도 될까요?
안드로이드 프레임워크라는 것은 저희가 흔히 개발을 하면서 보는 아래와 같은 것들입니다.
1–1. Activity Manager : 액티비티의 생명주기를 호출, 공통적인 네비게이션 백스택을 제공 (onStart(), onResume(), onCreate(), onStop(), onPause(), onDestroy(), onRestart() 메서드가 호출되는 것을 관리)
1–2. Resource Manager : 문자열, 그래픽, 레이아웃 파일 등 리소스를 찾아주는 역할
1–3. View System : 리스트, 그리드, 텍스트 뷰, 버튼, 웹 뷰 등 뷰들의 집합
1–4. Content Provider : 안드로이드 4대 컴포넌트 중 하나, 어플리케이션이 다른 어플리케이션으로부터 데이터를 엑세스하거나, 자신의 데이터를 공유하는 게 가능하게 함
1–5. Package Manager : 현재 디바이스에 설치된 어플리케이션과 관련된 정보를 가지고 있음
1–6. Notification Manager : 모든 어플리케이션의 상태표시줄에 커스텀 알럿 창을 보여주게 함(FCM 기능 구현시 이용한다.)
1–7. Window Manager : 화면에 대한 정보, 배치 등을 관리하는 시스템 서비스(투명한 액티비티를 만들거나 화면의 크기를 구할 때 쓰임)
1–8. Telephony Manager : 단말기의 상태에 대한 정보를 얻을 수 있는 서비스
1–9. Location Manager : 단말의 위치 값을 지속적으로 얻을 수 있는 서비스(위치 기반 서비스를 만들 때 쓰임)
당연히 지양되는 패턴입니다. 왠지 느낌상 안될 것 같죠? Android 프레임워크에 종속성을 가지지 않아야 unit test를 진행할 수 있습니다.
2. ViewModel안에서 View를 참조해도 될까요?
이것도 느낌 상 안될 것 같죠? ViewModel의 생명주기가 액티비티나 프래그먼트 보다 길기 때문에, 메모리 leak 이 발생할 수 있습니다.
ViewModel과 View와 통신할 때는 liveData를 활용하면 됩니다.
3. MutableLiveData를 public으로 해도 될까요?
진부한 말이지만 느낌상 안될 것 같은데, 하지말라고 합니다.
Activity나 Fragment에서 MutableLiveData의 값을 변경하는 것은 지양해야 합니다. 때문에, LiveData를 이용해서 값을 변경합니다.
4. Acitivity/Fragment에 로직이 있어도 될까?
로직이 있으면 MVVM이 아니겠죠? if, for 같은 로직이 존재하면 안됩니다.
5. Acitivty/Framgent에 여러개의 ViewModel이 있어도 될까?
저는 될 것 같은데, 하나의 ViewModel을 사용하는 것을 권장한다고 합니다.
6. 하나의 ViewModel에는 여러개의 View를 가져도 될까?
해도 되긴 하지만, ViewModel이 복잡해질 수 있습니다. 이 부분은 개발자가 관리해야 합니다.
- 참고
'Android(Kotlin)' 카테고리의 다른 글
Android infinit scroll (0) | 2021.08.27 |
---|---|
Android Unit Test (0) | 2021.08.27 |
Sealed class vs Enum (0) | 2021.08.27 |
Android MVC MVVM MVP (0) | 2021.08.24 |
Clean Architecture (0) | 2021.08.24 |