Android 컴포즈를 쓰는 이유는?

1. 안드로이드 버전 변화

1.0 (2008년 9월 23일)

1.1 Petit Four (2009년 2월 9일)

1.5 Cup Cake (2009년 4월 27일)

1.6 Donut (2009년 9월 15일)

2.0 Eclair (2009년 10월 27일)

2.2 Froyo (2010년 5월 20일)

2.3 Gingerbread (2010년 12월 6일)

3.0 Honeycomb (2011년 2월 22일) Holo

4.0 Ice Cream Sandwich (2011년 10월 18일)

4.1 Jelly Bean (2012년 7월 9일)

4.4 Kitkat (2013년 10월 31일)

5.0 Lollipop (2014년 11월 4일) Material

6.0 Marshmallow (2015년 10월 2일)

7.0 Nougat (2016년 8월 22일)

8.0 Oreo (2017년 8월 21일)

9 Pie (2018년 8월 6일)

10 (Q) (2019년 9월 3일)

11 (R) (2020년 9월 8일)

12 (S) (2021년 10월 4일)

Tiramisu (2022년 8월 15일)

 

스큐어모픽이 대세였다가 3.0부터 플랫 디자인 시도!

4.4 킷캣에 이르러서 대중화가 되었다.

5.0 롤리팝부터 머터리얼 디자인 등장(Holo,Kennedy 등 혼재되어있던 상황을 정리해줌)

⇒ 재질들이 쌓여있는 느낌이다.

 

Databinding은 MVVM에서 자주사용.

하지만 MVVM을 모든 개발자들이 좋아하는건 아니라서 view binding이 나옴.

2. JetPack

명령형 UI : 기존 개발자들에게 가장 친숙한 형태로 메뉴얼하게 화면에 UI View를 추가하거나 삭제할 수 있는 형태의 프레임워크를 말한다. (XML같은)

 

선언형 UI : 코드 상에 추가한 화면 View는 더이상 추가하거나 삭제 할 수 없고 화면을 변경하기 위해선 새롭게 만들어야 한다. 여기서 State 라는 개념이 도입되는데 선언형 UI에선 뷰마다 State가 있고 이 State값이 변경하게 되면 새로운 화면을 생성해서 다시 화면을 업데이트 하게 된다.

선언형 UI에선 UI 의 변경 사항은 프레임워크에서 담당하도록했기 때문에 개발자는 화면이 변경할 때 발생할 수 있는 오버헤드는 신경쓸 필요가 없고 State 변화에만 집중 할 수 있어 개발하기 편리해진다. 지금까지 명령형 UI를 사용한 개발자 입장에선 State라는 새로운 개념이 익숙하진 않을 수 있지만 사용하다보면 확실히 잔업무가 줄어드는 것을 느낄 수 있다. 선언형 UI는 리액트를 사용하는 웹에서 주로 사용되다가 현재는 플러터, Swift UI, Android Jetcompose과 같은 새로운 UI 프레임워크가 등장하면서 모바일에서도 적용되는 추세다. 앞으로도 다양한 프레임워크에서 선언형 UI를 채택하게 될 것 같다.

 

jetpack 장점

• 상호작용 ◦ 컴포즈는 기존 앱과 상호작용 가능함. ◦ View들을 컴포즈 UI 안에 넣을 수 있고 컴포즈를 뷰 안에 넣을 수 있음.
• 젯팩 통합 ◦ Compose는 Jetpack과 통합되도록 설계됨. ◦ Navigation, Paging, LiveData, Flow/RxJava, ViewModel, Hilt
• 머터리얼
  • 머터리얼 디자인 컴포넌트와 테마를 제공.
  • 아름다운 앱을 만들고 브랜드를 표현.
  • 복잡한 XML을 다루지 않고 이해하기 쉽고 추적하기 쉬움.

"동일한 버튼 클래스의 경우 [코드] 의 규모가 10배 더 작았습니다.” (Twitter)

“RecyclerView로 빌드한 모든 화면에서 상당한 감소 효과가 나타났 으며, 대부분의 화면이 여기에 해당합니다.” (Monzo)

“앱에서 목록이나 애니메이션을 만드는 데 필요한 코드 줄이 이렇게 적다는 사실이 매우 기뻤습니다. 기능마다 작성하는 코드 줄 수가 줄 어든 덕분에 고객에게 가치를 제공하는 데 더욱 집중할 수 있게 되었 습니다.” (Cuvva)

