안드로이드가 처음 등장했을 때 뷰는 xml, 로직은 java 로 개념적으로는 구분하여 개발할 수 있었습니다. 그리고 뷰의 상태를 갱신하기 위하여 앱 내 리소스에 접근 가능한 R.java 을 이용하여 인플레이션을 통해 메모리에 실제로 객체화된 뷰 객체를 참조하여 개발을 진행했습니다. (setContentView, findViewById …)
과거 안드로이드 UI 개발은 뷰를 참조하기 위한 불필요한 코드(Boilerplate) 가 많았고, 이를 해결하려는 많은 노력이 있었습니다. 자바 어노테이션을 활용하여 리소스 식별자에 접근을 편리하게 해주는 버터나이프, 안드로이드 개발 언어로 코틀린이 채택되면서 함께 등장했었던 kotlin-android-extension 플러그인, 레이아웃 리소스의 ID가 있는 모든 뷰의 직접 참조를 할 수 있도록 바인딩 객체를 제공하는 젯팩 뷰 바인딩 등이 생각합니다.
안드로이드 UI 개발에서 반드시 짚고 넘어가야 할 것이 하나 있습니다. 바로 Activity Lifecycle 과 관련된 부분입니다. 액티비티에서 비즈니스 로직과 뷰 처리를 위해 MVP, MVVM 등 다양한 아키텍처들이 등장했었습니다. 구글 개발 가이드라인에서 앱 아키텍처 가이드라인이 지속적으로 개선되었고, 개발 진행간 라이프사이클 의존적인 요소를 지원하기 위한 다양한 Jetpack 라이브러리들이 등장하면서 점점 UI 와 로직 개발이 잘 분리가 될 수 있어졌고, Testable 한 코드 작성이 수월해졌습니다. 개인적으로 젯팩 ViewModel 과 Hilt 가 Activity 의 전통적으로 수행하던 복합적인 역할에서 관심사가 잘 분리할 수 있는데 큰 도움이 되었다고 생각합니다.
이제 온전히 UI 만 좀 더 생각해 보겠습니다. 화면에 표시되는 뷰의 상태를 어떤 로직의 수행 결과로 뷰 객체 참조 정보를 활용하여 일일히 업데이트 하다보면 지속적으로 소스코드의 변경 및 개선함에 있어 어떤 이슈가 발생할까요? 기본적으로 뷰의 상태를 일일히 업데이트하는 코드를 작성하는 것은 (생각보다 훨씬) 거대한 작업이고 그 과정에서 버그가 발생하는 것은 온전히 개발자가 책임을 가져가야 하는 부분입니다. 이런 문제를 해결하기 위해 젯팩의 데이터 바인딩을 활용할 수 있습니다. 어쨌든, 전통적으로 안드로이드 UI 개발은 뷰의 상태를 어떻게 해야할 지 알려줘야 화면에 잘 표시됩니다.
안드로이드 UI 개발을 위해 Google I/O 2019 에서 Declarative UI Tookit 인 Jetpack Compose 가 소개되었고, 2021년 7월 정식 버전이 출시되었습니다. 개인적으로 선언형 UI 개발을 할 때는 뷰를 어떻게 해야할 지 명시하는 대신, 어떤 뷰를 원하는지 좀 더 집중할 수 있어 뷰 구현에 좀 더 집중할 수 있고 뷰의 재사용성 측면에서 장점이 있다고 생각해 관심을 가지고 있었습니다.
앞으로 공식 가이드 문서를 번역해 보고 관련 기술분석을 함께 포함하려고 생각하고 있습니다. 아래는 그 목차이고, 구성은 언제든지 변경될 수 있습니다.
