서론...
개인적으로 진행중인 프로젝트에서 Scaffold 내부 topBar 에서 지정한 부분만 접거나 확장해야하는 요구 조건이 있었다.
초기에는 androidx.compose.material3 에 포함된 LargeAppBar()를 사용하여 구현하고자 했다.
하지만 원하는 디자인 요구사항을 만족시키기 어려웠기 때문에, 직접 fraction 과 같이 진행도를 바탕으로 구현할 수 밖에 없었다.(다양한 라이브러리 역시 결국 같은 결과에 도달했다..)
해당 과정에서 구현을 위한 변수나 함수 그리고 상태를 관리하는 값이 너무 많았다.
수정사항이 실제로 발생하고 유지보수가 힘들었기 때문에 재사용성도 고려하고 역할과 책임을 적절하게 분리하고자 했다.
이 과정에서 nestedScroll에 대해 자세하게 알아본 과정을 풀어보고자 한다.
NestedScrolling 이란?
Compose supports nested scrolling, in which multiple elements react to a single scroll gesture. A typical example of nested scrolling is a list inside another list, and a more complex case is a collapsing toolbar.
Compose 에서는 nestedScrolling 으로 여러 요소가 하나의 Scroll 제스처에 반응하도록 하여, 자식 요소뿐 아니라 부모 요소 역시 스크롤 할 수 있도록 지원한다.
가장 일반적으로 스크롤 가능한 요소에 스크롤 가능한 요소가 들어가는 경우가 있다.
이러한 기능을 응용하면 자식요소의 스크롤을 처리하면서 부모 요소의 toolbar 를 변경하는 collapsing toolbar 와 같은 기능을 제작할 수 있다.
만약 nestedScrolling에 대해 처리되지 않는다면 자식 요소에서 스크롤을 처리하면, 부모 요소는 스크롤 제스처를 처리할 수 없어진다. 기본적으로 Jetpack Compose에서 제스처에 대한 처리는 자식 요소에서 부모 요소로 전파되기 때문이다.
자동으로 지원하는 NestedScroll
Compose에서 NestedScroll 을 지원하기 때문에 단순한 중첩 스크롤은 특별하게 무엇인가 구현하거나 조치를 취할 필요가 없다.
verticalScroll, horizontalScroll, scrollable 과 같은 수정자 혹은 Lazy 에 대한 API 및 TextField 등 구성요소에서는 자동적으로 nestedScroll 지원이 내장되어있다.
기본적으로 스크롤이 제공되는 경우 자동으로 자식 요소의 스크롤이 끝나면 부모 요소가 스크롤 될 수 있게 처리한다.
NestedScroll 을 따로 구현하는 경우
스크롤을 지원하지 않는 요소나 스크롤 구현이 되지 않은 Column 이나 Box의 경우는 자동으로 Scroll 제스처를 부모로 전파하지 않기 때문에 NestedScroll 을 처리해야한다.
NestedScroll 을 처리하기 위해서는 Modifier.nestedScroll() 을 사용한다.
fun Modifier.nestedScroll(
connection: NestedScrollConnection,
dispatcher: NestedScrollDispatcher? = null
): Modifier = this then NestedScrollElement(connection, dispatcher)공식문서
There are two ways to participate in the nested scroll: as a scrolling child by dispatching scrolling events viaNestedScrollDispatcherto the nested scroll chain; and as a member of nested scroll chain by providingNestedScrollConnection, which will be called when another nested scrolling child below dispatches scrolling events.
nestedScoll 수정자에서 기본적으로 NestedScrollConnection 과 NestedScrollDispatcher 를 받게 된다.
NestedScrollDispatcher를 이용하여 부모 요소에게 스크롤 제스처를 전파하고 NestedScrollConnection 을 이용하여 자식 요소에서 전달된 스크롤 제스처를 얻는다.
NestedScrollConnection
NestedScrollConnection 은 nestedScroll 수정자에서 필수적으로 받게된다.NestedScrollConnection 을 이용하여 직접 자식요소에서 전달된 스크롤 제스처를 얻을 수 있다.
또한 전달된 스크롤 제스처를 사용하고 남은 양을 다시 "선택적으로" 전달 할 수 있다.
얻어온 스크롤 제스처로 부모 요소에서 처리하고 남은 만큼 자식 요소가 처리하지 않아도 되는 상황에는 소모한 양을 전달하지 않을 수 있다.
NestedScrollConnection 은 interface로 구현체를 직접 만들어 아래와 같은 함수를 오버라이딩 할 수 있다.
onPreScroll()- 자식 요소가 스크롤을 먹기 전, 먼저 부모에서 스크롤 제스처를 얻는다.
- 스크롤 가능한 구성 요소가 스크롤 가능한 Delta 를 받아서
NestedScrollDispatcher를 통해 전달 될 때마다 발생된다. - Delta 를 전달하는 자식은 모든 조상이 소모하고 반환한 값을 바탕으로 소비를 조정할 수 있다.
onPostScroll()- 자식 요소가 스크롤을 한 후, 남은 스크롤 제스처를 부모에서 얻는다.
- 스크롤 가능한 요소가 스크롤 가능한 Delta 를 이미 소비한 후, 소비하고 남은 스크롤 제스처의 Delta 를
NestedScrollDispatcher를 통해 전달된다. - 부모 요소에서는 전달 받은 Delta의 남은 양 이상을 소비하지 않아야하고 소비한 양을 반환할 수 있다.
onPreFling()- 자식 요소가 스크롤 후 플링하기(내려가기) 전에 부모에서 플링을 얻는다.
- 자식 요소가 스크롤 하는 드래그를 멈추고 내려가는 애니메이션이 발생할 때 발생한다.
- 플링 과정에서 자식 요소가 내려가는 속도를 사용하기 전에 미리 부모 요소에서 사용할 수 있게 제공할 수 있다.
onPreScroll()처럼 부모 요소에서 속도 일부를 사용하고 남은 값을 반환할 수 있다.
onPostFling()- 자식요소가 스크롤 후 플링하고 난 후 부모에서 남은 플링을 얻는다.
- 자식 요소가 플링이 멈추고 남은 속도를 얻을 수 있으며 남은 속도 이상을 사용하지 않아야 한다.
각 오버라이딩이 가능한 함수의 호출 순서는 다음과 같다고 한다.
출처: 언본일기, Nested Scroll 삽질기 - Jetpack Compose / 작성자: onebone
공식문서의 NestedScrollConnection 사용 예시를 보면 다음과 같다.
// here we use LazyColumn that has build-in nested scroll, but we want to act like a
// parent for this LazyColumn and participate in its nested scroll.
// Let's make a collapsing toolbar for LazyColumn
val toolbarHeight = 48.dp
val toolbarHeightPx = with(LocalDensity.current) { toolbarHeight.roundToPx().toFloat() }
// our offset to collapse toolbar
val toolbarOffsetHeightPx = remember { mutableStateOf(0f) }
// now, let's create connection to the nested scroll system and listen to the scroll
// happening inside child LazyColumn
val nestedScrollConnection = remember {
object : NestedScrollConnection {
override fun onPreScroll(available: Offset, source: NestedScrollSource): Offset {
// try to consume before LazyColumn to collapse toolbar if needed, hence pre-scroll
val delta = available.y
val newOffset = toolbarOffsetHeightPx.value + delta
toolbarOffsetHeightPx.value = newOffset.coerceIn(-toolbarHeightPx, 0f)
// here's the catch: let's pretend we consumed 0 in any case, since we want
// LazyColumn to scroll anyway for good UX
// We're basically watching scroll without taking it
return Offset.Zero
}
}
}
Box(
Modifier
.fillMaxSize()
// attach as a parent to the nested scroll system
.nestedScroll(nestedScrollConnection)
) {
// our list with build in nested scroll support that will notify us about its scroll
LazyColumn(contentPadding = PaddingValues(top = toolbarHeight)) {
items(100) { index ->
Text("I'm item $index", modifier = Modifier.fillMaxWidth().padding(16.dp))
}
}
TopAppBar(
modifier = Modifier
.height(toolbarHeight)
.offset { IntOffset(x = 0, y = toolbarOffsetHeightPx.value.roundToInt()) },
title = { Text("toolbar offset is ${toolbarOffsetHeightPx.value}") }
)
}하단에 Component 구성을 보면 LazyColumn 이 사용되고 있다.
LazyColumn 내부를 타고 들어가서 Modifier.scrollable() 내부를 살펴보면 기본적으로 NestedScoll 을 지원하는 것을 확인할 수 있다.
val toolbarHeight = 48.dp
val toolbarHeightPx = with(LocalDensity.current) { toolbarHeight.roundToPx().toFloat() }
// our offset to collapse toolbar
val toolbarOffsetHeightPx = remember { mutableStateOf(0f) }
// now, let's create connection to the nested scroll system and listen to the scroll
// happening inside child LazyColumn
val nestedScrollConnection = remember {
object : NestedScrollConnection {
override fun onPreScroll(available: Offset, source: NestedScrollSource): Offset {
// try to consume before LazyColumn to collapse toolbar if needed, hence pre-scroll
val delta = available.y
val newOffset = toolbarOffsetHeightPx.value + delta
toolbarOffsetHeightPx.value = newOffset.coerceIn(-toolbarHeightPx, 0f)
// here's the catch: let's pretend we consumed 0 in any case, since we want
// LazyColumn to scroll anyway for good UX
// We're basically watching scroll without taking it
return Offset.Zero
}
}
}또한 직접 스크롤을 지원하지 않는 상위 요소인 Box 에 nestedScrollConnection 을 구현해서 넣어주게 된다.
자식 요소에서 스크롤하기 전, 스크롤 가능한 Delta 를 사용하여 지정한 toolbar 의 높이를 변경하게 된다.
또한 반환으로 부모에서 스크롤을 사용하지 않은 것으로 반환하고 있다.
따라서 결과적으로 아래와 같은 순서로 동작된다.
- 스크롤 발생
- 스크롤 이전에 스크롤 되는 Delta 를 상위
nestedScrollConnection을 이용하여 자식 요소가 스크롤 되기 전에 toolbar 의 높이를 조정한다. - 부모에서 소비하지 않고
Offset.Zero를 반환.
결과적으로 하위 리스트를 스크롤 하면 스크롤 제스처에 대한 Delta 에 따라 툴바의 높이가 변경되는 것을 확인할 수 있다.
NestedScrollDispatcher
NestedScrollDispatcher 는 기본적으로 optional 값이다.
자식 요소에서 스크롤에 대한 이벤트를 부모에게 전달할 필요가 있는 경우 구현한다.
공식문서에 사용 예제 일부를 보면 다음과 같다.
val nestedScrollDispatcher = remember { NestedScrollDispatcher() }
//...
.draggable(
orientation = Orientation.Vertical,
state = rememberDraggableState { delta ->
// here's regular drag. Let's be good citizens and ask parents first if they
// want to pre consume (it's a nested scroll contract)
val parentsConsumed = nestedScrollDispatcher.dispatchPreScroll(
available = Offset(x = 0f, y = delta),
source = NestedScrollSource.Drag
)
// adjust what's available to us since might have consumed smth
val adjustedAvailable = delta - parentsConsumed.y
// we consume
val weConsumed = onNewDelta(adjustedAvailable)
// dispatch as a post scroll what's left after pre-scroll and our consumption
val totalConsumed = Offset(x = 0f, y = weConsumed) + parentsConsumed
val left = adjustedAvailable - weConsumed
nestedScrollDispatcher.dispatchPostScroll(
consumed = totalConsumed,
available = Offset(x = 0f, y = left),
source = NestedScrollSource.Drag
)
}
)자식 요소에서 드레그 제스처를 받으면 받은 제스처를 이용하여 nestedScrollDispatcher.dispatchPreScroll 을 호출한다.
부모 요소에서 소모하고 남은 delta 를 이용하여 스스로 delta 를 소모한 후 최종적으로 nestedScrollDispatcher.dispatchPostScroll 을 이용하여 부모에 다시 남은 delta 를 전달한다.
각각의 내부를 살펴보면 실제로 부모 요소에 스크롤을 전파하는 것을 확인 할 수 있다.
fun dispatchPreScroll(available: Offset, source: NestedScrollSource): Offset {
return parent?.onPreScroll(available, source) ?: Offset.Zero
}
fun dispatchPostScroll(
consumed: Offset,
available: Offset,
source: NestedScrollSource
): Offset {
return parent?.onPostScroll(consumed, available, source) ?: Offset.Zero
}추가적인 궁금증...그리고 해결과정
공식문서에 NestedScrollDispatcher 를 설명하는 부분에서 해당 예시 코드를 LazyColumn의 자식 요소로 넣어보라는 말이 있었다.
실제 예시의 Box를 LazyColumn에 넣으면 Box의 드레그로 제스처를 모두 소모하면 부모 요소인 LazyColumn에서 스크롤이 발생했다.
여기서 궁금증이 발생했다.
중첩 스크롤을 지원하도록 수정자에 알리고 상호작용하는 요소가 아닌 최상위 요소인 LazyColumn은 어떻게 남은 스크롤을 알고 스크롤이 지원되었을까?
사실 이미 머리속으로는 LazyColumn이 Compose에서 nestedScroll 을 지원하는 요소였기 때문에 가능했다고 알고있지만, 초점은 "어떻게?"였다.
학습을 하는 과정에서 단순하게 NestedScrollDispatcher로 상위 체인에 알리고 NestedScrollConnection 으로 자식의 제스처를 가져온다는 말을 1차원 적으로 생각했다.
따라서 "nestedScroll 수정자가 적용된 Component 와 하위 요소만 중첩 지정한 중첩 스크롤에 참여된다" 생각했다.
NestedScrollConnection 에서 자식의 스크롤을 읽어와서 더 상위에는 "직접 전달하지 않았기 때문에" LazyColumn이 nestedScroll 을 지원한다 해도 "내가 전달하지 않은 부분을 어떻게 처리했지?" 하는 의문이 생긴 것이다.
직접적으로 컨트롤하는 부분이 없었기 때문에 다음과 같은 가설을 만들게 되었다.
"nestedScroll 수정자 내부에서 보다 상위 체인의 부모 요소로 스크롤 제스처를 전파하는 행위가 있다"
따라서 위 가설을 확인하기 위해 내부를 찾아본 결과
nestedScroll 수정자 > NestedScrollNode 에서 다음과 같은 내용을 찾을 수 있었다.
internal class NestedScrollNode(
var connection: NestedScrollConnection,
dispatcher: NestedScrollDispatcher?
) : ModifierLocalModifierNode, NestedScrollConnection, DelegatableNode, Modifier.Node() {
// ...
private val parentConnection: NestedScrollConnection?
get() = if (isAttached) ModifierLocalNestedScroll.current else null
// ...
override fun onPostScroll(
consumed: Offset,
available: Offset,
source: NestedScrollSource
): Offset {
val selfConsumed = connection.onPostScroll(consumed, available, source)
val parentConsumed = parentConnection?.onPostScroll(
consumed + selfConsumed,
available - selfConsumed,
source
) ?: Offset.Zero
return selfConsumed + parentConsumed
}onXXXScroll 혹은 onXXXFling 과 같은 각 메소드에서 자신이 받아온 connection과 부모의 connection 을 고려해서 스크롤 혹은 플링의 정보를 계산하고 전달하고 있다.
즉 초기 생각한 가설과 같이 nestedScroll 수정자 내부에서 스크롤 제스처가 부모 요소로 전파되고 있었다.
결국 Box의 draggable 에서 NestedScrollDispatcher.onPostScroll() 과 같은 함수를 호출하면NestedScrollConnection로 제스처가 전파되고 받아온 connection 에서 처리하고 남은 값을 받았다면 부모 요소에 이를 고려하여 전파하는 것을 확인할 수 있었다.
마무리 하며...
사실 구현을 마치고 보니 생각보다 더 많은 것을 알아야만 하는 상황이었다.
덕분에 배보다 배꼽이 더 큰 상황이 되어 생각보다 긴 시간이 걸렸던 것 같다...
하지만 덕분에 스스로 사용의 개념이 아닌 더 깊은 개념적인 이해가 아직 부족했다고 느끼고 반성할 수 있었다.
직접 기능을 구현하고 커스텀 하는 과정에서 과거 안드로이드 멘토님의 피드백에서 공식문서의 중요성을 들었던 기억이 있다.
공부하고 이해하는 과정에서 정말 많은 블로그를 접하고 라이브러리 코드를 뜯어보았다.
하지만 결국 핵심적인 궁금증을 해결하기 위해서는 공식문서가 많은 도움이 되는 것을 다시 느낄 수 있었다...
