하루하루 개발공부

예제 참고  https://github.com/android/architecture-samples/tree/todo-mvp todo-mvp 전체를 분석하기에는 양이 너무 많기 때문에 참고하여 간단하게 MainActivity와 프래그먼트를 구현한 예제를 통해서 mvp를 알아보도록 하자.  실행화면 기능은 제외하고 todo-mvp에서 구현한 mvp의 껍데기만 남겨놓았다. (실제 todo-mvp와는 조금 다르다)  메인 액티비티에서 영상, 기록, test 3가지의 프래그먼트를 보여주고 있다.  Navigation Drawer를 사용하여 왼쪽에 네비게이션 뷰를 구현하였고 그안에있는 내정보, About, Notice를 클릭했을때 각각 구분하여 토스트 메시지를 띄워주는 상태이다. 현재 상태에서 mvp를 어떤식으로 구현하였는지 살펴보고 기능을 하나씩 추가해보면서 분석해보도록 하겠다.  클래스 구조  이미지 1 todo-mvp 구조  mvp형태는 그대로 가지고 있으면서 Contract, BasePresenter, BaseView 인터페이스가 추가되었다. 프래그먼트가 어떠한 방식으로 액티비티에 표시되는지 자세히 보도록 하자.  이미지 2 todo-mvp UML 프래그먼트가 표시되는 과정을 간략하게 표현하면 이미지 2와 같다. 번호 순서대로 하나하나 씩 분석해 보았다.  1. BaseView<T> 인터페이스 public interface BaseView < T > { void setPresenter ( T presenter ) ; } - 특정하지 않은 형태를 제네릭으로 지정하는 인터페이스이다.  * T는 Contract에서 생성할 Presenter가 지정된다.  - Presenter를 입력하는 setPresenter()메소...

MVP패턴이란? 안드로이드에서 MVC 패턴에 대해 떠올려 보면 Model은 분리되어 있고 View와 Control이 함께 있는 구조라는 것이다. 그 예를 Activity로 들 수 있고 실제로 Activity 내부에서 View와 Control에 관련된 내용들을 모두 구현할 수 있고 그렇게 해왔다. 그러면서 Activity라는 하나의 클래스에 굉장히 많은 로직이 포함되고 코드줄이 길어진다는 문제점이 발생한다는 것도 기억해보자.  - Model, View, Presenter의 약자 - 안드로이드에서 MVC 패턴 중 View와 Control이 함께 공존하는 문제점 해결 - 안드로이드에서 가장 많이 사용하는 패턴 *Model : Data와 관련된 처리 / MVC의 Model과 동일하다. *View :  이벤트가 발생하면 Presenter로 알림 *Presenter : View에서 전달받은 이벤트를 처리하여 다시 View로 반환 MVP는 View와 Control이 묶이지 않도록 한다. 이미지1 MVP 동작 순서 1. View/Control: 이벤트 발생 2. View/Control: 이벤트를 Presenter에 알림 3. Presenter : 이벤트 수신하고 이벤트 형태에 맞게 Model에 데이터 요청 4. Model : Presenter의 요청 확인 5. Model : Presenter에 데이터 전달 6. Presenter : Model로부터 전송받은 데이터를 가공하여 View/Control로 전달 7. View/Control: Presenter로부터 전송받은 데이터에 맞게 UI 갱신 상황에 따라 Presenter에서 Model에 데이터를 요청하지 않을 수도 있지만 기본적인 형태는 위와 같다. *View가 아닌 View/Control이라고 표기한 이유는 안드로이드에서 기본적으로 View와 Control이 공존한다는 것을 표현한 것이다. 지난 MVC 글에서 안드로이드 MVC의 동작순서를 보면 Vi...

디자인 패턴 mvc - mvp - mvvm을 사용해보기위해 공부해보니 안드로이드 개발 시 사용하는 디자인패턴이라는 것을 알게되었다.  그렇다면 먼저 디자인 패턴에 대해 공부를 해봐야 할 것 같아서 찾아보기 시작했는데 공부해야 할 것이 너무 많다... 앞으로 꾸준히 해야 한다고 생각하고 여기서는 간단하게 개념만 정리한 후 예제를 만들고 실제 프로젝트에 적용해보면서 공부해 나가도록 하겠다.  디자인패턴이란 무엇인가? - 여기서 다루는 디자인패턴이란 '소프트웨어 공학'의 개념이다. - 프로그래밍할 때 다양한 문제 상황에 대한 재사용 가능한 해결책이다.   *일반적인 문제를 해결하기 위해 최선의 방법을 공식화 혹은 정의 하는 것   - 패러다임과 알고리즘과는 다르다.   * 객체지향 패러다임이든 함수형 프로그래밍 패러다임이든 문제상황은 일관되기에 패러다임과 디자인패턴은 동의어가 될 수 없다. 또한 어떠한 알고리즘이라도 마찬가지로 문제상황은 일관되기 때문에 알고리즘과도 동의어가 될 수 없다. 디자인패턴은 일반화된 해결책이다.  - 디자인 패턴은 객체지향 패러다임의 개념이 아니다.   * 디자인 패턴에 대한 내용을 보면 객체지향 패러다임에 국한된 내용들이 많은데 엄밀히 말하면 아니다. 디자인 패턴이 반드시 객체지향에 적합해야 할 필요는 없다. 다만 객체지향이 굉장히 유용한 패러다임이기 때문에 이에 대한 연구가 더 많이 진행되었던 것이다.  - Creational(창조), Structural(구조), Behavioral(행동)으로 구분한다.  * 클래스와 인스턴스에 관한 생성, 구조화, 행동과 관련있다. 여기서 디자인 패턴이 객체지향에 초점을 맞추고 있음을 알 수 있다. Creational patterns - 'Creat'이라는 어미에 맞게 클래스의 인스턴스를 만드는 것과 관련있다. - Class creation patterns : 상속을...