들어가며

뷰모델은 안드로이드 AAC(Android Architecture Components)중 하나로 라이브 모델과 함께 굉장히 중요한 역할을 차지합니다. AAC는 구글에서 안드로이드 앱을 좀 더 쉽고 견고하게 개발할 수 있도록 개발자 커뮤니티의 피드백을 받아 만들어지고 있는 라이브러리입니다.

소프트웨어는 마치 사람처럼 성장합니다. 안드로이드가 1.0이 2008년에 발표되었으니 벌써 12년이 되었습니다. 당연히 안드로이드 API도 초기 설계는 부족한 부분이 많이 있었습니다. 이에 따라 어떤 부분은 개발하기도 어렵고 버그가 발생하기 쉬운 구조적인 문제도 아주 많았죠.

하지만 구글이 대단하고 잘하고 있는건 이런 부족한 부분을 끊임없이 발견하고 피드백을 받아 개선시켜주고 있다는 점입니다. AAC가 등장한 배경도, 그 AAC의 하나인 뷰모델이 등장하게 된 배경도 결국은 이런 맥락입니다.

자, 그럼 뷰모델이 해결하고자 하는 문제는 무엇이고, 뷰모델은 이 문제를 어떻게 해결해주고 있을까요? 이번 글에서는 이 두 가지 질문에 대해 알아보도록 하겠습니다.
(결론을 먼저 말하자면 뷰모델은 액티비티의 재생성 시 UI와 관련된 데이터를 유지하기 위해 사용합니다.)

뷰모델이 해결하고 싶은 문제

안드로이드 앱 개발을 한다고 하면, 가장 많이 부딪히는 개념중에 하나가 액티비티의 생명주기입니다. 안드로이드 앱의 거의 모든 UI 요소들은 액티비티에 속하게됩니다. 그리고 이 액티비티는 생명주기를 가집니다.

여기서 생명주기라 함은 크게 액티비티의 생성(onCreate)부터 소멸(onDestroy)까지를 말하고 좀 더 디테일하게 보면 유저에게 최초로 보여지는 시점(onStart - onStop), 포커스를 갖게되는 시점(onResume - onPause) 등을 포함합니다.

문제. 액티비티는 시스템에 의해 재생성(re-created)될 수 있습니다.

이런 상황은 단말의 몇몇 설정 변경 시 발생합니다. 가장 흔한 예는 단말의 방향 전환(가로모드, 세로모드), 언어 설정 변경을 생각해 볼 수 있습니다. 이런 시스템 설정 변경은 앱 밖에서 발생하기 때문에 이로 인한 발생되는 액티비티의 재생성은 우리가 제어할 수 없습니다.

그리고 이렇게 액티비티가 재생성이 되면 액티비티가 가지고 있던 데이터는 사라집니다.

위와 같은 이유로 액티비티가 재생성 되었을 때, 좋은 유저 경험을 주기 위해서는 마치 아무일도 없었던 것 처럼 UI와 관련된 데이터를 어딘가에 저장해 두었다가 이를 이용해서 다시 화면을 그려줘야합니다.

기존의 해결책. onSaveInstanceState()와 onRestoreInstanceState()

액티비티의 onSaveInstanceState() 콜백을 이용하면 이런 예외적인 상황에서 저장해두고 싶은 데이터를 번들(Bundle)에 저장할 수 있습니다. 그리고 이렇게 저장해둔 데이터는 액티비티가 재생성될 때 onCreate(savedInstanceState: Bundle?)나 onRestoreInstanceState() 콜백을 통해 다시 전달받을 수 있습니다.

하지만 이 방법은 번들을 사용하기 때문에 저장하고자 하는 데이터의 형태도 제한이 되고, 많은 양의 데이터를 저장하기에는 제한이 있습니다. 번들의 사용에 대해 가이드 하고 있는 공식 문서에서는 50Kb 미만으로 유지하기를 가이드 하고 있습니다.

