안드로이드, 구글 라이브러리 AAC 따르기 [1]

- Fragment : Fragement가 뷰의 재활용을 위해 사용한다고 생각은 하겠는데, Activity의 기능을 모두 Fragement로 넣으려고 하니까 더 불편한 게 많다. LifeCycle이 start, resume 어디에 타는지 모르겠고 create 될 때를 start라고 보고 resume 대신 stop 될 때라고 봐야하나. 근데 소스따라 가보니까 start stop 모두 오버라이딩 가능하네! 우선 기본적으로 MainActivity에서의 Lifecycle에 따라서 활동하던 동작들 중에서 꼭 자체적으로 한번만 실행해야 하는 것들은 MainFragmentActivity로 이동시켰다. 

- Vew / ViewModel : 활동성을 기준으로 하나의 View에서만 처리해야하는 것들을 Fragement로 넣고 해당 View에 대한 데이타 처리를 위한 클래스를 ViewModel로 만들었다. 이렇게 보니까 소스가 확실히 간결하고 해당 클래스별 의존성 관계를 확실히 알 수 있었다. 쓸 데 없이 하나의 Activity에서 모든 걸 처리하는 기존 나의 소스는 MVC 라고 생각했었는데 의존성이 엄청 강한 Controler 였다는 것을 새삼 확인했다. 그러면서 이전 회사에서 설계한 아키텍처를 다시 생각해보게 된다. 

- ConstraintLayout

- ButterKnife : findViewById 성능을 개선하기 위한 라이브러리. 하지만 코틀린으로 개발하니까 ButterKnife를 쓰지 말고 아래의 ViewBining을 쓰라고 한다.

- ViewBinding : gradle 설정에 enable 설정만 하면 되니까 쉽게 사용 할 수 있다. 따로 ButterKnife랑 차이가 있는 것은 XML 레이아웃에 선언을 하지 않아도 되고, 바인딩 객체를 이용해서 기존 findViewById을 사용하지 않아도 쉽게 참조할 수 있으니. 면접 때 이야기 들었던 것도 ViewBinding에서 성능이 더 좋기 때문이라는 걸. 원했었지? 사용 측면에 있어서는 직접 참조를 하지 않아도 바인딩이 되기 때문에 쉽게 참조할 수 있다는 장점인 것 같다. 코틀린 언어로 개발해보면서 현재는 ViewBinding을 계속 이용할 생각이다.

- Retrofit2 : 나는 통신 모듈을 구현해서 개발해왔다. 자세히 기억나지는 않지만 사원 시절 대리님이 구현한 아파치 오픈 소스 통신 모듈이 deprecated 되는 것을 알게된 쯤 나는 HttpURLConnection 클래스를 이용하여 나만의 통신 모듈을 만들었다. 그리고 Callback 통해 결과를 응답받기 위해 interface 리스너를 구현했다. 그렇지만 성능은 생각하지 않았다. 성능보다는 개별적인 예외 상황에 따른 Exception 처리와 기능에 필요한 커스터마이징을 하기 위함이었다. 이제는 성능과 구조를 생각할 때. Retrofit2를 이용하면 내가 이전에 만들었던 통신 모듈을 모두 제거하기 시작해야 했다. 한번 만들어진 기능을 모두 바꿔야 할 때 얼마나 귀찮은가. 그리고 Retrofit을 사용하기 시작하면서 데이터를 담을 클래스를 매핑해야 하는 작업을 하는데 이 부분도 웹에서 VO 단, 각자 통신할 REST API를 열거하는 RetrofitService는 웹의 서비스단과 같은 구조를 가진다.는 것을 알게 되었다. 지금은 일단 변환 작업부터 하고 나서 래퍼하며 예외적인 클래스를 가져보도록 하자!