[Kotlin Android] View 객체 가져오기(3) - DataBinding

지난 ViewBinding 포스팅에 이어서 DataBinding에 대해 다루어 볼까 합니다.
특히 DataBinding은 MVVM 패턴을 구현하는 데에 많이 사용했으나 Maintanence Mode로 관리되고 있는 라이브러리가 되었고, 이로 인해 DataBinding 사용을 지양해야 하는 이유를 포스팅 해보려고 합니다.

ViewBinding vs DataBinding

---

기본적으로 DataBinding은 ViewBinding의 역할을 할 수 있다.

• 속도의 차이 (ViewBinding이 더 빠르다.)
• DataBinding은 <layout> 태그를 사용하여 만든 레이아웃을 처리하고, TAG를 삽입한다.
• ViewBinding은 단방향 바인딩을 지원한다. -> DataBinding은 양방향 바인딩을 지원한다.

결론

DataBinding이 모든 역할을 할 수 있지만, 단순히 findViewById()를 대체하기 위한 것이라면 ViewBinding을 사용할 것을 권장하고 있다.(∵ 속도가 더 빠르고 용량 절약)

DataBinding의 특징

(참고: Why we should stop using data binding in Android)

> Pros

• 양방향 바인딩 지원
• 가독성 향상 { 보일러 플레이트를 줄여줌 MVVM 패턴 구현을 단순화 }
• 타입 안전성 향상 { 컴파일 타임에 데이터의 타입을 체크하여 런타임 에러 감소 }
• 성능 향상 { UI 업데이트에 필요한 코드 감소 }
• LiveData와의 손쉬운 통합

> Cons

• 강결합된 코드 베이스 { 기본 클래스 사용이 어려워짐 }
• 관심사의 분리 { UI와 데이터를 조작하는 코드가 섞여있어 이해하기 어려움 => 유지보수 비용 증가}
• 테스트 및 디버깅의 어려움 {
  • 컴파일 시에 생성되는 코드가 있는데 이는 프로젝트에서 볼 수 없기 때문에 발생하는 문제를 추적하기 어려움
  • 단위테스트가 어려워짐
    }

DataBinding is in Maintenance Mode

---

DataBinding은 KSP의 업데이트를 통해 공식적으로 유지관리모드에 들어간 라이브러리가 되었다. 현재는 kapt에서만 지원되는 라이브러리가 되었다. kapt 또한 유지관리모드에 있다.

KSP (Kotlin Symbol Processing) / kapt (Kotlin Annotation Processing Tool): Annotation Processor의 종류. 구글을 KSP로 전환을 권장하고 있다.

DataBinding을 위해 kapt와 KSP를 모두 사용할 경우, KSP 단독으로 썼을 때의 성능 상 이점을 누릴 수 없다.

> 유지 관리모드란?

더 이상 기능 개발을 할 계획이 없는 상태. 곧 Deprecated될 상태라고 봐도 된다.

결론

구글에서는 ViewBinding을 권장하고 있으나, 결국은 Compose를 밀기 위한 빌드업이 아닌가 싶다. ViewBinding과 Compose 모두 단방향 이벤트 처리인데, DataBinding은 양방향이기 때문에 더 이상 개발하지 않고 단방향을 밀기 위한(?) 것이 아닐까? 양방향은 아무래도 결합도가 높기 때문에 권장하지 않는 것 같다.

암튼 안드로이드 개발자는 Compose를 익혀야하는 숙명인 것 같다...!

 

다음 포스팅에서는 실제로 구현하는 방법을 자세히 다루어 보겠습니다.