- 기존 MVP 모델에서 Presenter에 LiveData를 적용하면 의존성을 없앨 수 있다.
- view에서 라이브데이터를 보기위해 observe를 사용한다
presenter.count.observe(this) {
findViewById<TextView>(R.id.count_tv).texr = it
}- 뷰는 그래도 프레젠터에 대한 의존성을 갖고 있지만 프레젠터는 뷰에 대한 의존성을 완전히 끊어낼 수 있다.
- 왜 끊어야 해?
- 의존성을 줄이면 좋은 코드인가?
MVVM
- MVP 일 때 뷰와 모델 사이의 의존성을 갖고 있다
- MVP에서의 Presenter: 난 뷰한테 직접 데이터를 전달해줄거야 (뷰 의존성이 있어).
MVVM에서의 ViewModel: 난 데이터가 있어. 이걸 뷰한테 직접 보내주진 않을거야 (뷰 의존성이 없어). 뷰가 이 데이터를 참조해서 가져다 쓸거야. - MVVM에는 model, view, viewModel, binder 가 존재한다.
- 라이브 데이터를 이용해 MVP를 개선시켰다면 MVVM일까? 어느정도는 달성했다 by 제임스
- 바인더랑 데이터 바인딩 같은건가봐...
- 뷰모델을 안쓰고도 MVVM 가능? viewModel 이름이 아니더라도 그 역할을 하는 클래스는 있어야 한다.
- Binding.lifecycleOwner = this
- 왜 해줘야 할까?
- 적절한 시점에 관찰을 해제할 수 있도록
- 특히 Fragment에서 관찰이 두 번 되는 경우가 생길 수 있다
- ACC 뷰모델을 사용하지 않아도 MVVM이다.
- 하지만 ACC 라이브러리를 사용하지 않으면 화면 회전에 대처할 수가 없게 된다.
Private lateinit var viewModel: CounterViewModel
viewModel = ViewModelProvider(this)[CounterViewModel::class.java]- AAC 뷰모델을 쓸 때는 일반적인 클래스처럼 인스턴스를 생성하면 안됨
- AAC 뷰모델을 적용하면, 화면 회전해도 데이터가 유지되는 것을 볼 수 있음
- AAC 뷰모델은 Configuration changes 대응에만 의미가 있는 것이 아니다
- 뷰모델과 액티비티 생명주기가 다른데 뷰모델에서 MVP처럼 뷰를 참조하도록 하면 어떤 문제가 생길까?
- 예상치못한 상황으로 액티비티가 죽었을때 뷰모델이 계속 뷰를 참조한다면 앱이 제대로 동작할 수 없을 수도...- 메모리 누수에도 취약
MVVM 장단점
-
장점: 모듈화가 되어 테스트가 쉬워진다
-
단점: 단순한 UI 작업에서는 MVVM을 구현하는 부담이 "지나치게 과하다" 고 지적한다. 그가 말하길 응용 프로그램이 점점 더 커짐에 따라서, 뷰 모델을 폭 넓게 사용하기가 점점 더 어려워진다고 한다. 게다가 아주 큰 응용 프로그램에서 데이터 바인딩을 사용하게 되면 눈에 띄게 메모리를 소모하게 된다고 설명한다.
-
상황에 맞는 아키텍쳐를 사용하는 것이 좋다.
-
무조건적으로 MVVM이 좋은 것만은 아니다
-
한 액티비티에 여러개 뷰모덜 연결?
- 쓸 수 는 있지만 권장하지는 않는다 by 구글
