본문 바로가기

ANDROID/Jetpack

[안드로이드] 안드로이드 스튜디오 3.6 업데이트, ViewBinding 사용해보기

이번 2월 25일에 안드로이드 스튜디오 버전 3.6이 릴리즈 되면서, 안드로이드 스튜디오의 자잘한 UI/UX 변화와 함께 다양한 기능들이 추가되었다.

 

이번에 추가된 기능들 중에 먼저 눈에 들어왔던 뷰바인딩을 적용해 본 경험을 공유하고자 한다.

 

https://developer.android.com/topic/libraries/view-binding?utm_medium=studio-assistant-stable&utm_source=android-studio-3-6

 

뷰 바인딩  |  Android 개발자  |  Android Developers

뷰 바인딩 기능을 사용하면 뷰와 상호작용하는 코드를 쉽게 작성할 수 있습니다. 모듈에서 사용 설정된 뷰 바인딩은 모듈에 있는 각 XML 레이아웃 파일의 바인딩 클래스를 생성합니다. 바인딩 클래스의 인스턴스에는 상응하는 레이아웃에 ID가 있는 모든 뷰의 직접 참조가 포함됩니다. 대부분의 경우 뷰 바인딩이 findViewById를 대체합니다. 설정 안내 참고: 뷰 바인딩은 Android 스튜디오 3.6 Canary 11 이상에서 사용할 수 있습니다. 뷰 바인

developer.android.com

 

뷰바인딩은 기존의 DataBinding과 마찬가지로 findViewByID를 사용하지 않고 레이아웃을 참조할 수 있게 해준다. 사소한 차이일 수 있지만 특정 뷰를 참조하기 위해 lateinit 변수라던지 val 변수를 만든다던지, 혹은 이를 쓰지 않고 단순히 뷰를 조작하는 경우라고 한들써야했던 보일러플레이트 코드들에 비해 손도 덜 가고, 코드의 가독성도 높여주는 장점을 가지고 있다.

 

이런 점들에 대해 Google은 다음과 같은 강점을 어필하고 있다. (써주세요 써주세요)

 

- Null safety : 뷰바인딩은 view를 직접 참조하는 레퍼런스를 만듬으로써, 잘못된 view ID로 인해 null pointer exception이 생기지 않고, 특정 조건에만 존재하는 뷰의 경우 @Nullable 어노테이션을 붙이기 때문에 Null safety 하다.

 

- Type safety : 뷰바인딩을 활용해 뷰를 참조할 경우 뷰의 타입을 가지고 있기 때문에, id는 맞게 참조했으나 형식이 다름으로 인해 오류가 발생하는 등의 일을 방지할 수 있다.

 

이제 뷰바인딩의 장점에 대해 짚어보았으니 실제로 적용하는 법을 살펴보자.

 


1. 우선 안드로이드 스튜디오 3.6 및 최신 gradle 버전을 적용한다.

 

2. app 레벨의 gradle에서 viewBinding을 활성화한다.

 

android {
    ...
    viewBinding {
        enabled = true
    }
}

 

3. 뷰바인딩이 만들어준 클래스를 onCreate 및 onCreateView에 적용시켜준다.

 

< onCreate의 경우 : Activity 클래스에서 바인딩을 사용할 때 >

private lateinit var binding: ResultProfileBinding

override fun onCreate(savedInstanceState: Bundle) {
    super.onCreate(savedInstanceState)
    binding = ResultProfileBinding.inflate(layoutInflater)
    val view = binding.root
    setContentView(view)
}

 

* 여기서 기존 데이터바인딩을 사용할 때는 DataBindingUtil을 사용해 binding 변수를 생성해주었는데, 뷰바인딩에서는 곧바로 해당 레이아웃의 바인딩 클래스로부터 inflate를 하게 된다.

 

< onCreateView의 경우 : Fragment나 기타 클래스에서 바인딩을 사용할 때>

private var _binding: ResultProfileBinding? = null
// This property is only valid between onCreateView and
// onDestroyView.
private val binding get() = _binding!!

override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View? {
    _binding = ResultProfileBinding.inflate(inflater, container, false)
    val view = binding.root
    return view
}

override fun onDestroyView() {
    _binding = null
}

 

이것으로 뷰바인딩을 적용하는 과정을 마치게 되는데, 데이터바인딩은 레이아웃 코드로 감싸주어야 참조가 가능한 반면에 뷰바인딩은 이런 과정이 불필요함으로, 기존에 바인딩이 적용되지 않은 프로젝트에 쓰고자 할 때 굉장히 편리하다는 강점이 있었다.

 

반면 기존에 데이터바인딩이 부분 적용되어 있는 경우 뷰바인딩과 함께 사용하게 되면 참조하는 중 리턴 타입이 맞지 않는 등의 문제로 에러가 발생할 수 있는점은 주의해야겠다. 이에 관해 구글에서 제공하는 레이아웃 옵션을 사용하면 뷰바인딩이 특정 레이아웃을 무시하게 만들 수 있기 때문에, 필요에 따라 적용하면 되겠다.

 

<LinearLayout
        ...
        tools:viewBindingIgnore="true" >
    ...
</LinearLayout>


총론

 

뷰바인딩을 왜 쓰느냐, 그리고 쓰니 어떠했느냐 등에 대해 간단히 풀어보자면

 

  • 데이터바인딩보다 캐주얼하게 쓰기에 좋다
  • MVVM 패턴이 아닌 MVP 패턴에 적용하니 적절했다
  • 남은 findViewById가 떠나갈수록 개발자의 눈과 손은 가벼워지더라