들어가기 전에
✔ 안드로이드 개발을 처음 시작한다면 하나의 액티비티에 모든 코드를 넣어서 개발을 하곤 한다. 이렇게 되면 시간이 지날수록 액티비티가 무거워지며 유지보수가 힘들어진다. 이와 같은 비효율적인 코드를 스파게티 코드라고 한다.
✔ 하나의 액티비티가 무거워지는 것을 방지하며 유지보수가 용이하도록 만들기 위해서 Architecture 패턴이 등장했고, 안드로이드에서 최근에 유행하는 디자인 패턴은 MVVM 패턴이다.
✔ 보다 나은 이해를 위해 MVC 패턴과 MVVM 패턴을 서로 비교하면서 살펴보자.
MVC
✔ Model - View - Controller
시나리오
◽ Controller가 사용자 동작을 받아들인다. (텍스트 입력, 버튼 터치 등)
◽ Controller가 사용자의 동작에 따른 Model의 업데이트를 요청한다.
◽ Controller가 Model을 나타낼 View를 선택한다.
◽ View는 Model을 참조하여 UI를 업데이트함
✔ 쉽게 말하면 Controller가 유저의 이벤트를 받아들이고, Model에 데이터를 갱신하도록 하는 동시에 View에도 화면을 업데이트하라고 요청을 해야 한다. 해당 구조의 경우 액티비티가 여전히 할 일이 많은 단점이 있다.
✔ 또한 View와 Model 간의 의존성이 높아질 수 밖에 없다.
✔ 따라서 코드 유지보수를 하다가 잘못하면 UI 프레임 스킵 현상 및 메모리 릭(Memory Leak) 위험에 빠질수도 있다.
✔ 즉, MVC 패턴은 구현하기 쉬운 장점이 있는 반면, 기능 추가 및 변경에 있어서 유지보수가 여전히 어렵다.
MVVM
✔ View - ViewModel - Model
View
✔ 액티비티, 프래그먼트가 View 역할을 한다.
✔ 사용자의 동작을 받는다. (텍스트 입력, 버튼 터치 등)
✔ ViewModel의 데이터를 관찰하여 UI를 갱신한다.
ViewModel
✔ View가 요청한 데이터를 Model로 전달한다.
✔ Model로부터 요청한 데이터를 받는다.
Model
✔ ViewModel이 요청한 데이터를 반환함
✔ Room, Realm과 같은 DB 사용이나 Retrofit을 통한 백엔드 API 호출(네트워킹)이 보편적이다.
특징
◽ View가 유저의 액션을 확인하지만, View에서 바로 DB에 접근하지 않는다. 말 그대로 View이기 때문에 UI를 갱신하는 역할에 충실한다. 대신 ViewModel을 참조하고, ViewModel에서는 다시 Model에서 정리된 데이터를 참조한다.
◽ 또한 View는 ViewModel을 관찰(Observe)한다. DB에 새로운 아이템을 추가한 후에 화면을 업데이트 하라고 직접 명령하지 않아도 된다. View에서는 이미 ViewModel을 관찰하고 있기 때문에 데이터의 변화를 알아차리고 자동으로 화면을 갱신해준다.
장점
◽ View가 ViewModel의 데이터를 관찰하고 있으므로 UI 업데이트가 간편하다.
◽ ViewModel이 데이터를 홀드하고 있으므로 Memory Leak 발생 가능성을 배제할 수 있다. 이는 View가 직접 Model에 접근하지 않아서 액티비티나 프래그먼트 생명주기에 의존하지 않기 때문이다.
◽ 기능별 모듈화가 잘 되어 유지보수에 용이하다.
AAC
구글은 MVVM 패턴을 Android Architecture Component, 즉 AAC로 제공한다. AAC는 앱 구조를 더 튼튼하고 테스트에 용이하며, 유지보수성을 높여주도록 도와주는 라이브러리의 모음이다.
모듈화된 코딩을 돕기 위해 Databinding, LiveData, ViewModel 등의 유용한 라이브러리를 제공하며, 이러한 라이브러리를 사용하여 MVVM 패턴을 조금 더 쉽게 구현할 수 있다.
위의 이미지를 MVVM 구성 요소로 분석해보면 아래와 같다.
◽ View : UI Controller & Observer
◽ ViewModel : LiveData
◽ Model : Repository & RoomDatabase
View
✔ UI를 담당하는 액티비티, 프래그먼트를 의미한다.
✔ 화면에 무엇을 그릴지 결정하고, 사용자와 상호작용한다.
✔ 데이터의 변화를 감지하기 위한 Observer를 ViewModel에 걸어놓는다.
ViewModel
✔ UI에 표현하기 위한 데이터를 가지고 있으며, 구성이 변경(화면 회전, 언어 변경 등)되어도 살아남는다.
✔ AsyncTask는 액티비티나 프래그먼트의 생명 주기에서 자유로울 수 없지만, ViewModel은 View와 분리되어 있기 때문에 액티비티가 Destroy 되었다가 다시 Create 되어도 종료되지 않고 데이터를 유지하고 있다.
LiveData
✔ 관찰이 가능한 데이터 홀더 클래스이다.
✔ View에서 ViewModel의 Live Data를 관찰하게 되면 데이터가 변경될 때, View에게 자동으로 알려주게 된다.
✔ LiveData는 액티비티나 프래그먼트의 생명 주기를 인지한다. 즉, 액티비티가 활성화되어 있을 때만 UI 변경 등의 기능이 동작하게 되고, Destroy 상태에서는 동작하지 않기 때문에 Memory Leak의 발생을 줄여준다.
Repository
✔ ViewModel과 상호작용하기 위해 잘 정리된 데이터 API를 들고 있는 클래스이다.
✔ 앱에 필요한 데이터, 즉 내장 데이터베이스나 외부 웹 서버 등에서 데이터를 가져온다.
✔ 따라서 ViewModel은 DB나 서버에 직접 접근하지 않고, Repository에 접근하는 것으로 앱의 데이터를 관리한다.
RoomDatabase
✔ Room은 SQLite를 사용함에 있어 Query문을 작성할 필요 없이 간편하게 CRUD 동작을 할 수 있게 도와주는 ORM 라이브러리이다.
'Android > Sunflower' 카테고리의 다른 글
[ Android ] [ Kotlin ] Navigation (0) | 2021.12.13 |
---|---|
[ Android ] [ Kotlin ] Hilt (0) | 2021.12.09 |