본 내용은 학습을 위해 Why we should stop using data binding in Android 을 보고 입맛대로 정리한 글입니다.

---

선호하는 이유

1. 가독성 향상

• 보일러플레이트를 줄여줌
• MVVM 패턴 구현을 단순화함

2. 타입 안전성 향상

• 컴파일 타임에 데이터의 타입을 체크함으로써 런타임 에러가 줄어듦

3. 성능 향상

• findViewById() 의 호출 수를 줄임
• UI 업데이트에 필요한 코드를 줄임

4. LiveData와의 손쉬운 통합

• LiveData와 긴밀하게 통합되어 반응형 UI 구현 단순화

5. 양방향 바인딩 지원

• UI와 데이터 모델 간의 양방향 바인딩이 가능하여, 데이터를 실시간으로 쉽게 업데이트할 수 있음

선호하지 않는 이유

1. 강결합된 코드베이스

• 디버깅을 더 어렵게 만듦
• 코드베이스가 강결합이 되어, 기본 클래스를 사용할 수 없음

2. 관심사의 분리

• UI와 데이터를 조작하는 코드가 섞여있기 때문에 코드를 읽고 이해하기 어려움
• 앱이 복잡한 경우 코드 디버깅 및 유지보수가 더 어려워질 수 있음

3. 테스트 및 디버깅의 어려움

• 생성된 코드이기 때문에, 일반 코드에 비해 디버깅하기가 어려움
• 생성된 코드는 프로젝트에서 보이지 않기 때문에, 발생하는 문제를 추적하기 어려움
• 데이터바인딩이 포함된 코드를 단위테스트하는 것은 상대적으로 어려움

데이터바인딩의 현 주소

1. kapt에 의존

• 데이터바인딩은 kapt에 의존적임
• kapt는 유지 관리 모드에 있음
  • 더이상 새로운 기능을 구현할 계획이 없음
  • ref. kapt compiler plugin
• kapt 없이 ksp를 단독으로 사용하는 경우에만 ksp의 성능 이점을 누릴 수 있음
  • 데이터바인딩을 사용하는 한 kapt를 사용해야 하므로, 데이터바인딩이 장애물이 됨

2. 유지 관리 모드

• 구글에서 데이터바인딩도 유지 관리 모드라는 것을 공개함

  Databinding is in maintenance mode as well.
  We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.

  • ref. Support KSP의 10번째 코맨트

• 데이터바인딩에 KSP를 지원한다거나 데이터바인딩 사용을 권장할 계획이 없음

• 언젠가 kapt가 deprecated되면 데이터바인딩도 동작하지 않게 될 가능성이 있음