그냥 나만의 해석이고 언제 해석이 바뀔지 모름
기존의 xml 방식은 데이터가 변경되게 되면 그 데이터를 표시하기 위해서는 UI계층 구조를 업데이트 해야한다. 순서대로 한번 써보면
1) 데이터를 받음
2) VIEW에 적용 (예, TextView.Text = "안녕")
3) 데이터 변경
4) View에 적용 (TextView.Text = "잘 가")
위와 같은 방식을 통해서 각 ui 하나하나에 데이터 변경에 대한 반응을 코드를 이용해서 사용해야 했음. 그런데 databinding 을 통해서 데이터의 변경을 감지해서 ui변경을 하면서 이런과정이 많이 줄었다고 생각했음.
선언형 UI를 사용하게 되면서 각각의 객체 UI가 데이터 풀을 가지고 있어서 DATA가 변경될 때 마다 그 최신의 상태로 업데이트를 한다. XML의 경우 새로 뷰를 만들게 되면서 비용이 많이 들지만, 선언형 UI를 통해서 데이터의 변경 사항을 어디에 적용해야 할 지 효율적으로 찾아서 비용이 적게 든다고 함.
내가 이해한 바로는 UI요소를 만들 수 있는 Composable Function을 만들어서 필요할 때 이 Function을 통해 각 UI를 생성해 주는 방법으로 UI를 구성한다. 그리고 kotlin언어를 사용해서 만들어서 동적으로 반응하는 레이아웃이 될 수 있음.
Compose 기본
1. Column(vertical) Row(horizontal) Box 가장 중요한듯
orientation과 비슷한 방법임
2. Modifier
컴포저의 크기, 레이아웃, 동작, 외형을 바꾸기
접근가능한 라벨 등의 정보
사용자와의 interaction
스크롤, 드리그 등등의 다양한 기능들을 부여 할 수 있다.
이걸 잘 다루는 게 중요할 듯 함.
Modifier에 적용하는 기능의 순서도 중요함. padding을 먼저 적용하고 click을 적용하면 padding에 의해 클릭이 가능한 범위가 줄어든다. 이와 반대로 click을 먼저 적용하게 되면 UI객체에 Padding이 존재하지만, 클릭은 전체 UI 객체에서 이루어 지게됨.
상태관리 State
ReComposition
: 데이터 변경에 의해서 컴포지션을 업데이트하기 위해 다시 Composable을 실행하는것
remember 을 사용하여 객체를 컴포지션에 저장하고 리컴포지션을 할 때 remember을 호출하여 다시 사용
상태를 다르게 저장 할 수 있는데 나는 livedata를 주로 사용하므로, lisvedata.observeAsState()를 사용해서 위와 같은 기능을 할 수 있음.
stateful : remember을 사용해서 객체를 저장하는 컴포저블은 내부 상태를 생성하여 컴포저블을 stateFul로 만든다. 이는 컴포저블을 호출 하면서 제어할 필요없이 그 자체로써 역할을 하는 방법인듯?
stateless : 는 위와 반대로 제어가 필요한 컴포져블임.
state호이스팅 : 컴포져블을 stateless상태로 만들기 위해서 매개변수들을 한 단계 끌어올리면서 재사용성을 늘린다.
너무 뒤죽박죽인데 담부터 직접 사용하면서 정리해 봐야겠다.
'어플 개발일기' 카테고리의 다른 글
Android 1Compose (3) 간단한 Viewmodel과 연동시켜보기 (firebase) (0) | 2021.07.31 |
---|---|
Android Compose (2) 툴바 만들어 보기 + 단순 리스 (0) | 2021.07.31 |
data class를 번들(bundle)로 넘기기! (0) | 2021.06.20 |
listadapter 에서 diffutil이 반응안한다? 아니면 하면 안되는데 한다? (0) | 2021.06.15 |
android wating for debugger 계속 뜨는 문제 (0) | 2021.06.14 |