UI 변경 사항 반영하기
composition과 후속으로 이루어지는 recomposition의 과정을 거치면서 발생되는 모든 변경사항들은 실제 UI에 반영하여 상용자가 경험할 수 있도록 하는 통합 과정이 필요하다.
이 과정은 흔히 노드 트리의 구체화라고 불리며 Compose UI와 같은 클라이언트단의 라이브러리의 책임이다.
다양한 타입의 Applier들
Applier는 라이브러리가 사용되는 플랫폼에 대해 런타임이 완전히 알지는 못하도록 의존성을 반전시킨다.
이 추상화 계층은 Compose UI와 같은 클라이언트 라이브러리가 자체적으로 Applier 구현을 할 수 있도록 하기 위해 플랫폼과의 통합에 사용될 자신의 노드 타입을 선택하게 된다.
Compose Runtime에서 다양한 Applier들이 공통 로직을 공유하기 위해 AbstractApplier라는 공통 로직을 제공한다.
AbstractApplier는 방문한 노드들을 스택에 저장하여 현재 방문 중인 노드에 대한 참조를 유지한다.
트리의 아랫쪽에서 새로운 노드에 방문할 때마다 Composer는 applier#down(node: N)을 호출하여 Applier에게 알리면 Applier는 이를 stack에 푸시하고 노드에 필요한 모든 동작을 수행할 수 있다.
하위 노드 탐색을 마치면 노드의 부모로 다시 돌아가야할 때 Composer는 applier#ip()을 호출하여 마지막으로 방문한 노드를 스택에서 팝업 시킨다.
Column {
Row {
Text("Some Text")
if (condition) {
Text("Some conditional text")
}
}
if (condition) {
Text("Some more conditional text")
}
}
위 코드의 조건문에서 쓰이는 condition이 바뀔 경우 Applier는 아래와 같이 동작한다.
- Column에 대한 down 호출
- Row로 들어가기 위한 또 다른 down 호출
- 조건에 따른 자식 Text에 대한 삭제 혹은 삽입 작업 수행
- 다시 column으로 돌아가기 위한 up 호출
- 두 번째 조건부 텍스트에 대한 삭제 작업 수행
AbstractApplier에 스택과 down 및 up 작업이 포함되어 있어 자식 Applier들이 노드 타입에 관계없이 동일한 탐색 로직을 공유할 수 있다.
이는 앞전에서 언급되었던 Applier의 노드 트리 하향식 / 상향식 구축을 의미한다.
'Android' 카테고리의 다른 글
[Android] Compose UI - (2) (0) | 2024.12.26 |
---|---|
[Android] Compose UI - (1) (0) | 2024.12.16 |
[Android] Compose 런타임 - (12) (0) | 2024.12.12 |
[Android] Compose 런타임 - (11) (0) | 2024.12.11 |
[Android] Compose 런타임 - (10) (0) | 2024.12.09 |