<div id="readability-page-1" class="page"><div><article><div><div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*8uwdS__-0pFWbQKRXMyTHw.png" width="700" height="240" role="presentation"></p></div></figure><p id="abd3">안녕하세요, 저는 왓챠에서 Android 개발자로 일하고 있고 Browsing 1 Squad에서 Android TV앱을 개발하고 있는 doro입니다.</p><p id="17bb">왓챠는 다양한 기기를 지원합니다. Browsing 1 Squad는 왓챠에서 지원하고 있는 다양한 기기 중 대화면 기기 (Web TV, Android TV, PlayStation 등)에 집중한 팀입니다. Browsing 1 스쿼드원들은 유저들이 큰 화면으로 왓챠를 이용할 때 어떻게 더 좋은 경험을 할 수 있을까 매일 매일 고민하고 있습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*A83K9iGz0w3IqGPkaZeu1w.png" width="700" height="406" role="presentation"></p></div><figcaption>WATCHA</figcaption></figure><p id="4105">이번 스프린트에는 안드로이드 팀 peter, aiden과 함께 Android TV용 왓챠 앱의 설정페이지를 개선하는 작업을 했습니다.</p><p id="52d9">설정페이지는 유저의 다양한 정보를 간략하게 보여주고 왓챠를 이용하는데 필요한 설정값들을 직관적으로 변경할 수 있는 페이지입니다.</p><figure><p><img alt="" src="https://miro.medium.com/max/1200/1*LymORD7E7aysmIh6Me7wqg.gif" width="600" height="343" role="presentation"></p><figcaption>개선된 설정페이지</figcaption></figure><p id="0d5f">개선된 설정페이지는 구조는 간단하지만 메뉴간의 이동에 따라 다양한 UI가 제공되는 동적인 페이지 입니다. 메뉴의 상태에 따라서 메뉴 자체의 UI가 달라지기도 하구요.</p><h2 id="f743">어쩌다 Compose를</h2><p id="aece">처음에 디자인 시안을 봤을 때 느꼈던 점은 그렇게 어렵진 않겠다는 생각이었습니다. 복잡한 애니메이션이 들어가거나 새로운 개념의 UI가 있는 화면도 아니었으니깐요.</p><p id="7f58">그런데 이를 기존의 Android View 방식으로 구현하려고 하면 수 많은 <code>Boiler Plate</code>코드가 발생하게 되거나 구조적으로 복잡하게 되었습니다. 저는 딜레마에 빠지게 되었죠.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*1jmVbjEcQF0pIoN5rkci_Q.png" width="700" height="395" role="presentation"></p></div><figcaption>설정페이지 구조</figcaption></figure><ul><li id="a3c1">간단한 코드와 파악하기 쉬운 구조로 짜려니 <code>Boiler Plate</code>코드가 너무 많다.</li><li id="bb2c">중복 코드를 줄이려니 추상화가 많이 들어가고 로직이 복잡해져 구조 파악이 힘들다.</li></ul><p id="ed36">어떤 식으로든 내 코드를 본 다른 개발자가 저를 욕하거나 원망할 것만 같았습니다.</p><p id="88f7">이 때, 머릿속에 Compose가 스쳐지나갔습니다. Compose는 적은 코드와 직관적인 Kotlin API로 선언적 프로그래밍이 가능하여 상태값 관리에 훨씬 용이하다고 <code>Android Developer Document</code>에 소개 되어있었기에, 많은 고민 끝에 도입하기로 결정했습니다.</p><p id="5954">잘한 일 일까요? 왜 저희는 Compose를 도입하려 했고, 어떤 이득이 있었는지에 대해서 포스팅 해보았습니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*fjsJ8iw8QB_HzAGmDsvY8g.png" width="700" height="336" role="presentation"></p></div><figcaption>Hello Compose</figcaption></figure><h2 id="b241">Compose는 UI Toolkit이니깐요</h2><p id="d948">Compose는 <strong>선언형 프로그래밍</strong>이 가능하다고 합니다. 이는 UI 코드를 작성할 때, 상태에 따른 UI의 변화를 정의할 수 있다는 것을 의미합니다. UI를 그릴때 필요한 데이터들이나 이벤트가 발생할 때 필요한 callback 함수만 주입받는다면 원하는 Compose를 만들 수 있습니다.</p><p id="4010"><strong>UI의 변경은 오직 그 Compose안에서만 발생하게 되는것이죠. </strong>이는 구조적으로 엄청난 편리함을 가져다 줍니다. 예를 들어, 이럴 때 유용합니다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*mw_BL4FRT6KmERcm3gJvSg.png" width="700" height="413" role="presentation"></p></div><figcaption>메뉴의 선택에 따른 상태 변화</figcaption></figure><p id="f69f">위 화면은 설정페이지에서 유저들이 선택하는 메뉴의 UI입니다.</p><p id="f01d">메뉴는 선택되었을 때는 <code>focused</code> , 선택된 상태로 하위 메뉴로 넘어갔을 경우에는 <code>semi-focused</code> , 선택되지 않았을 때는<code>unfocused</code> 의 상태값을 가지게 됩니다.</p><p id="3247">만약, View 방식으로 UI코드를 작성할 때, 메뉴가 리모컨에 의해서 선택되었다면 내부적으로 어떤 일이 발생할까요?</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*rkfBNQDJ-Ce_Bys0K8MwIg.png" width="700" height="123" role="presentation"></p></div></figure><p id="5678">리모컨 이벤트를 받아서 처리하는 코드는 <code>Fragment</code>에 존재하게 되고, 이 이벤트는 <code>Adapter</code>와 <code>ViewHolder</code>를 통해서 <code>item_menu.xml</code>에게 전달되어 UI의 변경이 이루어지게 됩니다.</p><p id="a0c4">만약 <code>Fragment</code>에서 이벤트는 발생하는데 <code>ViewHolder</code> 까지 이벤트가 전달이 되지 않는다면 어떻게 해야할까요? 각 구간별로 디버깅을 해야합니다. 이는 UI변경을 명령형으로 프로그래밍해서 발생하는 문제입니다.</p><p id="0482">UI가 작성되어있는 코드와 UI를 변경하는 코드가 분리되어 있다보니 에러도 쉽게 발생하고, 구조도 복잡해지고, 디버깅도 더 힘들게 됩니다. 그렇다면 선언형 프로그래밍은 어떨까요?</p><figure></figure><p id="f099"><code>MenuItemView</code> 라는 @Composable 함수는 Compose를 이용해 UI가 작성된 코드입니다. 이 함수 내부에는</p><ul><li id="86ef">이벤트가 발생했을 때 실행하는 코드 — <code>Modifier.onFocusChanged</code></li><li id="5155">이벤트에 따라변화하는 상태값 —<code> isFocused.value = it.isFocused</code></li><li id="a7d8">상태값에 따라 변화하는 UI —<code> if (isFocused.value) ...</code></li></ul><p id="86f3">이 세 종류의 코드가 모두 한 메소드에 작성되어 있어서 디버깅하기도 편하고, 피쳐가 추가된다 해도 유지보수가 아주 용이해집니다. 같은 공간에서 UI가 변경되다보니 여러 클래스의 결합도가 없어지는 것도 큰 장점입니다.</p></div><div><p id="f4bf">또 이런식의 선언형 프로그래밍은 UI의 관심사도 자연스럽게 분리해줍니다. UI와 관련된 상태만 정의하게 되고 UI로직외의 이벤트들은 주입을 받게 됩니다. 메뉴에서도 <code>onFocusChanged</code> 라는 콜백함수를 주입받는 것처럼 말이죠</p><pre><span id="cd72">@Composable<br>fun MenuItemView(    <br><strong><em>    item: MenuItem,    <br>    onFocusChanged : (MenuItem, FocusState) -&gt; Unit,  <br>    isSemiFocused: Boolean = false</em></strong><br>) {<br>    ...<br>}</span></pre><p id="01d4">MenuItemView UI를 만들기 위해서 필요한 <code>parameter</code> 는</p><ul><li id="f3e2">MenuItem</li><li id="9260">(MenuItem , FocusState) -&gt; Unit</li><li id="af5f">Boolean</li></ul><p id="3afb">이렇게 3개 입니다. Compose입장에서는 비즈니스 로직이나 도메인 코드들은 모두 주입을 받고, 자신은 주입받은 데이터들을 기반으로 UI를 그리는데만 집중을 하고 있습니다.</p><p id="462d"><strong>즉 View 로직의 관심사 분리가 자연스럽게 가능해집니다</strong>.</p><h2 id="a5d6">털끝까지 재활용</h2><p id="7dca">Compose의 또 하나의 매력은 코드 재사용성이 엄청나다는 것입니다. 기존 View방식에서는 재사용하려면 <code>Boiler Plate</code> 코드가 더 발생하는, 배보다 배꼽이 큰 상황이 되어서 <strong>“재사용은 하지말고 내가 더 꼼꼼히 관리해야지”<em> </em></strong>라고 생각하고 넘어갔던 코드들 조차도 전부 재사용해서 하나의 UI코드로 관리할 수 있습니다.</p><p id="6b92">위의 화면들은 설정페이지 계정 정보에서 확인할 수 있는 화면입니다. 화면 상단에 Title과 Description이 공통으로 있고 하단에는 각 기능들에 대한 slot 페이지가 존재하고, 버튼까지 존재하는 페이지도 있군요.</p><p id="eb50">대략적인 구조는 다음과 같습니다.</p><figure><p><img alt="" src="https://miro.medium.com/max/422/1*9obJpdujFPIUjMpL3YhowQ.png" width="211" height="286" role="presentation"></p><figcaption>Content Screen Architecture</figcaption></figure><p id="0863">이렇게 구조만 나눌 수 있다면, 각각의 컴포넌트들에 대해 Composable함수를 만들 수 있습니다.</p><figure></figure><p id="71bb"><code>TitleView</code> , <code>DescriptionView</code> , <code>ContentView</code> , <code>CommonButtonView</code> 이 4개의 함수의 조합으로 위 화면을 구성 가능하게 됩니다. 각 함수의 파라미터로 원하는 데이터만 전달을 해주면 코드의 재사용이 되기 때문이죠.</p><p id="3c38">또, 이런 종류의 UI는 어떨까요</p><ul><li id="e4e4">문의하기 — 모바일, pc로 문의하는 <code>route</code></li><li id="5f8d">이용권 업그레이드 — 프리미엄 티켓의 스펙</li><li id="52fb">디바이스 정보 — 현재 유저의 기기 및 앱 정보</li></ul><p id="9e58">아주 소소하게 코드의 재활용을 요구하는 UI입니다.</p><p id="4903">각각 <code>RecyclerView</code>와 <code>Adapter</code>와 <code>ViewHolder</code> , <code>item.xml</code>을 만들어야할까요? 또는 <code>item.xml</code>을 <code>&lt;include&gt;</code> 태그를 이용하거나 <code>CustomView</code>에서 데이터를 결합 시켜줘야 할까요? 그것도 아니라면 내가 잘 관리한다는 마음을 먹고 통째로 하나의 <code>layout.xml</code>파일에 담는게 좋을까요?</p><p id="decc">Compose에서는 아주 간단한 구조로 코드 재사용이 가능했습니다.</p><figure></figure><p id="cb77">이렇게 모두 Compose로 구현한다면 각각의 화면에 해당하는 @Composable 함수를 만들어주고 호출하는 방식으로 UI 로직을 구성함으로써, 간단한 구조와 코드의 재활용이라는 두 마리의 토끼를 모두 잡을 수 있습니다.</p><h2 id="81a7">@Preview는 Free덤</h2><p id="c27e">마지막으로 Compose를 사용하면서 소소하게 좋았던 기능은 @Preview입니다. @Preview를 사용하면 앱을 실행하지 않고 Android Studio 내부에서 빌드를 해 여러 상태에 대해 UI를 확인할 수 있어 기존 xml에서 UI를 확인하는 것보다 좀 더 쉽게 디버깅을 할 수 있었습니다.</p><pre><span id="1523">@Repeatable<br>annotation class Preview(<br>    val name: String = "",<br>    val group: String = "",<br>    @IntRange(from = 1) val apiLevel: Int = -1,<br>    // TODO(mount): Make this Dp when they are inline classes<br>    val widthDp: Int = -1,<br>    // TODO(mount): Make this Dp when they are inline classes<br>    val heightDp: Int = -1,<br>    val locale: String = "",<br>    @FloatRange(from = 0.01) val fontScale: Float = 1f,<br>    val showSystemUi: Boolean = false,<br>    val showBackground: Boolean = false,<br>    val backgroundColor: Long = 0,<br>    @UiMode val uiMode: Int = 0,<br>    @Device val device: String = Devices.DEFAULT<br>)</span></pre><p id="906c">Preview는 <code>width</code>, <code>height</code>부터 <code>locale</code>, <code>UiMode</code>, <code>Device</code>등 다양한 조건을 주입받아 미리보기를 생성할 수 있게 해줍니다. 왓챠같은 다국어 언어를 지원하는 서비스의 경우에도 정말 유용하게 사용할 수 있었죠.</p><div><figure><p><img alt="" src="https://miro.medium.com/max/1128/1*9IVlM73u1JMyoLKFnL7lqw.png" width="564" height="603" role="presentation"></p></figure><figure><p><img alt="" src="https://miro.medium.com/max/1134/1*lnXuT5yMA0h2m5f3R-2WZQ.png" width="567" height="604" role="presentation"></p></figure><figure><p><img alt="" src="https://miro.medium.com/max/1148/1*lmcnJypxLGeR7kvMugxz1Q.png" width="574" height="614" role="presentation"></p><figcaption>기본 / 일본어 / 모델명이나 이메일이 긴 경우</figcaption></figure></div><p id="4994">이런식으로 @Preview 어노테이션을 적극적으로 이용한다면 프로덕트 코드의 변화에 따라서 미리 정의해둔 @Preview Composable 함수들이 변화하는 것을 IDE에서 확인할 수 있습니다.</p><p id="c992">자신이 원하는 기기, 기기의 상태 등 다양한 환경에서의 결과물을 바로 IDE에서 확인할 수 있어서 , 여러 가지 테스트 케이스를 먼저 정의해놓는 TDD형식의 개발방식도 충분히 도입할 수 있겠다는 생각이 들었습니다.</p><h2 id="383c">마치며</h2><p id="e810">Compose를 도입하면서 코드를 깔끔하게 줄일 수 있었고, UI로직과 비즈니스 로직의 관심사 분리를 자연스럽게 할 수 있어 너무 좋았습니다. 또한 UI 디자인도 더욱 디테일하게 관리할 수 있게 되어서, 앞으로도 왓챠의 많은 UI를 Compose로 작성할 예정입니다.</p><p id="af51">왓챠에서는 언제나 더 효율적인 방법과 개선 방향을 찾고 있습니다. 더 좋은 서비스 경험을 함께 고민하고 싶다면, 아래 공고를 확인해주세요.</p></div></div></article></div></div>

WATCHA - Medium

안녕하세요, 저는 왓챠에서 Android 개발자로 일하고 있고 Browsing 1 Squad에서 Android TV앱을 개발하고 있는 doro입니다.
왓챠는 다양한 기기를 지원합니다. Browsing 1 Squad는 왓챠에서 지원하고 있는 다양한 기기 중 대화면 기기 (Web TV, Android TV, PlayStation 등)에 집중한 팀입니다. Browsing 1 스쿼드원들은 유저들이 큰 화면으로 왓챠를 이용할 때 어떻게 더 좋은 경험을 할 수 있을까 매일 매일 고민하고 있습니다.
이번 스프린트에는 안드로이드 팀 peter, aiden과 함께 Android TV용 왓챠 앱의 설정페이지를 개선하는 작업을 했습니다.
설정페이지는 유저의 다양한 정보를 간략하게 보여주고 왓챠를 이용하는데 필요한 설정값들을 직관적으로 변경할 수 있는 페이지입니다.
개선된 설정페이지는 구조는 간단하지만 메뉴간의 이동에 따라 다양한 UI가 제공되는 동적인 페이지 입니다. 메뉴의 상태에 따라서 메뉴 자체의 UI가 달라지기도 하구요.
어쩌다 Compose를
처음에 디자인 시안을 봤을 때 느꼈던 점은 그렇게 어렵진 않겠다는 생각이었습니다. 복잡한 애니메이션이 들어가거나 새로운 개념의 UI가 있는 화면도 아니었으니깐요.
그런데 이를 기존의 Android View 방식으로 구현하려고 하면 수 많은 Boiler Plate코드가 발생하게 되거나 구조적으로 복잡하게 되었습니다. 저는 딜레마에 빠지게 되었죠.
간단한 코드와 파악하기 쉬운 구조로 짜려니 Boiler Plate코드가 너무 많다.
중복 코드를 줄이려니 추상화가 많이 들어가고 로직이 복잡해져 구조 파악이 힘들다.
어떤 식으로든 내 코드를 본 다른 개발자가 저를 욕하거나 원망할 것만 같았습니다.
이 때, 머릿속에 Compose가 스쳐지나갔습니다. Compose는 적은 코드와 직관적인 Kotlin API로 선언적 프로그래밍이 가능하여 상태값 관리에 훨씬 용이하다고 Android Developer Document에 소개 되어있었기에, 많은 고민 끝에 도입하기로 결정했습니다.
잘한 일 일까요? 왜 저희는 Compose를 도입하려 했고, 어떤 이득이 있었는지에 대해서 포스팅 해보았습니다.
Compose는 UI Toolkit이니깐요
Compose는 선언형 프로그래밍이 가능하다고 합니다. 이는 UI 코드를 작성할 때, 상태에 따른 UI의 변화를 정의할 수 있다는 것을 의미합니다. UI를 그릴때 필요한 데이터들이나 이벤트가 발생할 때 필요한 callback 함수만 주입받는다면 원하는 Compose를 만들 수 있습니다.
UI의 변경은 오직 그 Compose안에서만 발생하게 되는것이죠. 이는 구조적으로 엄청난 편리함을 가져다 줍니다. 예를 들어, 이럴 때 유용합니다.
위 화면은 설정페이지에서 유저들이 선택하는 메뉴의 UI입니다.
메뉴는 선택되었을 때는 focused , 선택된 상태로 하위 메뉴로 넘어갔을 경우에는 semi-focused , 선택되지 않았을 때는unfocused 의 상태값을 가지게 됩니다.
만약, View 방식으로 UI코드를 작성할 때, 메뉴가 리모컨에 의해서 선택되었다면 내부적으로 어떤 일이 발생할까요?
리모컨 이벤트를 받아서 처리하는 코드는 Fragment에 존재하게 되고, 이 이벤트는 Adapter와 ViewHolder를 통해서 item_menu.xml에게 전달되어 UI의 변경이 이루어지게 됩니다.
만약 Fragment에서 이벤트는 발생하는데 ViewHolder 까지 이벤트가 전달이 되지 않는다면 어떻게 해야할까요? 각 구간별로 디버깅을 해야합니다. 이는 UI변경을 명령형으로 프로그래밍해서 발생하는 문제입니다.
UI가 작성되어있는 코드와 UI를 변경하는 코드가 분리되어 있다보니 에러도 쉽게 발생하고, 구조도 복잡해지고, 디버깅도 더 힘들게 됩니다. 그렇다면 선언형 프로그래밍은 어떨까요?
https://medium.com/media/6c2dd20f776d0b8429108164e3065892/href
MenuItemView 라는 @Composable 함수는 Compose를 이용해 UI가 작성된 코드입니다. 이 함수 내부에는
이벤트가 발생했을 때 실행하는 코드 — Modifier.onFocusChanged
이벤트에 따라변화하는 상태값 — isFocused.value = it.isFocused
상태값에 따라 변화하는 UI — if (isFocused.value) ...
이 세 종류의 코드가 모두 한 메소드에 작성되어 있어서 디버깅하기도 편하고, 피쳐가 추가된다 해도 유지보수가 아주 용이해집니다. 같은 공간에서 UI가 변경되다보니 여러 클래스의 결합도가 없어지는 것도 큰 장점입니다.
또 이런식의 선언형 프로그래밍은 UI의 관심사도 자연스럽게 분리해줍니다. UI와 관련된 상태만 정의하게 되고 UI로직외의 이벤트들은 주입을 받게 됩니다. 메뉴에서도 onFocusChanged 라는 콜백함수를 주입받는 것처럼 말이죠
@Composable
fun MenuItemView(    
    item: MenuItem,    
    onFocusChanged : (MenuItem, FocusState) -> Unit,  
    isSemiFocused: Boolean = false
) {
    ...
}
MenuItemView UI를 만들기 위해서 필요한 parameter 는
MenuItem
(MenuItem , FocusState) -> Unit
Boolean
이렇게 3개 입니다. Compose입장에서는 비즈니스 로직이나 도메인 코드들은 모두 주입을 받고, 자신은 주입받은 데이터들을 기반으로 UI를 그리는데만 집중을 하고 있습니다.
즉 View 로직의 관심사 분리가 자연스럽게 가능해집니다.
털끝까지 재활용
Compose의 또 하나의 매력은 코드 재사용성이 엄청나다는 것입니다. 기존 View방식에서는 재사용하려면 Boiler Plate 코드가 더 발생하는, 배보다 배꼽이 큰 상황이 되어서 “재사용은 하지말고 내가 더 꼼꼼히 관리해야지” 라고 생각하고 넘어갔던 코드들 조차도 전부 재사용해서 하나의 UI코드로 관리할 수 있습니다.
위의 화면들은 설정페이지 계정 정보에서 확인할 수 있는 화면입니다. 화면 상단에 Title과 Description이 공통으로 있고 하단에는 각 기능들에 대한 slot 페이지가 존재하고, 버튼까지 존재하는 페이지도 있군요.
대략적인 구조는 다음과 같습니다.
이렇게 구조만 나눌 수 있다면, 각각의 컴포넌트들에 대해 Composable함수를 만들 수 있습니다.
https://medium.com/media/03002d2794ca5e131fa3547f7554bb57/href
TitleView , DescriptionView , ContentView , CommonButtonView 이 4개의 함수의 조합으로 위 화면을 구성 가능하게 됩니다. 각 함수의 파라미터로 원하는 데이터만 전달을 해주면 코드의 재사용이 되기 때문이죠.
또, 이런 종류의 UI는 어떨까요
문의하기 — 모바일, pc로 문의하는 route
이용권 업그레이드 — 프리미엄 티켓의 스펙
디바이스 정보 — 현재 유저의 기기 및 앱 정보
아주 소소하게 코드의 재활용을 요구하는 UI입니다.
각각 RecyclerView와 Adapter와 ViewHolder , item.xml을 만들어야할까요? 또는 item.xml을 <include> 태그를 이용하거나 CustomView에서 데이터를 결합 시켜줘야 할까요? 그것도 아니라면 내가 잘 관리한다는 마음을 먹고 통째로 하나의 layout.xml파일에 담는게 좋을까요?
Compose에서는 아주 간단한 구조로 코드 재사용이 가능했습니다.
https://medium.com/media/2a24d1c973305d6a483a140dbaa53dc7/href
이렇게 모두 Compose로 구현한다면 각각의 화면에 해당하는 @Composable 함수를 만들어주고 호출하는 방식으로 UI 로직을 구성함으로써, 간단한 구조와 코드의 재활용이라는 두 마리의 토끼를 모두 잡을 수 있습니다.
@Preview는 Free덤
마지막으로 Compose를 사용하면서 소소하게 좋았던 기능은 @Preview입니다. @Preview를 사용하면 앱을 실행하지 않고 Android Studio 내부에서 빌드를 해 여러 상태에 대해 UI를 확인할 수 있어 기존 xml에서 UI를 확인하는 것보다 좀 더 쉽게 디버깅을 할 수 있었습니다.
@Repeatable
annotation class Preview(
    val name: String = "",
    val group: String = "",
    @IntRange(from = 1) val apiLevel: Int = -1,
    // TODO(mount): Make this Dp when they are inline classes
    val widthDp: Int = -1,
    // TODO(mount): Make this Dp when they are inline classes
    val heightDp: Int = -1,
    val locale: String = "",
    @FloatRange(from = 0.01) val fontScale: Float = 1f,
    val showSystemUi: Boolean = false,
    val showBackground: Boolean = false,
    val backgroundColor: Long = 0,
    @UiMode val uiMode: Int = 0,
    @Device val device: String = Devices.DEFAULT
)
Preview는 width, height부터 locale, UiMode, Device등 다양한 조건을 주입받아 미리보기를 생성할 수 있게 해줍니다. 왓챠같은 다국어 언어를 지원하는 서비스의 경우에도 정말 유용하게 사용할 수 있었죠.
이런식으로 @Preview 어노테이션을 적극적으로 이용한다면 프로덕트 코드의 변화에 따라서 미리 정의해둔 @Preview Composable 함수들이 변화하는 것을 IDE에서 확인할 수 있습니다.
자신이 원하는 기기, 기기의 상태 등 다양한 환경에서의 결과물을 바로 IDE에서 확인할 수 있어서 , 여러 가지 테스트 케이스를 먼저 정의해놓는 TDD형식의 개발방식도 충분히 도입할 수 있겠다는 생각이 들었습니다.
마치며
Compose를 도입하면서 코드를 깔끔하게 줄일 수 있었고, UI로직과 비즈니스 로직의 관심사 분리를 자연스럽게 할 수 있어 너무 좋았습니다. 또한 UI 디자인도 더욱 디테일하게 관리할 수 있게 되어서, 앞으로도 왓챠의 많은 UI를 Compose로 작성할 예정입니다.
왓챠에서는 언제나 더 효율적인 방법과 개선 방향을 찾고 있습니다. 더 좋은 서비스 경험을 함께 고민하고 싶다면, 아래 공고를 확인해주세요.
멋진 동료를 구하고 있어요
코드 다이어트, Android Compose! was originally published in WATCHA on Medium, where people are continuing the conversation by highlighting and responding to this story.

코드 다이어트, Android Compose!

댓글