2014-07-11 2 views
8

MVP (Model-View-Presenter)는 GUI 애플리케이션을위한 잘 알려진 디자인 패턴입니다. Android의 경우 일반 Java 모듈에서 비즈니스 로직을 구현하면 Android 에뮬레이터 없이도 테스트가 가능합니다. 때문에 안드로이드 응용 프로그램의 GUI에 대한 특별한 요구 사항의 안드로이드에 패턴을 구현안드로이드에서 Model-View-Presenter 구현상의 어려움

그러나, 나는 데 어려움 : 활동이 어느 시점 (걸려 오는 전화에 손상 될 수 있습니다

  • 는 사용자가 홈 버튼을 누르면 ...), 그리고 그것을 다시 만들 때 그것이 남겨진 때와 똑같은 상태에 있어야합니다. 이것은 다른 대부분의 GUI 응용 프로그램과는 다릅니다.

  • 활동은 여러 라이프 사이클 상태를 거칠 수 있습니다. 활동의 UI를 수정해서는 안되는 경우 일시 중지 될 수 있습니다. 예를 들어 일부 데이터가 백그라운드에서로드되는 경우 일시 중지 된 상태 인 경우 MVP (활동)의보기 부분으로 전달할 수 없습니다. 다시 말하지만, 이것은 일반적이지 않은 요구 사항입니다.

나는 블로그 게시물 MVP for Android을 읽고 example source code 살펴 보았다. MVP 패턴을 사용하여 달성하고자하는 최종 목표는 transpiler j2objc을 사용하여 모든 비즈니스 로직을 Objective-C로 변환 할 수있어 iOS에서 동일한 애플리케이션을 구현하면서 비즈니스 로직을 재사용 할 수 있도록하는 것입니다.

Android 용 MVP 패턴을 성공적으로 구현 한 사람이 있습니까? 그 경우 무엇이 누락 되었습니까?

+0

내가 궁금해하는 점은 비즈니스 로직 모듈이 '컨텍스트'가 필요없는 일반 자바 인 경우 왜 '활동'수명주기가 중요합니까? 다른 말로하면, 왜 특별한 GUI 요구 사항이 문제가되는 것입니까? – Blacklight

+0

MVP의 '보기'부분이 특정 시점 (일시 중지되었을 때)에서 업데이트되지 않을 경우 '발표자'또는 '모델'을 모르면 안됩니까? 'Model'은 나중에 복원 될 수 있도록 만들어지지 않아야합니까? – foens

+1

활동은 라이프 사이클을 관리하고 필요에 따라 발표자를 설정/일시 중지/해제하는 책임이 있다고 주장 할 수 있습니다. 발표자는 시스템 종속적 인 UI 프레임 워크 단점에 대해 현명한 사람은 아닙니다. – dcow

답변

4

Activity를 사용하지 않고 MVP 구성 요소를 구현하는 것이 좋습니다. 개념적으로 안드로이드와 GWT에서 유용 할 것이 무엇인지 생각할 수도 있습니다. mocked View 인터페이스로 테스트 주도 개발을 사용하여 컴포넌트를 생성하고 비즈니스 로직이 완벽하게 구현 및 검증 될 때까지 테스트를 추가하십시오. TDD는 구성 요소의 API를 쓸데없이 (왜 필요하지 않은 것들에 대한 테스트를 작성합니까?) 유지하므로 구성 요소를보다 쉽게 ​​이식 할 수 있습니다.

설명하는 활동 요구 사항은 플랫폼 독립적 일 수 있습니다. 구성 요소는 직렬화 가능해야하며 (특히 Java 직렬화가 아닌 작은 것) 라이프 사이클 상태 이벤트를 받아 들여야합니다. 그것도 시스템 기능을위한 모의를 사용하여 완전히 테스트 할 수 있습니다. 이 단계를 진행할 때, Android 요구 사항 중 일부는 반드시 Android에만 해당되며 다른 플랫폼에서도 유용 할 수 있습니다. 거대한 서비스 API 생성을 피하십시오. 예를 들어, 직렬화를 지원하려면 Parcel API이 아닌 store/load 메소드가 필요합니다. 화이트 보드에 다른 개발자에게 그러한 서비스 API를 설명하는 것이 불필요한 솜털 모양을 찾는 훌륭한 방법이라는 것을 알았습니다.

