jetpack compose - 코드 기반 UI 작성

 안드로이드로 열심히 작업을 하는 중에 jetpack compose라는 친구를 발견하게 되었습니다. 사실 이전에도 다른 아티클들 사이에서 여러번 봤었던 키워드이긴 한데, 그냥 jetpack의 구성요소겠거니 싶어 아는 내용(필요할 때 그때 찾아봐도 충분할 거라는 오만?)이라고 생각하고 덮어뒀던게 화근이 된 것 같습니다.

 그래서 이번에 제대로 발견한 김에 이 jetpack compose가 무엇인지 알아보려고 합니다.(근데 사실 이게 안드로이드 UI 제작 기법이긴 한데 코틀린으로 작성해둬서 안드로이드 태그에 넣을지 코틀린 태그에 넣을지 한참 고민했습니다.)

---

 jetpack compose가 무엇인지?

 jetpack compose는 코틀린 안드로이드에서 사용되는 코드 기반 UI로, 선언형 UI입니다. 안드로이드를 위해 구글이 개발한 UI ToolKit이죠. 이 jetpack compose는 기존에 사용하던 xml 기반의 UI보다 훨씬 코드를 간결하게 작성할 수 있고 재사용성을 높여준다는 장점을 지니고 있습니다. 이는 전체적으로 선언형 UI가 지닌 장점이라고 볼 수 있겠습니다.

@Composable
fun Step(number: Int) {
    Row(
        modifier = Modifier
            .fillMaxSize()
            .background(Color.White)
    ) {
        Box(modifier = Modifier
            .weight(1f)
            .fillMaxHeight()
            .clickable {
                flipBack()
            })

        Box(
            modifier = Modifier
                .weight(1f)
                .fillMaxHeight()
        ) {
            Text(
                modifier = Modifier.align(Center),
                text = number.toString(), color = Color.Black, fontSize = 40.sp
            )
        }

        Box(modifier = Modifier
            .weight(1f)
            .fillMaxHeight()
            .clickable {
                flipNext()
            })
    }

}

 

(이런식으로 작성되어 있는 코드입니다.)

 jetpack compose의 특징은 무엇이 있을까?

• only Kotlin(자바에서는 사용할 수 없습니다.)
• Min SDK version 21(Android 5.0)
• 선언형 UI Tool Kit (No XML)
• 상속이 아닌 확장 기반

 

only Kotlin

 아쉽게도 jetpack compose는 기본 구성이 코틀린에서만 존재하는 여러가지 기능들(코루틴 및 @Composable 등)을 사용하고 있기 때문에 자바와 혼용해서 사용하는 경우 jetpack compose 도입이 어렵습니다. 새로운 기능이 등장했을 때 자바와 연동을 고려하뎐 구글이 더이상 자바와 혼용할 수 없는 코드를 늘리는 것으로 보아 차츰차츰 확실히 IOS - Swift와 같이 안드로이드 - Kotlin 생태계를 구성하고 싶어하는 것으로 보입니다.

Min SDK version 21(Android 5.0)

 딱히 특별히 설명할 것은 없지만, Min SDK 가 21이상은 되어야 하니 그 아래 버전에서 안드로이드 앱을 지원해주지 않을 생각으로 작성해야 한다는 것을 의미합니다.

API 별 안드로이드 점유율(2022년 2월 11일 기준)

 현재 점유율을 보면 이제 Min SDK가 21이상이라는 것은 거의 대부분의 사용자를 고려한다는 사실을 확인할 수 있습니다.

선언형 UI Tool Kit (No XML)

 기존 명령형 UI로 작성하던 UI가 선언형 UI로 바뀝니다. 선언형 UI는 기존의 뷰 작업을 개발자가 코드에서 직접 처리해주던 것을 프레임워크 안으로 집어넣은 형태로 볼 수 있습니다. 최적화 및 상세 사항들은 프레임워크 내부에서 처리하고, 사용자는 UI에 필요한 state만 전달해주면 되는 형태입니다. 이러한 선언형 UI는 현재 SwiftUI와 플러터, 그리고 Jetpack Compose입니다.

상속이 아닌 확장 기반

 기존 안드로이드에서 사용하던 XML 기반의 View들은 기본적으로 Object 클래스를 상속받는 View를 상속받는 형태로 이루어져 있습니다. Button도 View를 상속받는 형태이고 ImageButton도 그 Buttom을 상속받는 형태로 이루어져 있습니다. 그러다 보니 무언가가 추가될 때 계속해서 코드가 불어나는 형태가 되고 있었습니다. 그러나 jetpack compose는 그것을 회피하고 싶어 만들어낸 코드이기 때문에 각 뷰를 상속하는 것이 아니라 각각 따로 동작하는 형태로 이루어져 있습니다.

 jetpack compose의 장점

• 코드 감소: 기존 XML 코드보다 많은 부분들이 감춰져 있고, 재사용성이 뛰어남
• 직관적: UI 상태의 업데이트는 프레임워크 내부에서 이루어집니다.
• 의존성 하락: 기존 View 코드는 View와 연결된 Kotlin/java 코드와의 의존성이 매우 높은 편이었으나, compose의 경우 매우 낮춰줄 수 있음
• 구글이 밀어주고 있는 언어: 안드로이드의 최종 종착점은 Kotlin + Jetpack이 될 듯(물론 jetPack도 언제 사라질 지 모르지만...)

 

 jetpack compose의 단점

• 아직은 많지 않은 예제와 라이브러리들
• java 코드로 작성 불가

 

---

 jetPack Compose는 결국 구글에서 이때까지 사용하던 XML 기반 UI처리가 더 이상 유지보수가 어렵고, 개발자들의 코드 레거시를 늘린다는 판단하게 만들어진 것이기 때문에 시간이 지날수록 서서히 안드로이드도 선언형 UI를 기반으로 개발하게 될 것입니다. 지금에서야 새로 배우는 과정이니 러닝 커브가 존재하고, java로 된 앱들이 많아 마이그레이션도 어렵지만, 시간이 지나 많은 사람들이 학습을 공유하고 오픈소스 라이브러리들을 만들기 시작하면 결국 많은 앱들이 jetPack Compose로 작성되게 될 것 같습니다.

 새로 배우는 과정이라면 두 가지 UI 제작 방식 모두 고려하면서 작성하는 것이 미래를 위해서도 현명하지 않을까... 그런 생각이 듭니다.(구글이 안드로이드를 버릴 이유는 없지만 점점 코드가 플러터를 닮아가는게, 안드로이드를 버리고 플러터로 갈아탈지도 모른다는 생각은 살짝 드네요.)