또한 이 방법에서 onSaveInstanceState()는 메인 쓰레드에서 동작해야하기 때문에 여기서 데이터를 저장하는데 시간을 많이 사용하게 되면 그만큼 UI에 버벅거림이 생기게 됩니다.

뷰모델은 이 문제를 어떻게 해결 할 수 있을까?

뷰모델은 아래와 같이 액티비티가 재생성이 되는 시나리오에서는 액티비티의 onDestroy가 호출되더라도 소멸되지 않습니다. 뷰모델은 액티비티내에서 finish()를 직접 호출하거나 사용자가 액티비티를 닫을 때(백키를 누르거나 히스토리에서 제거해서) 소멸됩니다.

뷰모델이 액티비티의 재생성시에도 살아 남으니 해결책은 아주 간단합니다. 액티비티가 재생성 되었을 때에도 유지하고 싶은 데이터는 뷰모델에 저장하면 됩니다.

뷰모델 사용 방법

간단히 화면에 게임의 점수를 표시해 준다고 생각해봅시다. 이 점수는 유저에 의해 업데이트가 되고, 가로모드를 지원하기 때문에 화면 방향이 전환되어도 유저에 의해 업데이트된 점수는 유지되어야 합니다.

이런 요구사항이 있을 때 뷰모델에 저장해야하는 값은 점수가 되어야 합니다. 아래와 같이 score를 저장하는 변수를 뷰모델에 선언해줍니다.

1
2
3

class MyViewModel : ViewModel() {
    var scroe: Int = 0
}

이렇게 만든 뷰모델은 생성자를 통해 만들지 않고 ViewModelProvider라는 팩토리 객체를 이용해서 만들어줘야합니다. 일단 뷰모델의 인스턴스를 얻었다면 그 이후 사용법은 간단합니다. 일반적인 클래스 객체를 사용하듯이 데이터를 읽고 쓰면 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@Override fun onCreate(savedInstanceState: Bundle?) {
   super.onCreate(savedInstanceState)
   setContentView(R.layout.activity_main)

   // Get ViewModel instance
   mViewModel = ViewModelProviders.of(this).get(MyViewModel.class);
   
   // Update ui
   updateUi(mViewModel.scoreTeamA);
}

fun updateScore(score: Int) {
    // Read and write data from the ViewModel
   mViewModel.score = mViewModel.score + 1

   // Update UI
   textViewScore.text = mViewModel.score.toString()
}

참고로 안드로이드 개발자 페이지에서는 뷰모델과 라이브데이터(LiveData)를 함께 사용하는 예제를 보여주고 있습니다. 그 이유는 뷰모델과 라이브데이터를 함께 사용할 때 그 효용성이 극대화 되기 때문입니다.

지금은 이해를 돕기위해 라이브데이터에 대한 이야기는 하지 않겠습니다. 하지만 나중에 반드시 라이브데이터에 대해서도 공부해 보기를 권해드립니다.

뷰모델에 대해 조금 더 알아보자

앞에서 뷰모델이 어떤 문제를, 어떻게 해결 할 수 있는지 알아보았습니다. 이를 바탕으로 뷰모델을 언제, 어떻게 써야할지 조금 더 구체적으로 알아보도록 하겠습니다.

뷰모델에는 어떤 데이터를 저장해야 할까?

액티비티는 굉장히 다양한 데이터를 가지고 있을 수 있습니다. 그중에 뷰모델에 저장해야할 데이터는 어떤 데이터일까요? 정답은 UI와 연관된 데이터입니다. 앞서 뷰모델이 어떤 문제를 해결하고자 하는지를 이해했다면 당연한 이야기겠죠?

뷰모델을 사용할 때 주의점

뷰모델에는 반드시 액티비티나 프래그먼트(Fragment), 컨텍스트(Context)에 대한 참조를 저장하면 안됩니다. 뷰(Views)도 컨텍스트를 가지기 때문에 뷰에 대한 참조 역시 저장하면 안됩니다.

