BigJeon Android 개발 블로그
Android Compose를 활용 해야 하는 이유에 대하여 알아보자... 본문
안녕하세요 Android Native 개발자 BigJeon입니다!
오늘은 요즘 새로운 Android 개발 트렌드중 당연코 1위 Compose에 대하여 알아보고,
왜 Compose를 사용해야하는가에 대한 지극히 개인적인 생각을 포스팅 해볼까 합니다!
1. Compose란?
우선 Compose가 무엇인지? Android 공식 문서를 살펴보고 가보도록 하겠습니다!
위 링크를 눌러서 들어가보면 대문짝하게 쓰여있는 글귀다.
Jetpack Compose라고 명칭이 되어있는걸 보았을때 Compose가 Android jetpack의 일부인 것을 알 수 있다!
Jetpack에 대한 내용은 다음에 따로 포스팅 하도록 하겠다!
'jetpack Compose는 네이티브 UI를 빌드 하기 위한 Android 최신 권장 도구 키트 입니다.'
권장이란 단어는 Kotlin이 정식으로 채택 되었을때도 봤었던 단어이다.
사실 Compose가 무엇이냐고 말하면 위의 한줄로 표현이 가능하다
(물론 React Native와 같은 선언형 UI 이다 라는 문구가 포함되어있으면 더 좋을거 같다고 생각한다.)
그만큼 Android UI를 빌드하는데 최적화된 Tool인것을 알 수 있는데, 그 이유는 뒤에 나오는 글을 보면 알 수 있다.
현재 Compose를 많이 다루어 본적은 없지만, 그 짧은 경험에도 저 뒤에 나온 글귀에 대하여 격하게 공감하였다.
2. 선언형 UI?
사실 기존에 XML로 UI를 구성 하는 방식이 익숙한 개발자라면 선언형 UI의 필요성을 잘 못 느낄 수 도 있다고 생각한다.
(나도 Compose 를 써보기 전까진 그랬다...)
선언형 UI란?
한 정의에 따르면, 프로그램이 어떤 방법으로 해야 하는지를 나타내기보다 무엇과 같은지를 설명하는 경우에 "선언형"이라고 한다. 예를 들어, 웹 페이지는 선언형인데 웹페이지는 제목, 글꼴, 본문, 그림과 같이 "무엇"이 나타나야하는지를 묘사하는 것이지 "어떤 방법으로" 컴퓨터 화면에 페이지를 나타내야 하는지를 묘사하는 것이 아니기 때문이다. 이것은 전통적인 포트란과 C, 자바와 같은 명령형 프로그래밍 언어와는 다른 접근방식인데, 명령형 프로그래밍 언어는 프로그래머가 실행될 알고리즘을 명시해주어야 하는 것이다. 간단히 말하여, 명령형 프로그램은 알고리즘을 명시하고 목표는 명시하지 않는 데 반해 선언형 프로그램은 목표를 명시하고 알고리즘을 명시하지 않는 것이다.
명령형 방식(WHAT?)의 경우 알고리즘을 명시하고 목표는 명시하지 않고, 선언형 (HOW?) 은 알고리즘을 명시 하지 않고 목표를 명시한다...
요약하자면 이정도 인건데, 사실 그렇게 쉽게 이해 할 만한 정의는 아닌거같다....
쉽게 예제를 비교해서 보자면,
선언형 UI와 명령형 UI에 대한 자료 조사중 좋은 예시가 있어서 가져왔다!
좌측의 경우가 평소 우리가 사용하던 UI 선언 방식이다.
위에서 말했듯 명령형의 경우 What?이라는 키워드가 중요한데,
1. B라는 이름의 view를 생성한다
2. B의 색상을 빨간색으로 설정한다
3. B의 자식 View를 초기화한다
4. C3이라는 ViewC를 생성한다
5. B에 C3을 자식으로 추가한다
이렇듯 명령어의 경우 View에세 이렇게 해! 저렇게 해! 라는식으로 '~한다'라는 표현으로 나타내게된다.
하지만 우측의 선언형을 보면
1. B라는 View를 생성하는데, 그 View의 배경은 빨간색이고, 자식 View로는 ViewC가 있다.
이렇게 한줄로 표현이 가능해지며, 우리는 빨간색의 view를 만들거야~ 라는 표현으로 나타내진다.
이러한 부분을 통해 간결한 코드, 재사용성 증가, 직관성, 빠른 개발등이 가능해진다.
3. 그래서 왜 Compose를 사용 해야 하는가?
만약 특정 View를 재사용 해야하는 상황이 생긴다고 가정을 해보자명령형 방식의 경우
1. 커스텀 View 클래스 생성 및 커스텀 View 속성 선언
2. 해당 CustomView를 이용한 layout .xml 작성
3 JAVA or Kotlin 코드를 통한 View 속성 지정 코드 작성
이외에도 다양한 작업들이 필요하며, 해당 작업을 하는데 작성 해야하는 코드 라인 또한 적지 않다.
선언형 UI의 경우
1. 나타낼 View 속정 시정 및 정의(하나의 Object로 만든다)
2. 필요한 부분에 알맞게 Parameter값을 변경 하여 필요시 마다 호출해서 사용
이게 끝이다....개인적으로 필자는 RecyclerView를 사용할때 앞으로는 Compose를 주로 사용하게 되겠구나라고 느꼈는데,
@Composable
fun MainListView() {
LazyColumn() {
items(items = item) { item ->
ItemView(item = item)
}
}
}
}
@Composable
fun ItemView() {
Text("HelloWorld")
}
이게 끝이다...(기존의 Adapter속성 지정해주고 했던거 생각하면 못해도 200줄은 가뿐하게 넘겼던거같은데....)
좀 극단 적인 예시이긴 하지만 Compose를 직접 사용 해 본 결과 기존 XMl형식을 이용한 앱 개발 방식 대비 코드 라인 수가 많게는 절반정도 줄어든 결과가 발생했다!!(선언형 왜 이제 알았을까...)
거기에 MVVM패턴, MVC패턴 등 다양한 디자인 패턴을 적용 하여 개발을 진행 할 경우(특히 ViewModel을 이용한 DataBinding 사용 시), 개인적으로 XML 코드와 ViewModel의 데이터를 연결 해주는 기능을 구현 할 때 억지로 맞춰서 끼우는 느낌이 강했고, 코드 또한 가시성이 많이 떨어졌다.
하지만 Compose를 이용한다면 더욱 확실 하게 각각의 기능, 목적 별 구분이 가능 해 졌고, 무엇보다 XML코드 작성의 불필요성으로 인한 개발 기간 단축 또한 상당히 와닿았다.
Compose에 더욱 자세하게 다루기에는 포스팅이 너무 길어질거 같기도 하고 사실 마지막 3.그래서 왜 Compose를 사용 해야 하는가? 섹션만 봐도 Compose의 필요성은 충분히 느낄 수 있을거라고 생각한다.
결론!! : 필자는 앞으로 Compose를 주력으로 사용 하게 될거 같다......(이 기회에 React Native도 한번....)
'AOS - Compose' 카테고리의 다른 글
| Compose - Preview 영역을 표시해주는 라이브러리 추천 (0) | 2024.10.28 |
|---|---|
| Compose - Preview에 ViewModel 연결하기(with FakeViewModel) (0) | 2024.10.28 |
| Compose의 화면 갱신 원리에 관하여... (0) | 2024.08.15 |
