Android MVP
원문 : http://antonioleiva.com/mvp-android
원문 내용이 길지 않으니 직접 읽어보면 좋을 것 같다.
이 글에서는 View와 Controller 로직을 모두 가지고 있는 Android Activity의 문제를 해결하여 Activity는 View 로직만 갖도록 만드는 방법에 대해서 설명한다. 이 방법 외에도 MVVM이라는 것도 있으나 개인적으로 이 방법이 좋아 보인다. 특히 저자는 Robert C. Martin의 Clean Architecture에 부합하는 구조 보여주고 있다고 생각되어 더 호감이 간다.
주요 흐름
1. View(Activity, Fragment,...)에서 이벤트가 발생하면 View는 Presenter 인터페이스의 메소드를 호출한다
2. Presenter의 구현체는 Interactor(use case handler)를 호출하여 원하는 결과를 얻는다. Interactor는 Presenter에 결과를 제공하기 위해 비즈니스/도메인 계층을 호출한다.
3. Interactor의 구현체는 비즈니스/도메인 레이어 호출을 완료하면 Presenter의 구현체가 구현하는 Listener를 호출함으로써 결과를 반환하거나 제어만 반환한다.
4. Presenter 구현체는 화면을 갱신하기 위해 Activity가 구현하는 View 인터페이스의 메소드를 호출한다.
주요 역할
Activity에 있던 기능들은 View와 Presenter로 나눠진다. 각각의 역할은 아래와 같다.
View의 역할
- 화면을 구성
- 사용자 행위가 일어나면 Presenter로 위임
- Presenter가 제공하는 포맷팅 된 결과를 화면에 갱신
Presenter의 역할
- 사용자 상호작용을 처리하기 위해 Interactor 인터페이스 호출
- Interactor로 부터의 결과를 수신하기 위해 Listener 인터페이스 구현
- Interactor로 부터의 결과를 View 갱신하기 위해 View 메소드 호출
테스트 가능성
Activity는 테스트하기 참 어려운 대상이다(robolectric과 같은 프레임워크를 사용하더라도). 이런 테스트하기 어려운 대상에는 최소한의 로직을 두어 테스트가 거의 필요치 않도록 하는 것이 좋은 전략이다.
Robert C. Martin은 Humble Object라는 기법을 소개하는데 이 기법은 Interface에 의해 테스트가 거의 필요치 않은 로직과 테스트가 자동으로 수행되어야 하는 로직을 분리하는 기법으로써 Humble Object는 너무나도 초라하여 테스트할 가치가 없는 객체를 의미한다. IO를 제어하는 객체 등이 속한다(DB, GUI 등을 제어하는 객체도).
MVP는 위와 같이 Presenter, Interactor, Listener, View 인터페이스를 통해 강력하게 얽힌 의존 관계를 느슨하게 만들어서 테스트 가능성을 높였다.
Presenter 구현체, Interactor 구현체 등 주요한 로직은 자동 단위 테스트가 가능할 것으로 보인다(테스트를 먼저 만들면서 개발을 진행할 수도 있을 듯). 그리고 View의 구현체(LoginActivity)는 Fake(Simulator)를 통해서 눈으로 보면서 수동 테스트가 가능하나 너무나 초라하여(Humble Object) 테스트를 자주 할 필요가 없는 대상이 되었다.
결론
GUI 애플리케이션은 UI 위젯으로 인해 복잡한 의존성을 가지고 있고, 테스트하기 어려운 것이 일반적이다. MVP는 안드로이드 앱을 테스트하기 좋은(좋은 설계를 갖는) 앱으로 만드는 방법 중 하나라고 생각된다. 실 서비스에 적용해 보진 않았지만 조만간 테스트 가능한 앱 기능 구현을 시도하고 정리하는 시간을 갖고자 한다.