이에 대한 이유는 뷰모델의 생명주기를 생각해보면 알 수 있습니다. 뷰모델이 액티비티에 대한 참조를 갖고 있다고 생각해봅시다. 이 때 단말의 방향이 변경되어 액티비티가 재생성이 되면 어떻게 될까요?

현재 액티비티는 종료되고 새로운 액티비티가 생성되지만 뷰모델은 액티비티가 재생성 되어도 살아있기 때문에 종료된 액티비티의 참조를 갖고 있게됩니다. 결국 해당 액티비티는 뷰모델이 종료될 때까지 계속 메모리에 남게 됩니다. 즉 메모리 릭(Memory leak)이 발생합니다.

다만 여기에 한 가지 예외가 있는데, 어플리케이션의 컨텍스트는 뷰모델에서 가져도 됩니다. 어플리케이션은 액티비티가 아닌 어플리케이션의 생명주기를 따르기 때문입니다. 더해서, 뷰모델에서 시스템 서비스를 사용하기 위해 어플리케이션 컨텍스트가 필요한 경우 AndroidViewModel을 이용하면 됩니다. AndroidViewModel은 이런 경우를 위해 제공되는 뷰모델로 Application에 대한 참조를 가집니다.

뷰모델은 액티비티가 재생성될 때 UI와 관련된 데이터를 저장하기 위해 사용합니다.

또한 뷰모델은 액티비티의 재생성 시 UI 데이터를 저장하는 데 사용합니다. 데이터가 영구히 저장되어야 한다면 프리퍼런스(Preference)나 데이터베이스에 저장해야합니다.

뷰모델을 사용할 때 얻을 수 있는 추가적인 장점

뷰모델을 사용하면 UI와 관련된 데이터를 액티비티나 프래그먼트로부터 분리할 수 있습니다. 일반적으로 UI 개발 시 데이터와, 뷰, 로직을 분리하는 것이 코드의 복잡도를 줄이고 개발을 편하게 해준다는 것은 UI 개발에서 MVC, MVP, MVVM과 같이 다양한 패턴이 존재하는 것을 보아도 알 수 있습니다. 또한 이렇게 데이터와 UI를 분리하면 코드를 테스트 하기도 좋아집니다.

그리고 뷰모델을 올바르게 사용한다면 코드에 대한 가독성도 높아 질 수 있습니다. 예를 들어 어떤 액티비티의 코드를 분석하는데 여기서 뷰모델을 쓰고 있다면 바로 이 액티비티의 UI 관련 데이터는 이 뷰모델 코드를 보면 되겠구나하고 알 수 있습니다.

마무리

이번 글에서는 뷰모델의 개념에 대해 알아보았습니다. 뷰모델이 왜 만들어졌고 어떻게 사용하면 되는지만 알고 바로 뷰모델을 사용해도 되지만 뷰모델과 관련된 개념들은 재밌는 부분이 많습니다.

액티비티의 생명주기, 데이터를 저장하는 다양한 방법들, 라이브데이터, 프래그먼트, 디자인 패턴에서의 뷰모델과, 안드로이드 AAC 뷰모델과의 차이 등이 있는데 이런 개념들을 시간을 두고 하나씩 완전히 익혀두면 굉장히 큰 도움이 될 수 있습니다.

참고로 뷰모델에서 데이터를 저장하는 것은 내부적으로 프래그먼트의 setRetainInstance라는 메커니즘을 사용합니다.

마지막으로 어떤 도구도 상황에 맞게 사용하는 것이 중요합니다. 뷰모델에는 다양한 장점이 있지만 사용해야하는 곳과 주의할 점이 분명합니다. 이런 점들을 잘 알고 필요할 때 사용하는 것이 중요합니다. 이 글이 뷰모델을 사용하는데 조금이라도 도움이 되면 좋겠습니다.

참고자료

• ViewModel Overview
  • 안드로이드 공식 페이지의 뷰모델 사용 가이드
