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 특징
- viewBinding은 빌드 과정에서 생성된다.
- 끝에 Binding이란 단어가 붙는다.
- 카멜 표기법에 따라 네이밍이 된다.
- ID가 존재하지 않는 뷰에 대해선 클래스에 참조가 존재하지 않는다.
- getRoot()메서드가 자동 포함 된다. layout file의 루트 뷰에 관한 직접 참고 제공.
🔎 findViewById와의 차이?
- null safety - 뷰 직접 참조로 없는 아이디로 널포인트 익셉션 발생 안함.
- type safety - 뷰 타입이 일치함으로 Class Cast Exception 발생 안하지.
🔎 DataBinding과의 차이?
일단, 둘은 모두 뷰를 직접 참조하는데 사용할 수 있는 binding class 를 제공한다.
확실히 viewbinding은 보다 단순한 처리의 경우 적합.
- 더 빠른 컴파일 = annotation처리 필요 없음으로 컴파일이 빠르다.
- 사용 편의 - 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을 이야기 하다 보니 여러 이야기들이 나왔지만 결국 아래 표와 같이 비교하고 사용하면 된다.
꼭 무엇 하나가 좋다기보단, 프로젝트의 상황에 경우에 맞게 사용하는 것이 가장 좋을 것 같다.
