Jetpack Compose 시작
Jetpack Compose?
- 안드로이드의 View 시스템을 대체하기 위한 새로운 패러다임의 UI Kit로 구글에서 2019년
선언형(Declarative) API
구조를 제공
명령형 UI vs 선언형 UI
명령형 UI
- 뷰에게 직접 내부의 상태를 변경하도록 명령하는 구조.
- ex) 텍스트를 변경 (setText()), 자식 뷰를 추가 (addChild()), 이미지 변경 (setImageBitmap()) 등..
- 무엇(What) 을 그리는지 보다는 어떻게(How) 그리는지에 더 중점을 가지고 있음.
선언형 UI
- 기존 명령형 구조의 단점들을 해결하기 위해서 새롭게 도입된 패러다임
- 제공되는 데이터를 가지고 뷰가 무엇을 그리면 될지를 선언하는 구조
- 어떻게(How) 그릴지는 프레임워크에게 위임해버리고, 무엇(What) 을 그리는지에 중점을 가지고 있음.
왜 Compose가 도입되었을까?
기존의 View UI 시스템의 문제점
- 기존의 View 시스템은
명령형(Imperative) API
구조 - 이 구조는 소프트웨어 유지보수를 어렵게 하는 문제가 있음.
- 데이터를 여러 위치에서 렌더링하는 경우에 뷰 갱신 누락 등의 실수할 여지
- 여러 위치에서 UI업데이트를 수행하는 경우에 예상하지 못한 충돌 발생 여지
- xml을 이용하여 정적 UI를 구성해야하므로 UI코드가 산재되어 있음
- 동적 컨텐츠를 표시하려면 xml선언된 뷰를 객체화하여 사용해야하는 번거로움이 있음.
- DataBinding으로 번거로움을 어느정도 해결했지만, xml 자체의 가독성이 안좋아짐
선언형 UI 프레임워크를 사용하면서 오는 장점들
- 기존 View 시스템 대비 작성해야 하는 코드가 현저히 줄어들게 됨
- 작성하는 코드가 적을수록 버그 발생확률이 감소
- 주어진 데이터로 화면에 무엇을 보여줄지만 신경쓰면 되므로, 직관적인 코드구조를 유지할 수 있음.
그 외에 Compose 고유의 장점들
- UI를 kotlin으로만 작성
- 관리포인트 일원화
- 코드가독성
- 언어레벨의 유연함을 활용할 수 있음. - 분기, 반복 등
- 기존의 View UI 시스템과 상호호환 가능
첫번째 Compose 화면 구성하기
- Compose 프레임워크는 Composable 함수를 호출하여 화면 렌더링을 수행
- Composable 함수 : Compose 에서 화면을 구성하는 단위로, 화면이 어떻게 구성될지를 표현한 함수
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
firstComposable("World")
}
}
}
@Composable
fun firstComposable(name: String) {
Text(text = "Hello $name")
}
Composable 함수 작성의 기본 원칙
- 함수에
@Composable
어노테이션을 지정하여 Composable 함수임을 명시 - Composable 함수 내에서 다른 Composable 함수를 호출하여 UI 계층 구조를 구성
- Compose 프레임워크는
Text()
, LazyComlumn()
, Button()
등, 화면에 표시하기 위한 컴포넌트들을 제공- View 시스템에서 제공하는 위젯(뷰)들처럼 제공됨
- 이 컴포넌트들도 결국은 Composable 함수
- 이 컴포넌트들의 종류와 사용법을 익혀야 함
- 일반함수처럼 Composable 함수도 인자(데이터)를 받을 수 있어서, 받은 데이터를 이용하여 화면을 렌더링하도록 함수를 작성. 반면에 Composale 함수는 반환값이 필요없음
- Composable 함수는 동일한 인자로 호출할 경우에 동일한 동작(렌더링)을 수행되어야 하고, 글로벌 변수나 random()함수 등의 외부요인으로 인해 동작이 변경되어서는 안됨!
댓글 없음:
댓글 쓰기