• Understand the Activity Lifecycle
  • 안드로이드 공식 페이지의 액티비티 생명주기 가이드
• Parcelables and Bundles
  • 안드로이드 공식 페이지의 Parcelables과 번들에 대한 설명
• ViewModels : A Simple Example
  • 구글 Advocator인 Lyla가 쓴 뷰모델의 사용 시 주의할 점과 다른 방식들과의 비교
• ViewModels: Persistence, onSaveInstanceState(), Restoring UI State and Loaders
  • 구글 Advocator인 Lyla가 쓴 뷰모델에 대한 전반적인 설명

멋쟁이들은 계절이나 분위기에 따라 다양한 색의 옷으로 스스로를 표현합니다. 아름다운 자연도 계절에 따라 완전 다른 모습으로 우리의 눈을 사로잡습니다.

최근 Android, iOS에 많은 화제가 되고 있는 다크 모드(Dark Mode)도 비슷합니다. 모드에 따라 하나의 앱이 밝고, 어두운 두 가지 모습을 자유자재로 오갑니다.

안드로이드에서는 테마(Theme)를 이용해서 이를 구현할 수 있습니다. 계절에 따라 모습이 바뀌는 자연을 생각하면 테마는 계절이라고 생각할 수도 있고, 기분에 따라 옷의 컬러를 선택하는 사람에겐 기분이 테마가 될 수 있습니다.

안드로이드의 다크 모드라는 것도 결국은 시스템이 ‘다크 모드(Dark mode)’일 때 이에 맞는 미리 만들어둔 테마를 적용시켜주는 것에 불과합니다.

아래 이미지는 안드로이드 공식 페이지에서 테마에 대해 설명하는 이미지입니다. 동일한 액티비티에 서로 다른 테마를 적용한 모습으로, 테마에 따라 액티비티가 완전히 다른 느낌으로 변하는 모습을 볼 수 있죠.

그럼 이번 포스팅에서는 테마에 따라 다양한 모습으로 변신하는 앱을 어떻게 만들 수 있는지에 대해 이야기하도록 하겠습니다.

테마의 선언과 구성

앞에서 테마에 대해 개념적으로 설명을 드렸지만 우리는 개발자이니 좀 개발자의 관점에서 테마를 살펴보도록 하겠습니다. 테마는 아래와 같이 res/values/style.xml에 선언합니다. 여기서 파일 명은 원하는 대로 작성하셔도 됩니다.

1
2
3
4
5
6
7
8

<resources>
    <style name="AppTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>
        <item name="colorImagePlaceHolder">@color/GR80</item>
    </style>
</resources>

일단 기본적으로 테마는 키, 값의 쌍으로 이루어진 맵과 같이 생각할 수 있습니다.

더 위에 style 태그를 보면 마치 클래스 처럼 parent를 통해 다른 테마를 상속 받을 수도 있습니다. 위의 예에서는 AppTheme이라는 테마가 Theme.MaterialComponents.DayNight.NoActionBar라는 테마를 상속받아 선언되고 있습니다. 다른 테마를 상속 받으면 새로 정의한 테마는 parent 테마의 모든 속성을 동일하게 갖게되고 기존의 속성을 오버라이드할 수 있습니다.

<style name="AppTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">

이제 가장 중요한 내용입니다.

테마에 있는 속성들은 컬러와 같은 디자인 리소스에 의미있는 이름을 붙인 것 입니다. 예를 들어 위에 colorAccent은 안드로이드의 뷰가 가진 속성이 아닙니다. 그리고 colorAccent는 이름에서 보이듯이 이름에서 어떤 특정 색을 표현하지 않고 ‘강조를 나타내는 색’이라는 의미를 더 강조하고 있습니다.

즉 테마에 따라 colorAccent를 다르게 적용할 수 있음을 표현하는 것입니다. 꼭 인터페이스와 구현체의 관계와 비슷합니다. colorAccent라는 속성(인터페이스)은 서로 다른 테마(구현체)에서 다른 컬러로 표현될 수 있는 것입니다.