다음으로 구성 요소를 위임 한 액티비티를 생성하고 조롱 된 인터페이스에 대한 Android 전용 구현 클래스를 제공하여 구성 요소를 Android에 포팅하십시오. 처음에는 모두 "제대로 작동"해야하지만 실제로는 일부 요구 사항이 누락되었을 수 있으므로 플랫폼 독립적 인 부분에 추가하고 반복하십시오.

iOS로 포트 할 준비가되면 이전에 조롱 한 인터페이스를 다시 구현하십시오. 이러한 인터페이스가 희박한 경우 j2objc가 생성 한 프로토콜 헤더를 가져 와서 Objective-C에서 직접 생성하는 것이 더 쉬울 것입니다. 예를 들어, j2objc의 NSDictionaryMap 클래스는 NSDictionary 구현을 사용하여 java.util.Map을 구현합니다. iOS API 만 사용하여 Java 버전을 작성하고 변환 할 필요가 없습니다.

+0

안녕하세요. 감사합니다. 나는 그 구성 요소가 무엇인지 완전히 확신하지 못합니다. 발표자에 대해 말하는거야? 귀하의 포스트에서 나는 [Presenter-First] (http://atomicobject.com/files/PresenterFirstAgile2006.pdf)라고 불리는 구현 프로세스를 실제로 설명하고 있다고 느낍니다. 보기는 인터페이스 (플랫폼 특성 없음) 여야하며 Android에서의 활동에 의해 구현되어야합니다. 나는 저장 /로드 절차를 구현하는 데 상당한 노력을 기울일 것이며, 이는 또한 Android 레크리에이션 프로세스의 재 구현이라고 생각합니다. – foens

+0

결합 된 MVP "단위"를 구성 요소라고 부르겠습니다. 더 좋은 이름이 있습니까? 사용 가능한 용어가 모두 과부하 된 것처럼 보입니다. Presenter-First에 관해서는 당신이 옳았습니다. 제가 그 논문을 읽지 않았기 때문에 링크를 이용해 주셔서 감사합니다. 저장 /로드는 Parcel 또는 Java의 직렬화와 같은 플랫폼 관련 보관 서비스에서 외부에서 호출해야합니다. 모든 구성 요소는 자체 저장소/복원을 처리해야합니다. 서비스를 제공함으로써 안드로이드 특정 코드는 안드로이드 애플 리케이션이 일반적으로 사용하는 동일한 코드를 사용하게됩니다. – tball

1

Android의 MVP 변형은 앱에서 비즈니스 로직을 격리하기위한 올바른 방향으로 나아가는 단계입니다.그러나 문제를 더 잘 분리하고 더 재사용 할 수있는 도메인/비즈니스 로직을 얻으려면 Presenter First pattern을 사용하는 것이 좋습니다 (간략히 언급 한 내용을 참조하십시오). 감소하는 커플 링을 제외하고는 TDD와 잘 어울리 며 모든 비즈니스 로직을 단위 테스트 할 수 있습니다.

저는 최근 Android 용 Presenter First 예제를 사용하여 GitHub 저장소를 시작했습니다. Android 아키텍처의 복잡성으로 인해 패턴을 구현하기가 쉽지 않습니다. 일반적으로 프리젠터 퍼스트 앱에서 볼 수있는 것보다보기 싫은 경향이 있습니다. 이는 주로 활동 라이프 사이클 및 기타 이상한 점 때문입니다. 비즈니스 로직을 플랫폼에서 분리하기 위해 최선을 다했지만 개선해야 할 부분이 있습니다. 어쩌면 당신은 거기에서 몇 가지 아이디어를 사용할 수 있습니다

http://github.com/olerass/presenter-first-android

: 당신은 예제를 찾을 수 있습니까? 또는 자신의 일부를 더 잘 기여할 수도 있습니다.