[Android] 안드로이드 개발 레벨업 교과서 정리 #5 다양한 설계 기법

출처 : 안드로이드 개발 레벨업 교과서 130~132p

안드로이드 앱을 개발할 때 어떤 설계를 하는가? 액티비티에 모든 기능을 구현하다가 그만 거대한 액티비티를 만들어본 경험이 있는가? 액티비티가 너무 커지면 다음과 같은 문제가 발생한다.

• 역할별로 처리가 나뉘지 않아 코드의 가독성이 떨어진다.
• 다양한 구현이 저마다 멤버 변수를 수정하면 수정 시 영향을 예측하기 어렵다.

현재 이러한 문제점에 대처할 수 있는 MVP나 MVVM 등과 같은 설계 기법이 주목받고 있다. 이번 절에서는 이러한 설계 기법에 대해 배운다.

1. MVP를 이해하자

MVP는 사용자 인터페이스를 구축할 때 이용하는 설계 기법이다. MVP는 Model View Presenter의 머릿글자로, 이 구현에 따라 Model, View, Presenter 라는 세가지 역할로 처리를 나눌 수 있다.

Model에는 데이터와 비즈니스 로직이 들어있고, 이곳에서는 UI에 관한 로직은 가지지 않는다. 데이터베이스나 API 접근에 관한 처리는 여기에 포함된다. View는 데이터를 표시한다. 또한 사용자의 탭 등 액션은 뷰에서 처리하지 않고 Presenter에 위임한다.

Presenter는 Model과 View 사이에서 서로 통신한다. View에서 발생한 이벤트가 Presenter에 알려지면 Presenter는 그 이벤트에 대응하는 처리를 수행한다.

View가 직접 Model에 접근하거나 반대로 Model이 직접 View에 접근하는 일 없이, View와 Model 사이에는 항상 Presenter가 들어간다. Model이나 View의 실체인 인스턴스를 Presenter로부터 직접 참조하게 하지 않고, 인터페이스 등을 이용해 접근할 수 있게 한다. 이렇게 하면 테스트 시에 목 객체(Mock Object)로 대체할 수 있어 테스트가 용이하다.

MVP 설계의 장점

Model, View, Presenter로 역할을 명확히 나누므로 처리 내용이 어디에 있는지 명확하게 구분할 수 있고 코드 관리 효율이 높아진다. MVP 패턴으로 설계하면 필연적으로 역할을 나눠야 하기 때문에 액티비티에 구현을 채워넣을 수 없게 된다. 결과적으로 처리를 나눌 수 있어 액티비티를 작게 만들 수 있다. 또한 View와 Model 사이에 Presenter가 들어가므로 View와 Model의 의존관계가 사라진다.

MVP 설계 기법 참고 사례

MVP 설계의 단점

Presenter는 인터페이스를 통해 View와 Model에 접근하므로 그들의 위치를 인터페이스로서 정의할 필요가 있는데, 이 부분이 길어지기 쉽다. 또한 Model에서 가져온 데이터를 View에 표시하는 것을 개발자가 직접 구현해야 한다. 안드로이드에는 기본적으로 MVP 패턴을 지원하는 프레임워크가 없기 때문에 어떻게 UI 로직을 Presenter로 분리하는가 하는 설계상의 어려움이 단점이 된다.

2. MVVM을 이해하자

Android Gradle Plugin을 통해 DataBinding이 지원된다.

DataBinding은 사용자 인터페이스와 데이터를 연결하는(바인딩하는) 메커니즘이다. DataBinding을 활용한 설계 기법으로 MVVM(Model View ViewModel)이 있다. MVVM은 MVP 등과 같이 UI 로직을 분리할 수 있다.

Model에는 MVP의 Model처럼 데이터와 비즈니스 로직이 들어간다.

View는 데이터를 표시한다. MVP와 달리 ViewModel이 Model에서 가져온 데이터를 반영해서 표시한다. ViewModel이 가진 값이 DataBinding으로 자동적으로 뷰에 반영되므로 View 부분에서 반영하는 구현을 할 필요가 없어진다.

하지만 안드로이드에는 애니메이션이나 액티비티 전환 등 ViewModel에서 구현하기 어려운 항목이 있다. 그런 부분은 View에서 구현하면 된다. 기본적으로 ViewModel은 뷰의 상태와 UI에 관한 로직을 구현하고, DataBinding을 통해 ViewModel의 상태가 View에 반영된다. 또한 뷰 클릭 등의 이벤트를 ViewModel이 받고 Model과 데이터를 주고받아 DataBinding으로 View의 상태를 갱신한다.

MVVM 설계의 장점

MVP 패턴처럼 역할을 분리할 수 있으므로 액티비티를 작게 만들 수 있다. 또한 DataBinding으로 MVP일 때 기술하는 Model에서 가져온 데이터를 View에 반영하는 로직도 작성할 필요가 없으므로 액티비티의 코드를 많이 줄일 수 있다. Presenter와 마찬가지로 View에 의존하는 코드가 없어 테스트가 용이해진다.

MVVM 설계의 단점

바인딩에 대한 처리는 자동으로 생성되므로 데이터 바인딩 처리는 블랙박스화 되어있다. 자동으로 생성된 코드는 일반적으로 가독성이 낮고 디버그하기가 어렵다.

★ 할일 : 책에는 AAC ViewModel을 사용하지 않고 MVVM 패턴을 구현했으니, 코틀린으로 AAC ViewModel 사용해서 작성해보기!