“Kotlin과 XML 사이를 전환하는 것이 아니라 모든 것이 같은 언어 로 종종 같은 파일에서 작성되면 코드를 추적하기가 훨씬 쉬워집니 다.” (Monzo)

“Compose의 레이아웃 시스템은 개념적으로 더 단순하기 때문에 추론하기도 쉽습니다. 복잡한 구성요소의 코드도 쉽게 읽을 수 있습 니다.” (Square)

"테마 레이어가 훨씬 더 직관적이고 읽기 쉽습니다. 멀티 레이어 테 마 오버레이를 통해 속성을 정의하고 할당하는 여러 XML 파일로 확 장해야 했을 일을 단일한 Kotlin 파일 내에서 달성할 수 있었습니 다.” (Twitter)

"사용 및 유지관리가 쉽고 구현/확장/맞춤설정이 직관적인 스테이 트리스 UI 구성요소의 새로운 세트를 제공하겠다는 목표를 세웠습 니다. Compose는 이를 위한 좋은 해답이었습니다.” (Twitter)

“추론하는 동안 기억해야 하는 사항이 줄어들고 통제를 벗어나거나 제대로 이해하지 못하는 행동도 적어집니다.” (Cuvva)

“상호 운용성에서 Compose 통합이 시작되었으며 '사용하기 쉽다' 는 사실을 알았습니다. 밝은 모드와 어두운 모드 등을 신경 쓸 필요 가 전혀 없었고 전반적인 사용 환경이 매우 완벽했습니다.” (Cuvva)

"Android 스튜디오의 미리보기 덕분에 시간이 크게 절약되었습니 다. 또한 여러 미리보기도 빌드할 수 있기 때문에 시간이 절약됩니 다. 오류 상태나 여러 가지 글꼴 크기처럼 상태와 설정이 다양한 UI 구성요소를 확인해야 하는 경우가 많습니다. 이때 여러 미리보기를 만들 수 있으므로 확인하기가 쉽습니다.” (Square)

"Compose는 선언적 UI보다 더 많은 문제를 해결하기도 했으며 접 근성 API, 레이아웃 등 모든 항목이 개선되었습니다. 만들고 싶은 것 과 실제로 만드는 것 사이의 차이가 줄어듭니다.”(Square)

“애니메이션을 Compose에 쉽게 추가할 수 있으니 색상/크기/고도 변경 등을 애니메이션으로 처리하지 않을 이유가 없습니 다.”(Monzo)

“특별한 도구가 없어도 애니메이션을 만들 수 있습니다. 정적 화면을 표시하는 것과 다르지 않습니다”(Square)

"머티리얼 디자인을 기반에서 분리하면 정말 유용합니다. 자체 디자 인 시스템을 구축하다 보면 머티리얼과 디자인 요구사항이 다른 경 우가 많기 때문입니다.” (Square)

3. jetpack 활용사례

a.트위터

• Twitter 앱은 10년에 걸친 레거시.
• 확장 가능한 디자인 시스템 구축을 원함.
• 컴포즈 선택 ◦ 사용 및 유지관리가 용이한 stateless UI 콤포넌트 ◦ 확장과 커스터마이징이 편함. ◦ 컴포넌트 단위로 레거시 설정에 의존하지 않고 변경함.

b.스퀘어

• 스퀘어는 POS, 결제 등을 만드는 회사.
• Retrofit(restAPI, json을 어케 다룰건데 ?), OkHttp, Dagger 1, Picasso(글라이드에 미밀리고 있음), Moshi(json 라이브러리), Javapoet 오픈소스 라이브러리 강자.
• Square는 이미 선언형 도구 (Workflow)로 앱을 개발했었음. MVI에 가까운 Unidirectional Data Flow.
• 하지만 UI는 Mosaic란 내부 툴을 사용했지만 Jetpack Compose로 변경.
• Android 도구와의 통합의 장점이 있다.

c.몬조 (카카오뱅크같은 곳)

d.구글플레이

• View - 3개의 클래스. 350라인의 자바, 55라인의 XML
• Compose - @Composable 함수로 같은 파일 같은 언어. 210라인 의 코틀린.