머티리얼 디자인에 포함된 주요 테마 속성

테마는 내가 직접 정의해서 사용할 수도 있고 안드로이드 플랫폼에 정의되어 바로 사용할 수 있는 것들도 있습니다. 아래 이미지는 롤리팝과 함께 머티리얼 디자인이 소개되면서 많이 쓰인 이미지입니다.

위에 보이는 colorPrimary, textColorPrimary, colorPrimaryDark, windowBackground, navigationBarColor와 같은 속성들은 머티리얼 테마(Material Theme)에 미리 정의된 것으로 보시는 것처럼 시스템 UI에 미리 사용되고 있고 앱에서 얼마든지 이를 재정의(Override)해서 사용이 가능합니다. 즉 앱에서 사용하는 테마에서 colorPrimaryDark를 노란색으로 적용하면 위에 위에 그림에 있는 상태바(Status bar)의 색은 노란색으로 변경될 것입니다.

그렇다면 이게 어떻게 가능할까요? 바로 안드로이드도 플랫폼에서 상태바의 색상에 특정 컬러를 하드코딩 한게 아니라 colorPrimaryDark라는 테마의 속성을 참조하도록 해두었기 때문입니다.

아래는 머티리얼 테마를 상속받아서 앱에서 직접 사용할 테마를 AppTheme라는 이름으로 선언해서 사용하는 예입니다. 아래 예에서 android:windowBackground나 android:windowActivityTransitions와 같은 속성은 안드로이드 프레임워크에 있는 테마이고, colorPrimary, colorPrimaryDark, colorAccent는 머티리얼 테마에 선언된 속성입니다.

그리고 마지막에 있는 colorImagePlaceHolder는 제가 직접 만든 속성입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

<resources>
    <style name="AppTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        // Attributes from material theme
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>

        // Attributes from android framework
        <item name="android:windowBackground">#ffffff</item>
        <item name="android:windowActivityTransitions">true</item>

        // Attributes that I've defined
        <item name="colorImagePlaceHolder">@color/GR80</item>
    </style>
</resources>

colorImagePlaceHolder와 같이 기존에 없는 속성을 선언하고 싶으면 res/values/values.xml 파일에 아래와 같은 방식으로 선언하면됩니다. 보시면 좌측에 속성이 가질 리소스 포맷을 적고 name에 사용할 속성 명을 적어주면 됩니다.

1
2
3
4
5
6

<resources>
    <attr format="color" name="colorImagePlaceHolder"/>
    <attr format="color" name="colorDivider"/>
    <attr format="color" name="mildBackgroundColor"/>
    ...
</resources>

테마에 적용된 값을 사용하기

자 이제 테마의 개념부터, 종류, 선언하는 방법까지 알아봤으니 어떻게 사용하는지를 알아봅시다. 테마를 사용하는 가장 기본적인 방법은 ?attr/[attributeName] 을 사용하는겁니다. 구체적으로 아래와 같이 사용할 수 있습니다.

1
2
3
4
5
6

<androidx.appcompat.widget.Toolbar
        android:id="@+id/toolbar"
        style="@style/Toolbar"
        app:titleTextColor="?attr/titleTextColor"
        app:titleTextAppearance="@style/ToolbarTitle"
        tools:title="Toolbar" />

툴바의 텍스트 컬러를 지정하는 부분을 보시면 아래처럼 ?attr을 사용하고 있죠.

?attr/titleTextColor

?attr은 테마에서 attr 뒤에 있는 속성 이름으로 값을 찾아오라는 의미입니다. 예를 들어 위의 예에서는 현재 나에게 적용된 테마에서 titleTextColor라는 이름으로 정되된 컬러값을 가져오라는 뜻입니다.

앱에 현재 LightTheme과 DarkTheme가 있다고 합시다. 현재 이 툴바가 LightTheme를 적용받고 있고 LightTheme에 titleTextColor가 흰색이라면 툴바의 텍스트는 흰색이 될 것이고, DarkTheme를 적용받고 있고 여기에 titleTextColor가 검정이라면 툴바의 텍스트는 검정이 됩니다.

