고통스러운 Presenter와 아프지 않은 Presenter

미리 준비하다

MVP 아키텍처, 클린 아키텍처 등에서 프레젠터가 등장했다.
비즈니스 논리를 결합한 결과 등을 액티비티와 프래그먼트의 인터페이스 같은 것에 반영하기 위해서다.
개인적으로 프리젠터가'왜 이렇게 안 어울리지'라고 생각하는 부분을 썼을 뿐인데 여러분들은 어떻게 디자인하셨어요?

고통의 Presenter

프레젠터 자체가 고통스럽다기보다는 기본적인 디자인 마인드가 이런 패턴이다.

API 통신 시작

진행 상태 표시

API 통신 종료 후 진행률 취소

이렇게 Activity와 Fragment가 주도하는 놈이
UseCase/Presenter/Repository가 교묘하게 헤어져도 RxJava에서는 지옥을 외면해도 기본적인 생각은 이렇다. 단지 상태 관리가 복잡해지는 경우가 많다.

interface XXXPresenter {
  void showProgress();
  void hideProgress();
}

이런 디자인 모델이 있다면 이미 고통스러운 디자인 모델이다.

뭐가 아파요?

showProgress()Activity나 Fragment로 반복해서 보여주면 되는데 이런 표현은 경솔하다
실제로 Activity와 Fragment는 안드로이드 프레임워크에 규정된 생명주기를 혼자 가지고 있다.showPregress()온리썸(onResume)~onPause() 사이에서만 호칭을 받을지, 생애주기암을 무시하고 호칭을 받을지 결국 용례와 창고를 보지 않으면 알 수 없는...이런 경우는 쉽게 발생한다.
그리고 차바퀴를 꺼낼 때는 봉인 처리가 필요한가, 아니면 봉인 처리가 필요한가.
봉인이 필요하다면

interface XXXPresenter {
  void showProgress();
  void hideProgress();
  void enableEditor();
  void disableEditor();
}

이렇게 덧붙이면 되나요?저기, 액티비티와 프래그먼트가 하고 싶은 일이 늘어날 때마다 프레젠테이터가 늘어나는 건가요?
편집기를 켜거나 끄는 것은 해야 하는데, 이전 화면으로 돌아가는 것을 막아야 합니까?안 해요?
이런 느낌은 점점 컨디션이 늘어나 영문도 모르게 변한다.
말하자면 프레셔너는 액티비티와 프래그먼트에 대해 그렇게 잘 알고 있겠지?그런 생각도 든다.
　

(상대적으로) 고통스럽지 않은 Presenter

언뜻 보기에는 조립품이 아까보다 늘어나서 더 복잡할 수도 있지만 중점은 거기에 있지 않다.
가장 큰 포인트는 화면의 상태 이동이 사라졌다는 것이다.
Activity/Fragment는 자신의 라이프 사이클을 고려하여 상태 모델subscribe/unsubscribe을 화면에 직접 매핑합니다.
이 경우 UseCase/Presenter 는

class XXXXUsecase {
  void postMessage(String body);

  void subscribeFetchingState();
  void unsubscribeFetchingState();
  void subscribeMessageList();
  void unsubscribeMessageList();
}

interface XXXXPresenter {
  presentFetchingState(int state);
  presentMessageList(List<Message> messages);
}

이렇게 되겠지.
구체적으로 통신에서 무엇을 해야 하는지, Activity/Fragment에 의뢰하여 꼬르륵 소리를 내며 UI를 막는 것은 모두 Activity/Fragment의 자유입니다!
또 UseCase에서 subscribe부터 unsubscribe까지 present XXX()라는 규칙이 있어 라이프 사이클 고려도 쉬워졌다.
　

끝말

android-architectures의 코드를 읽었든 실제로 했든 무심결에 눈에 띄지 않는 부분만 썼다.이것은 사람을 실망시키는 소식이 아니다.
모두들 어떻게 설계했을까, 이 근처