UI 패러다임

명령형 UI (XML)

XML의 UI 시스템은 명령형 패러다임을 따른다. 즉, 어떻게 UI를 변경할 것인가를 개발자가 단계적으로 지시하는 방식이다.

XML은 UI의 초기 상태를 선언할 뿐이며, 실제 화면 변경은 런타임에 View객체를 직접 조작함으로써 이루어진다.

textView.text = "Hello"
progressBar.visibility = View.GONE
button.isEnabled = false

compose는 선언형 UI 패러다임을 기반으로 한다. 즉, 상태에 따라 UI를 어떻게 보여줄지를 선언한다.

UI는 상태를 직접 보유하지 않으며, 상태가 변경되면 UI는 Recomposition을 하여 다시 그린다.

Text(text = if (isLogin) "환영합니다" else "로그인 해주세요")

XML의 UI 상태는 여러 위치에 분산되어 관리된다. 대표적으로 View 내부 필드, Activity, Fragment, onSaveInstanceState 등이 있다.

이 방식은 상태가 변경될 때마다 View를 직접 조작해주어야하며, 현재 상태를 코드 전체를 통해 추척해야한다. 따라서 상태가 단일 진실 공급원을 갖기 어렵다는 단점이 있다.

상태가 무엇인지 보다 마지막으로 어떤 명령이 실행됐는지가 UI를 결정한다.

button.isEnabled = false
progressBar.visibility = View.VISIBLE

compose의 UI 상태는 UI 외부에 존재하며, composable은 해당 상태를 읽기만 한다. 상태는 주로 ViewModel이나 remember/ rememberSavable을 통해 composable의 로컬 상태로 갖는다.

단방향 데이터 흐름과 재사용 가능한 composable을 만들기 위해 상태 호이스팅을 기본 설계 원칙으로 한다.

@Composable
fun LoginScreen(uiState: LoginUiState) {
    if (uiState.isLoading) {
        CircularProgressIndicator()
    }
}

XML UI는 다음과 같은 과정을 거친다.

따라서 View가 많을수록 메모리 사용량이 증가하고, 복잡한 레이아웃일수록 초기 진입 비용이 증가한다.

Compose UI는 다음과 같은 과정을 거친다.

따라서 UI는 코틀린 코드의 실행 결과이며 불필요한 View 객체 생성을 하지 않는다.

상태가 변경되면 영향 받는 Composable만 재실행하기 때문에 효율적이다.

XML의 UI 테스트는 View 객체를 생성해야하기 때문에 생명주기에 강하게 의존한다.

대표적으로 Espresso 기반의 Instrumentation Test가 중심이 된다.

이 방식의 특징은 다음과 같다.

또한 UI 로직이 Activity나 Fragment 내부에 섞여 있는 경우가 많아서 상태 조작을 위해 View를 직접 건드려야 하고 특정 순서의 사용자 액션을 강제하는 테스트가 증가한다.

Robolectric을 사용하는게 더 좋을 듯 하다.

Compose는 전용 테스트 프레임워크를 제공한다.

이 방식의 특징은 다음과 같다.

상태를 외부에서 주입하기 때문에 테스트가 수월하다.