결국 테마를 통해 화면의 모습을 다이나믹하게 변경하는 것은 내가 변경하고자 하는 UI 요소의 컬러를 최대한 ?attr을 이용해서 테마의 속성을 간접 참조(indirect reference)로 설정하고, 사용자의 선택이나, 환경에 따라 테마를 변경하는 것입니다. (이 포스팅 전체에서 가장 중요한 내용인거 같네요.)

테마의 적용

그렇다면 위의 예에서 저 툴바에 적용되는 테마는 어떻게 결정 될까요? 테마는 컨텍스트에 적용이 됩니다. 자 그럼 안드로이드 플랫폼에서 컨텍스트를 갖는게 어떤게 있을까요? View, ViewGroup, Activity, Application 등이 있겠죠. 테마는 컨텍스트에 적용이 되기 때문에 여기에 모두 적용이 됩니다.

또한 테마는 범위를 갖는데 상위레벨에 적용한 테마는 하위 레벨까지 모두 적용이 되고 하위레벨에 적용된 테마가 상위레벨에 적용된 테마에 우선해서 적용됩니다.

1. 어플리케이션 레벨로 적용하기
   androidManifest.xml

   1 2 3 4 5 6 7 8

   <manifest ...> <application ... android:theme="@style/AppTheme"> ... </application> </manifest>

2. 액티비티에 적용하기
   androidManifest.xml

   1 2 3 4 5 6 7 8 9 10 11

   <manifest ...> <application ...> <activity ... android:theme="@style/SplashTheme"> </activity> ... </application> </manifest>

3. 뷰그룹 및 뷰에 적용하기

   1 2 3 4 5 6 7 8 9 10 11

   <LinearLayout ... android:theme="@style/Theme.MaterialComponents.Light"> <TextView ... /> <TextView ... android:theme="@style/ThemeOverlay.MaterialComponents.Dark" /> </LinearLayout>

xml에서 각 테마는 android:theme를 통해 적용이 가능하고 적용하고자 하는 범위에 따라 androidManifest.xml의 application 태그나, activity 태그 또는 레이아웃 파일에서 각 뷰그룹 또는 뷰에 적용이 가능합니다.

코드에서 테마에 정의된 속성 값 읽어오기

앞서 테마는 컨테스트에 적용이 된다고 이야기했습니다. 그럼 테마에 엮여있는 특정 속성의 값을 코드에서 가져오려면 어떻게 할까요?
(xml이였다면 ?attr/[attributeName]을 썼겠죠)

아래는 컨텍스트에 엮여있는 컬러값을 가져오는 예제입니다.

1
2
3
4
5
6
7
8

@ColorInt
fun Context.getThemeColor(@AttrRes themeAttrId: Int): Int {
    return obtainStyledAttributes(
            intArrayOf(themeAttrId)
    ).use {
        it.getColor(0, Color.TRANSPARENT)
    }
}

현재 액티비티의 테마에 있는 colorPrimary를 가져오려면 액티비티 내에서 getThemeColor(R.attr.colorPrimary)와 같이 할 수 있을 것이고 특정 뷰그룹에 적용된 테마에 대한 컬러를 가져오려면 targetViewGroup.getContext().getThemeColor(R.attr.colorPrimary)와 같이 사용할 수 있겠죠.

테마의 사용

자 그럼 위에서 알아본 테마의 개념이 어떤식으로 사용될 수 있을까요? 아래의 UI를 예로 들어 봅시다. 이 앱의 처음 디자인은 좌측의 밝은 색 위주의 디자인이였는데 어떤 과정을 거쳐서 우측과 같이 어두운 테마를 적용할 수 있었을까요?

이를 위해서는 아래와 같은 단계를 밟아가면 됩니다.

