[android] Compose Layouts and Modifiers: Live Q&A - MAD Skills 정리

해당 글은 https://www.youtube.com/watch?v=zGP7-VvjmTQ에 대한 정리 글입니다.

Column vs LazyColumn

Column은 화면에 보여짐과 동시에 모든 컴포넌트들이 생성됩니다다.
LazyColumn은 스크롤이 내려갈때 컴포넌트들이 생성됩니다.

LazyColumn은 스크롤할때 Column보다 버벅일수 있지만, Column이 못하는일을 할 수 있습니다.(20000개의 리스트를 보여준다던지)

보여줄 리스트의 크기에 따라 뭘 선택할지 고민하세요.

LazyColumn의 중첩 스크롤은 지원이 안되는가?

LazyColumn내에 LazyColumn이 내부에 있어서 수직 스크롤은 불가능합니다.
우리가 예전에 nestedScroll안에 recyclerView를 넣지 말아야했던 이유를 생각해봅시다.
nestedScrollView는 높이가 무한했기에 recyclerView의 recycle이 작동이 안했었죠.
LazyColumn도 마찬가지 입니다. LazyColumn 내부에 무한한 Canvas를 만들기 때문에
재활용이 일어나지 않습니다.

이론적으로 이것을 가능하게 하려면 내부의 lazyColumn의 크기를 고정으로 박으면 가능합니다.

(실제로 해보았습니다.)
Column에 스크롤이 있고, 내부에 LazyColumn을 만들었습니다.
Column과 LazyColumn 둘다 같이스크롤이 있을 시, 아래와 같은 런타임에러가 발생했습니다.

Vertically scrollable component was measured with an infinity maximum height constraints, which is disallowed. One of the common reasons is nesting layouts like LazyColumn and Column(Modifier.verticalScroll()). If you want to add a header before the list of items please add a header as a separate item() before the main items() inside the LazyColumn scope. There are could be other reasons for this to happen: your ComposeView was added into a LinearLayout with some weight, you applied Modifier.wrapContentSize(unbounded = true) or wrote a custom layout. Please try to remove the source of infinite constraints in the hierarchy above the scrolling container.

https://www.youtube.com/watch?v=1ANt65eoNhQ&t=899s

그래서 lazyColumn의 item을 통해 해결하였습니다.

언제 BoxLayout을 쓰고 Custom Layout으로 만들어야 하는가?

(개인적으로 정말 원하던 질문입니다)
Compose는 이미 복잡한 디자인을 만드는데 사용할 수 있는 BoxLayout이 존재합니다.
그럼에도 Custom Layout으로 만들때 필요한 결정적인 요소는 요소의 크기가 의존적일때 필요합니다.
사이즈와 위치가 종속을 가지고 있을때, 맞춤 레이아웃을 만드는게 컴포저블을 단순하게 만듭니다.

Modifier.alignByBaseline()은 언제 필요해?

Text가 있을때 서로 글꼴이 다를경우, 기준선이 맞지 않을수 있다.
(제가 직접 해보고 알려드리겠습니다)

Modifier 연산자를 여러개 넘기는것은 허용되는건가?

recyclerView와 LazyColumn의 성능차이가 일어나는 이유는 무엇입니까

ComposeView에서 많은 Column을 사용할때 영향을 미치나요?

약간의 오버헤드가 미칠수 있으나, Linear Layout보다 훨씬더 저렴합니다.
그렇기에 자유롭게 레이아웃을 만드세요!

Compose에서는 많은 experimental 어노테이션이 붙어있는데 언제 stable이 될까요?

Stable이 되면 함부로 수정을 할수 없습니다.
최대한 바꾸지 않으려고 노력하지만 피드백을 받기 위해, 또는 api가 올바른 방향으로 나아가는지에 대해 테스트 하고 있습니다
확실히 말하고자 하는건, 메이저 업그레이드가 일어나지 않는한 중요한 변경사항은 없을것입니다.

Custom Layout을 만드는데 디버그하는 팁

Inspecter Layout를 사용하세요.
어디 위치에 향하는지 확실히 알고자 한다면 이만한게 없습니다.
또한 Preview는 이작업에 많은 도움이 될것 입니다.

custom Modifier를 만들때 composed{}를 사용하는 이유는 무엇입니까?

오히려 권장하지 않습니다.
성능에 대한 이슈때문에 modifier node로 바꾸려고 시도하고 있습니다.
(이에 대한건 따로 정리가 필요할것 같습니다.)

ConstraintLayout을 계속 사용해야 합니까?

성능에 대한 이슈는 Compose로 오면서 벗어나게 되었습니다.
더이상 최적화에 필요하지 않습니다.
제약조건이 있을때, ConstraintLayout을 사용할때 좀더 가독성이 있다면 사용하세요.
선호의 문제입니다.
XML에서 ConstraintLayout은 CustomLayout를 대체하기 위해 사용되기도 했죠.
하지만 Compose에서는 CustomLayout을 만들기 쉬워졌습니다.

SubcomposedLayout은 언제 사용하나요?

모든 Lazy component , BoxConstraint는 subcomposedLayout을 사용하고 있습니다.
이것은 안에 내용물이 무엇인지 알수 없을때 사용합니다.
또한 측정할때 내용이 무엇인지 파악할 수 있습니다.
커스텀을 할때 서브 컴포즈 레이아웃을 사용할일은 별로 없겠지만, 사이즈를 알기 전까지 어떤 내용물인지 모른다면 subComposedLayout을 사용하면 좋습니다.