Android MVP Implemenation 종류

Android Development using MVP Pattern은 적용에 있어선 “무조건 이렇게 해야한다” 식의 정설이 있지는 않다. 다만 기본적인 원칙과 MVP를 사용하는 이유 등을 고려하여 팀원들과 토론하여 상황에 맞는 해결책을 탐구하며 개발을 진행해야한다.

MVP in Android!

MVP 패턴을 사용하는 이유

Testability

안드로이드 개발의 근간이 되는 Context: Context는 Unit Tes의 가장 큰 걸림돌이다. Context는 일반적인 방법으로는 JVM 환경에서 Mock이 불가능하며, Unit Test를 하고 싶은 로직에 해당 Dependency가 존재하는 경우 테스트가 불가능하다.

Unit Test를 하는 이유
– 추가 기능 개발 비용 축소
– 개발 디자인 향상
– 많은 팀원과 함께 프로젝트 진행할 시 개발 속도 향상
– 새로 프로젝트에 투입되는 인원 코드 적응 환경 개선

View logic ↔ Business Logic 분리

여기서 Business Logic이라 함은 앱이 구동하기 위해서 존재하는 필수 Create, Read, Update, Delete 로직이라고 생각해도 무방하다. View Logic은 사용자들한테서 가장 근접한 계층의 로직을 포함하며, 뷰와 관련된 모든 로직이라고 보면 무방하다. 분리하게 되면 코드를 가독성이 크게 향상하며 개발 속도가 향상된다

View 로직을 최대한 멍청하고 단순하게 만든 뒤, Presenter는 Android API를 전혀 사용하지 않는 로직만 구현한다고 생각하면 편하다. 최상의 시나리오는 View 레벨 코드에는 if 문이 하나도 존재하지않는 케이스이다.

Maintainable Code

결론적으로는 유지보수가 편리한 코드가 생성됨으로써 새로운 기능추가 혹은 오래된 코드를 수정할 시에 불필요한 시간을 소모할 일이 적어진다.

MVP 구현 방식 케이스 스터디

Clean Architecture

Clean Architecture Repo

Fernando Cejas 의 Clean Architecture 같은 경우는 Presenter interface 같은 경우 기본적인 lifecycle method만 가지고 있으며, View 는 인터페이스로 필요한 method들을 가지고있다. Clean Architecture 같은 경우는 View Interface 를 보면 Context 를 제공하는 인터페이스를 가지고있으며, 이것은 나중에 다른 협엽하는 개발자들이 남용하게 될 가능성이 매우 크며 권장하지 않는다. MVP로 완전하게 이전하기 위해서는 View에서 presenter 로 context 를 던져줄 필요가 없어야 하기 때문이다.

u2020

u2020-mvp Repo

U2020-mvp 같은 경우는 Jake Wharton 의 u2020을 MVP로 port 시킨 프로젝트인데 BasePresenter 를 abstract class로 구현하여서 View와 1:1 관계를 고정한다. takeView() 가 호출될 때 WeakReference로 들고 있으며 dropView() 가 호출되면 릴리스시키며 메모리 누수를 방지한다. Abstract Class로 interface를 구현하여서 다른 사람들이 Base Presenter를 잘못 사용할시에 NullPointException 를 던져주는 친절한 API까지 제공하게 구하고있다.

u2020

Android Blueprint Repo

Google Blueprint는 구글에서 발표한 아키텍처 시연 집합 프로젝트다. 구글이 직접 서술했듯이 안드로이드 구조는 매우 유연한 기능들을 제공하기에, 구글의 방식이 무조건 맞는다는 뜻은 아니다. Contract Interface를 이용하면 기존의 다른 MVP 방식보다 불필요한 interface가 하나 늘긴 하지만, View와 Presenter의 인터페이스가 어떤 식으로 서로 작동하는지 한눈에 볼 수 있다는 장점이 있다. 하지만 사실 코드를 작성하다 보면 Contract 파일이 별도로 필요한지는 의문이 들 때도 있다.