[Android] ViewBinding vs DataBinding

Jay·2020년 12월 16일
1

Android

목록 보기
1/39
post-thumbnail

ViewBinding

  • view와 상호 작용하는 코드를 더욱 쉽게 작성할 수 있도록 도와주는 기능.
  • xml파일에서 각 뷰는 id값을 가진다.

🤔 왜 도입 되었을까?

일단, layout Component를 코드 단으로 고치는 과정이 매우 골칫거리 (findViewById가 대표적 예시)

그래서 layout Component를 객체화 시키지 않고 바로 사용하자. 불필요한 코드를 줄이자. 이런 느낌?

🤮 좀 더 알아보자.

View Binding은 모듈 별로 사용 설정한다. 설정이 되면 각 xml 파일에 대해 binding class 를 자동 생성 한다.

Binding Class의 인스턴스는 ID를 가지고 있는 모든 뷰에 대한 직접적 참조를 포함한다. 그에 따라 findViewById를 사용하지 않고 대체 할 수 있다.

(kotlin에선 binding class 생성 없이 layout id값 참조하여 view 사용. 이것은 뷰 바인딩과 다른 관점..)

🛠 Setting

이 부분은 build 버전이 4 이상 간 이후에 데이터 바인딩과 비슷하다.

android {
    ...
    buildFeatures {
        viewBinding true
    }
}

ViewBinding 특징

  1. viewBinding은 빌드 과정에서 생성된다.
  2. 끝에 Binding이란 단어가 붙는다.
  3. 카멜 표기법에 따라 네이밍이 된다.
  4. ID가 존재하지 않는 뷰에 대해선 클래스에 참조가 존재하지 않는다.
  5. getRoot()메서드가 자동 포함 된다. layout file의 루트 뷰에 관한 직접 참고 제공.

🔎 findViewById와의 차이?

  1. null safety - 뷰 직접 참조로 없는 아이디로 널포인트 익셉션 발생 안함.
  2. type safety - 뷰 타입이 일치함으로 Class Cast Exception 발생 안하지.

🔎 DataBinding과의 차이?

일단, 둘은 모두 뷰를 직접 참조하는데 사용할 수 있는 binding class 를 제공한다.

확실히 viewbinding은 보다 단순한 처리의 경우 적합.

  1. 더 빠른 컴파일 = annotation처리 필요 없음으로 컴파일이 빠르다.
  2. 사용 편의 - tag처리된 xml 불 필요로 사용 용이. (모듈에서 binding 사용 설정만을 통해 자동으로 모든 레이아웃의 binding class 생성)

🔎 DataBinding과의 차이에서 오는 단점?

  • layout에서의 표현식 혹은 변수 제공하지 않으므로 동적인 UI 콘텐츠 생성 할 수 없다.
  • two-way- data binding 제공 안한다. (ex. bindingAdapter) 공식문서

# findViewById()의 문제점

일반적으로 안드로이드를 처음 배우면 findViewById()를 사용하여 각 view component들을 객체로 만들어서 사용한다.

(위의 과정을 거쳐야만 xml에 정의된 id를 가진 뷰들을 코드 단에서 사용할 수 있기에)

// java
TextView textView = (TextView) findViewById(R.id.tv_first)

// kotlin
val textView = findViewById<TextView>(R.id.tv_first)

치명적인 단점

  • 컴포넌트가 10개만 되더라도 같은 코드 10줄은 추가해야지. (100줄이면?)
  • findViewById함수는 사용하기에 무게감 있는 함수.
  • null값에 상대적으로 안전하지 못하다. 존재하지 않는 컴포넌트 / id를 불러올 수 있기에..

Kotlin Android Extension

  • findViewById()를 사용하지 않아도 된다. synthetic binding을 지원하기에.
    - 이젠 deprecated 되었다... migration 준비..

👀 정리

ViewBinding과 DataBinding을 이야기 하다 보니 여러 이야기들이 나왔지만 결국 아래 표와 같이 비교하고 사용하면 된다.
꼭 무엇 하나가 좋다기보단, 프로젝트의 상황에 경우에 맞게 사용하는 것이 가장 좋을 것 같다.

profile
developer

0개의 댓글