1. 테마에 따라 색상이 변하는 부분과 변치 않을 부분을 나눠봅니다.
2. UI에서 컬러가 하드코딩 되어있는 부분을 찾고 테마의 어떤 속성을 사용할지 결정합니다. 이때는 이미 시스템에 정의된 테마의 속성을 사용할지, 새로운 속성을 만들지 결정합니다.
3. 새로운 테마를 만들고 이 테마에서 변화를 줄 속성을 오버라이드합니다.
4. UI에서 변경이 필요한 부분의 컬러를 테마의 속성을 참조하도록 ?attr/을 이용하여 변경합니다.

테마에 따라 색상이 변하는 부분과 변치 않을 부분을 나눠보기

위의 예제에서 변하는 부분과 변치 않는 부분을 나눠봤습니다.

변하는 것

• 화면의 배경
• 툴바의 배경
• 쿨바의 텍스트
• 리스트 내의 카드 배경
• 리스트 내의 카드 텍스트
• 바텀네비게이션 배경
• 바컴네비게이션 아이콘
• 탭레이아웃 배경

변하지 않는 것

• 탭레이아웃 인디케이터 및 선택된 탭의 텍스트
• 리스트 내 카드의 재생시간 뱃지

변하는 부분과 변치 않는 부분을 나눴으면 각각에 어떤 테마의 속성을 사용할 수 있을까요? 모두 새로 선언해도 되지만 이미 선언돼있는 다양한 속성들이 있으니 이것들을 먼저 확인해봅니다.

아래 링크에는 머티리얼 디자인 시스템에 이미 선언돼있는 다양한 속성들에 대한 설명이 있습니다.

Android Styling: Common Theme Attributes

이 글에서는 컬러에 대한 내용을 주로 다루고 있으니 몇 가지 컬러 관련 속성을 보겠습니다.

• ?attr/colorPrimary : 앱의 메인 브랜딩 컬러
• ?attr/colorSecondary : 앱의 세컨 브랜딩 컬러로 주로 메인 브랜딩 컬러를 보완하는 좀 더 밝은 색상으로 사용
• ?attr/colorOn[Primary, Secondary, Surface etc] : 각 컬러에 대한 대비를 이루는 색입니다. 예를 들어 배경에 ?attr/colorPrimary를 쓰고, 여기위에 다른 UI 컴포넌트를 올릴 때 colorOnPrimary를 사용하면 이 컴포넌트를 좀 더 눈에 띄게 강조 할 수 있겠죠.
• ?attr/colorSurface : 카드(cards), 시트(sheets), 메뉴(menues)와 같은 컴포넌트의 표면 색을 나타냅니다.
• ?attr/colorBackground : 스크린의 백그라운드 색
• ?attr/colorError : 에러를 표시할 때 사용할 색

아래 이미지는 material.io 페이지에 있는 The baseline Material color theme로, 위의 컬러를 보통 어떤식으로 선택하는지에 대한 예시를 보여주고 있습니다. 참고로 material.io 페이지에 가면 대비가 되는 색을 선택하거나, 위에 있는 머티리얼 테마에 사용되는 속성값들을 어떤 식으로 결정하면 좋을지에 대한 가이드와 툴이 잘 나와있습니다.

다시 아래 목록으로 돌아와서 위에 있는 속성들을 참고하면 저는 아래와 같이 테마의 속성을 정의할 수 있을거 같습니다. 이걸 바탕으로 각 UI 컴포넌트에 하드코딩 되어있던 컬러를 ?attr를 이용해서 바꿔줍니다.

이제 위의 속성들을 각 테마에 따라 정의합니다.

밝은 테마

1
2
3
4
5
6
7

<style name="LightTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="colorSurface">@android:color/white</item>
        <item name="backgroundColor">@android:color/white</item>
        <item name="android:windowBackground">@color/gray_bg</item>
        <item name="titleTextColor">@android:color/black</item>
        ...
</style>    

어두운 테마

1
2
3
4
5
6
7

