LegoLibrary 앱 리팩토링 [1]

ic_launcher

첫번째로 간단한 정보(달러 환율)를 서버로부터 가져오는 RX인터페이스를 구현하기로 했다. API에 대한 정보는 다음과 같다.

  • Description
    • 어느 특정한 사이트로부터 최소한의 us달러 환율 만 가져 온다.
  • Request
    • request parameter : 없음.
  • Response
    • content-type : application/x-www-form-urlencoded; charset=utf-8
    • response : String only
    • error code
      • “ERROR” : 모든 오류 상황 시 반환.

목표는 다음과 같다.

  • RxAndroid와 Retrofit2, OkHttp3를 활용 하여 비동기로 서버 콜을 하여 달러 환율 정보를 얻고 언제든지 사용할 수 있게 만들어 준다. 
  • 오류 발생시 예외 처리 코드를 만든다. (간단한 토스트 메시지로 일단 처리)
  • MVP패턴을 적용하여 model과 view를 분리하고 presenter를 통해서만 데이터의 get/set을 하게 한 뒤 view를 세팅 하게 해 준다. 

 

구현할 기능들을 다이어그램으로 정리하면 다음과 같다.

ref_002

  1. Adapter (RetrofitAdapter class)
    • Retrofit2을 사용 할 수 있게 인스턴스를 생성하고 싱글톤 패턴을 적용 하여 단 한개의 인스턴스만 존재 하게 한 클래스 이다.
    • Http 로그들을 확인 할 수 있게 하기 위해서 OkHttp3의 ‘httpLoggingInterceptor’을 HttpClient빌더에 인터셉터를 달아주고 사용 한다.
    • 최소 타임아웃(기본, 쓰기, 읽기)시간을 설정 한다.
    • data bean과 Rx를 사용 하기 위해서 ‘GsonConverterFactory’와 ‘RxJavaCallAdapterFactory’를 설정 한다.
    • MVP에서 Model등에서 getInstance()를 호출하여 사용 하게 한다.
    • 장점
      • 싱글톤으로 구성 되어 있어 getInstance()메소드를 통해서 바로 사용 가능.
      • 로그 출력을 가능하게 되어 http request, response 들의 header정보나 status code를 확인 가능. response의 경우 body의 내용까지 나옴.
    • 단점
      • NJobService라는 네트워크 API를 명시한 인터페이스에 종속적이다. 만약 다른 네트워크 API서비스를 사용 하기 위해서는 동일한 서비스 네트워크를 만들고 내부를 수정 해야 한다.
      • 이에 대해선 나중에 Builder디자인 패턴을 적용 하여 필요한 데이터를 적시에 설정 하고 인스턴스를 build-create 하여 얻는 방식을 생각 중 이다.
  2. Retrofit network API interface (NJobService)
    • 서버와 통신을 위한 API를 명세 하는 인터페이스. Retrofit에 interface의 class파일을 기반으로 서비스를 등록 한 뒤 생성된 서비스 인스턴스를 통해서 인터페이스의 추상 메소드들을 콜 하는 형태 이다.
    • 기본적으로 Call<T>이라는 인터페이스 콜백을 지원 하지만, Rx를 위하여 Observable<T>도 지원 한다.
    • Rx와 기본적인 형태를 2개 만들었다. Rx를 지원하는 Observable의 data type이 ResponseBody임을 잘 봐두도록 하자. 이 ResponseBody를 통해서 데이터를 얻고 가공하게 될 것이다.
  3. Model class (MainActivityModel)
    • 서버에 환율 정보를 요청하고 받은 Observable<ResponseBody>를 구독하는 Subscribe를 설정 하는 메소드와 환율정보를 멤버로 받고 get/set하는 메소드 들이 있다.
  4. Presenter class (MainActivityPresenter)
    • Presenter와 1:1로 매칭되는 View인터페이스를 구한한 Activity에 데이터를 전달 하고 View layout을 갱신하도록 한다.
    • Activity에서 Presenter를 통해 데이터를 요청 하고 난 뒤 콜백이 Call객체나 Observable을 생성하면 그에 따른 후처리를 한다. 만약 Observable을 받게 되면 이를 구독하는 Subscribe를 구현한 객체를 통해서 데이터를 가공 하고 난 뒤에 View의 인터페이스 추상 메소드를 호출 하여 View를 구현한 Activity나 Fragment에 가공된 데이터를 전달 하고 View를 업데이트 하게 해 준다.
    • Activity에서 Presenter를 onCreate()메소드에서 등록 시 새성자를 통해서 등록 하는데 등록 하면서 model객체를 만든다.
    • 그리고 Activity에서 Presenter에 View인터페이스를 등록 한다. 이는 Activity내 에서 내부 익명 클래스던, 구현한 클래스던 상관없다.
    • View 인터페이스는 BaseView인터페이스를 상속 받고 있는데 조상 인터페이스로서 대부분의 공통 적으로 사용되어질 거라 생각되는 처리를 넣을것 이다. 현재로서는 네트워크 통신 중 오류가 발생했을때의 처리를 할 콜백 메소드가 있다. 해당 소스는 다음과 같다.
  5. Activty (MainActivity – View)
    • Presenter를 통해서 전달받은 model의 데이터를 이용하여 화면을 갱신하는 클래스 이다.
    • ButterKnife를 이용해서 view, dimension, string 등의 리소스 값을 바인딩 해서 사용 한다.
    • Presesnter에 1:1로 매칭되어 사용 될 View인터페이스를 구현해야 한다.
    • Presenter의 View 인터페이스를 구현한것을 확인 할 수 있다.

 

RxAndroid의 진입 장벽은 높다. 환율을 가져오는 간단한 처리라면 그나마 간단한 편이지만, 기존에 만들던 복잡한 인터페이스 콜과 그에 따른 콜백에 콜백, 그리고 애니메이션과 화면의 갱신까지 들어가게 되면 정말 정신 없을 것 이다.

기존에 개발을 하다보면 비슷한 기능을 가진 메소드들을 중복으로 만드는 일이 잦았다. 게다가 일정등에 대한 압박까지 있다보면 찾을 시간이 없는 것이다. 그런데 Presenter에서 View인터페이스를 구현하면서 일괄적으로 확인이 가능 하니 이럴때 필요한 메소드를 찾아서 수정 하고 하는게 편해 보였다.

하지만 단점이 있다면 아무래도 각 화면단(Activity, Fragment)마다 이러한 인터페이스를 만들고 화면에 종속시켜줘야 한다는 것 이다. 이는 기능의변화가 생기면 View인터페이스와 이 View를 구현하는 화면단까지 수정을 가해야 하는 것이다. 혼자서 개발을 한다면 이게 귀찮을 수도 있다. 그래서 View인터페이스가 아닌 직접 Activity의 뷰 갱신 메소드를 presenter에서 호출 하는 경우도 있다고 한다.

이제 막 입문한 MVP와 Rx에서는 아직 낯설고 어렵게만 느껴진다. 다음에는 간단한 목록들을 가져와서 gson을 통해 json을 파싱하고 화면을 갱신하는 기능을 만들어 보려 한다. 언제가 될런진 모르겠지만..

 

  •  과거에 작성한 글

 

 

You may also like

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.