- 안드로이드의 MVC 패턴은 Controller역할을 하는 Activity(Fragment)가 View에 대한 직접적인 조작을 하게 되어 Activity(Fragment)에 Controller와 View의 역할이 섞여 MVC의 구조에 어긋나는 문제가 생긴다.
- Library : Dagger2, Retrofit2, RxJava2, RxAndroid2, retrofit-rxjava-adapter, retrolambda, recyclerView, glide
- Google android-architecture 참고
- Github api 연동
Model
,View
,Presenter
(이 외 adapter, network, util)으로 구성- View와 Presenter 사이의 연결에 대해 정의한 Contact Interface를 생성
- Fragment가 android view인 경우 Activity는 Fragment와 Presenter를 생성하고, Fragment에서 View를 상속받아 구현
Data와 관련된 전반적인 처리를 Model에서 담당한다. domain클래스를 정의하거나 Presenter에서 데이터 요청이 오면 데이터를 로컬 또는 서버로부터 가져와 데이터를 넘겨준다. android-architecture에서는 Local이나 Remote Repository로부터 데이터를 가져오는 부분을 Presenter가 아닌 Data Layer에 두고있다. 통신 후 Presenter로 데이터를 반환하는 방법 Handler, AsyncTask, Callback, Rx Observer 4가지 중 여기서는 Observable return 방식과 Callback Interface 방식을 사용했다.
사용자의 실질적인 이벤트가 발생하고, 이를 Presenter에 처리를 위임한다. 데이터를 가공하거나 데이터를 가져오는 행위는 View가 아닌 Presenter에서 처리한다. View와 Model에서는 서로에 대한 레퍼런스를 가지면 안된다.(서로의 존재를 모른다) Presenter를 통해서 데이터를 요청하고 반환한다.
View에서 전달받은 이벤트를 처리하고, 결과를 다시 View에 전달한다. 또는 Model에 요청하여 받은 Data를 View에 전달한다.
RecyclerView에서 사용하는 adapter는 화면(Activity)에 필요한 Data를 받아 구성하고, View를 관리한다. 그렇기 때문에 adapter는 View와 Model의 특징을 모두 가진다. View와 Model에 대해 정의한 Contact Interface를 만들어 adapter에서 상속받아 구현한다. 이후 Presenter에서 adapter Model을 통해 데이터를 관리하고, View에서 adapter View를 통해 RecyclerView를 갱신한다.
- View : 이벤트 발생
- View -> Presenter : 이벤트 전달 or 처리 위임
- Presenter : 이벤트의 형태에 따라 이벤트를 바로 처리하거나 Model에 데이터를 요청
- Presenter -> Model : Presenter로부터 데이터를 요청받음
- Model : 서버 API와 통신하여 데이터를 가져옴
- Model -> Presenter : Model로부터 데이터를 받음
- Presenter : 받은 데이터를 가공 (RecyclerView는 8. Presenter -> Adapter.Model : 데이터를 전달, 9. Presenter -> Adapter.View : 뷰 갱신)
- Presenter -> View : 가공한 데이터를 View에 전달
- View : Presenter로부터 전달받은 데이터로 View에서 UI를 갱신