<style name="DarkTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        <item name="colorSurface">@color/gray_900</item>
        <item name="backgroundColor">@android:color/black</item>
        <item name="android:windowBackground">@android:color/black</item>
        <item name="titleTextColor">@android:color/white</item>
        ...
</style>

이제 감이 오시나요? 위의 속성들을 재정의 하는 테마를 추가하기만 하면 이제 얼마든지 분위기가 확 다른 앱을 만들 준비가 된 것이죠.

그럼 이제 이런 테마를 어떻게 적용하면 될까요? 아까 위에 기술 했던대로 activity 또는 application 단위로 androidManifest의 android:theme 태그를 이용해 정의하면 됩니다. 이걸 동적으로 하고 싶다구요? 그럼 간단히 테마를 선택할 수 있는 다이얼로그를 하나 만들고 테마를 선택하면 이걸 Preference 같은 곳에 저장하고, 액티비티가 시작 시 setContentView 이전에 테마를 설정해주면 됩니다.

1
2
3
4
5
6
7
8
9
10
11
12

override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val userSelectedPref = getThemeFromPref()
        when(userSelectedPref) {
            "light" -> setTheme(R.style.LightTheme)
            "pink" -> setTheme(R.style.PinkTheme)
            "dark" -> setTheme(R.style.DarkTheme)
            else -> setTheme(R.style.LightTheme)
        }
        setContentView(R.layout.activity_main)
        ...
}

테마는 뷰가 인플레이트 되기 전에 설정이 되고 인플레이트 후에는 변경해도 UI에 업데이트가 반영이 되지 않기때문에 setOntentView 이전에 해주어야합니다.

다크 모드

그럼 다크모드는 뭘까요? 다크모드는 안드로이드 9에서부터 지원되는 시스템 설정입니다. 즉 앱이 아니라 안드로이드 시스템에서 설정 가능한 모드입니다. 앱에서 다크모드를 지한한다는 것은, 사용자가 시스템의 다크모드를 적용하면 이에 따른 어두운 테마를 만들어 두었다가 이게 적용되도록 해주면 됩니다. 간단하죠?

이 부분은 이 글의 내용을 이해했다면 간단히 적용이 가능하지만 이 글에서 다루면 너무 길어질 것 같아서 다음 포스팅에서 따로 다루도록 하겠습니다.

마무리

저는 디자인과는 좀 거리가 있어보이는 개발자입니다. 노트북이 들어간 백팩과 체크무늬 셔츠가 가장 편안합니다. 하지만 그럼에도 제가 만든 앱은 어디서나 돋보였으면 좋겠고 보기에 좋았으면 좋겠습니다. 또한 저는 잘 다듬어진 디자인은 그 자체로 유저에게 큰 가치를 준다고 생각합니다. 이 글을 보신 분들도 테마를 이용해서 보다 다양한 느낌의 앱을 앱을 만드는데 도움이 되셨으면 합니다.

참고

테마에 관련된 글들은 주로 안드로이드 엔지니어인 Nick Butcher의 유튜브 영상과 미디엄 글을 많이 참고했습니다. 또한 material.io에 있는 페이지들도 개발자에게 디자인과 관련된 컴포넌트나 개념을 잡는데 도움이 많이 되었습니다.

마지막으로 안드로이드의 테마를 이야기하면 항상 스타일(Style)에 대한 이야기를 보통 함께 합니다. 이 둘은 상당히 비슷하면서 다른데 개인적으로는 두개를 같이 다루면 오히려 개념을 잡는데 헷갈리기 때문에 스타일에 대한 이야기는 최대한 배제하였습니다. 하지만 테마를 이해했다면 스타일에 대한 부분도 꼭 짚고 넘어가면 좋을 것 같습니다.

• Dark theme
• Styles and Themes
• Material io
• Android Styling: Themes vs Styles
• Android Styling: Common Theme Attributes
• Android Styling: Prefer Theme Attribute
• Android Styling: Themes Overlay