디자인 패턴을 공부하면서 안드로이드 코드 내에 다양한 디자인 패턴들이 사용되고 있다는 것을 알게 되었습니다. 특히 이전에 안드로이드 코드 중에서 재밌다고 생각했던 부분들이 디자인 패턴을 활용한 코드들이 많았습니다. 제가 발견했던 안드로이드 코드 내 재밌는 디자인 패턴들을 정리해보았습니다.

생성 패턴

1. 팩토리 메서드 패턴

팩토리 메서드는 객체 생성에 대한 책임을 인터페이스로 추상화하고, 이 인터페이스를 구체화하여 객체 생성을 다양화 시킬 수 있는 패턴입니다.

안드로이드에서는 ViewModel 생성시 ViewModelProvider.Factory interface를 통해 팩토리 메서드 패턴을 사용하고 있습니다.

팩토리 메서드를 통해 해결하는 문제

개발자는 AAC ViewModel을 직접 생성하기보단 ViewModelProvider.Factory를 통해 생성합니다. 이는 ViewModelStoreOwner의 생명주기에 맞춰 ViewModel의 생명주기를 안드로이드에서 관리해줄 수 있게 하기 위함입니다.

ViewModel의 생성을 안드로이드에서 책임지기 때문에 개발자는 ViewModel 생성에 필요한 의존성을 모두 안드로이드에 알려주어야 합니다. 즉, 개발자는 팩토리 메서드 패턴을 통해 안드로이드 내에서 ViewModel을 생성할 수 있도록 돕습니다.

2. 빌더 패턴

빌더 패턴은 복잡한 객체를 단계별로 생성해줄 수 있도록 도와주는 디자인 패턴입니다.

안드로이드 뷰 시스템의 AlertDialog는 빌더 패턴을 통해 생성할 수 있도록 되어 있습니다.

val builder = AlertDialog.Builder(this)
val dialog = builder
  .setTitle("Alert")
  .setMessage("This is an alert dialog")
  .setPositiveButton("OK") { dialog, which -> dialog.dismiss() }
  .setNegativeButton("Cancel") { dialog, which -> dialog.dismiss() }
  .create()

dialog.show()

빌더 패턴을 통해 해결하는 문제

개발자는 빌더 패턴을 통해 AlertDialog 내 UI 요소들을 다양하게 추가할 수 있습니다. Positive, Negative, Neutral 버튼 등 원하는 액션 버튼 만을 추가할 수 있으며, 타이틀, 아이콘 등 다양한 UI들을 추가할 수 있습니다. 이 UI들에 대한 존재 유무, 각각의 속성들을 빌더 패턴을 사용하지 않고 AlertDialog 생성자로만 설정할 수 있었다면, 생성자의 매개변수 값이 적어도 10개는 필요했을 것입니다. AlertDialog는 빌더 패턴을 통해 길고 복잡한 생성자를 통하지 않고도 UI를 조합해낼 수 있습니다.

구조 패턴

3. 어댑터 패턴

어댑터 패턴은 호환되지 않는 인터페이스를 가진 객체들이 협업할 수 있도록 하는 디자인 패턴입니다.

안드로이드에서 RecyclerView에 데이터를 연결하기 위해 RecyclerView.Adapter 또는 이를 확장한 클래스들(ex> ListAdapter)을 사용해야 합니다.

class MyListAdapter : ListAdapter<String, MyViewHolder>(MyDiffUtil) {
    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): MyViewHolder {
        val view = LayoutInflater.from(parent.context)
            .inflate(R.layout.item_layout, parent, false)
        return MyViewHolder(view)
    }

    override fun onBindViewHolder(holder: MyViewHolder, position: Int) {
        holder.bind(getItem(position))
    }
}

어댑터 패턴을 통해 해결하는 문제

RecyclerView는 ViewHolder 단위로 UI를 그리므로, 개발자는 코드 내 데이터를 ViewHolder 형태로 변환해야 합니다. 따라서 이 과정에서 위RecyclerView.Adapter 즉 어댑터 패턴을 사용하게 됩니다.

추가로 RecyclerView.Adapter가 ViewHolder 패턴을 사용하는 이유는, 비용이 많이 드는 View의 inflation(레이아웃 인플레이션) 작업을 최소화하기 위해서 입니다. Adapter는 ViewHolder를 생성해둔 뒤, 리스트가 스크롤 될 때마다 보이지 않게 된 ViewHolder를 재활용하여 새로운 리스트 아이템을 보여줍니다. 이를 통해 성능을 최적화하고, 불필요한 View 생성 비용을 줄일 수 있습니다.

4. 복합체(Composite) 패턴

복합체 패턴 은 데이터를 트리 형태로 구성한 뒤, 데이터를 트리 탐색 과정에 따라 처리하는 패턴입니다.

Jetpack Compose는 3가지 단계를 통해 데이터에서 UI로 그려집니다. 아래 3단계 중 Composition단계에서 composable들은 각각 노드로서 트리 구조로 구성되어, 이 트리 구조 순회를 통해 Layout, Drawing 단계가 진행됩니다.

복합체 패턴을 통해 해결하는 문제

UI 요소는 다른 UI 요소를 포함할 수 있기 때문에 이를 부모-자식 관계, 즉 트리 형태로 표현할 수 있습니다. 이를 통해 Compose의 Layout 단계에서 트리 구조를 잘 활용하게 됩니다. 구체적으로 부모 노드는 모든 자식 노드의 UI 너비, 높이를 측정하여 자신의 UI 너비, 높이를 계산하게 되며 자식을 부모의 상대 위치에 위치시키게 됩니다.

행동 패턴

5. 책임 연쇄 패턴

책임 연쇄 패턴은 작업을 체인처럼 연결시켜 작업을 다음 체인에 전달하는 패턴입니다. 이 과정에서 다음 작업이 필요없는 경우 작업을 다음 체인에 전달하지 않는 등 작업 연결을 유동적으로 관리할 수 있습니다.

안드로이드 뷰 시스템에서 아래와 같이 여러 ViewGroup과 View가 중첩되어있다면 유저가 화면을 터치했을 때 어떤 ViewGroup 혹은 View에게 터치가 전달되어야 할까요? 만약 ViewGroupB, View 두 UI 모두 터치 이벤트가 정의되어 있으며, 상황에 따라 번갈아 가며 ViewGroupB, View에 이벤트를 전달해야한다면 어떻게 개발할 수 있을까요?

안드로이드 뷰 시스템에서는 dispatchTouchEvent, onInterceptTouchEvent, onTouchEvent를 통해 터치 이벤트 흐름을 제어할 수 있습니다. 아래 도표에서 onInterceptTouchEvent 함수의 결과값 Boolean에 따라 이벤트 흐름이 달라지는 것을 볼 수 있습니다. 책임 연계 패턴을 활용하여 필요한 뷰에만 터치 이벤트를 전달하고 있습니다. 이 외에도 GestureDetector 함수의 결과값 Boolean에 따라 이벤트 흐름이 달라지는 등 터치 이벤트 관련 코드에서 책임 연쇄 패턴을 자주 볼 수 있습니다.

책임 연쇄 패턴을 통해 해결하는 문제

위 도표에서 onInterceptTouchEvent를 통해 터치 흐름을 제어할 수 없다면 터치 이벤트 처리가 매우 복잡해질 것입니다. 개발자는 기기 스크린의 어떤 지점에 터치 이벤트가 발생했을 때, 해당 지점에 존재하는 모든 View들에 터치 이벤트를 동시에 처리해야할 수도 있습니다. 안드로이드는 책임 연쇄 패턴을 통해 터치 데이터가 처리되는 단계를 줄여 복잡함을 줄이고, 성능상의 이득도 취하고 있습니다.

결론

이외에도 안드로이드에서 유행하는 코드들에는 상태 패턴, 커맨드 패턴등 다양한 디자인 패턴들이 보이곤 합니다. 반복자, 옵저버, 싱글턴 패턴은 어떤 진영에서든, 개발 언어 차원에서도 관찰되기도 하구요.

디자인 패턴을 공부하고 보니 꼭 모든 디자인 패턴을 알아야 한다고 생각이 들지는 않습니다. 개발을 하면서 자연스럽게 알게 되는 패턴도 있고, 잘 안쓰게 되는 패턴도 있는 것 같기 때문입니다. 복합체 패턴은 패턴이라기 보다는 그저 자료 구조중 하나인 트리 사용법이라고 생각되기도 하구요.

그럼에도 한 번 공부해보는 것을 추천하는 이유는 개발하는 동안 어떤 문제가 발생했을 때, 여러 개발자가 이해하고 있는 패턴으로 문제를 해결함으로서 동료간에 코드에 대한 이해도가 높아지는 장점이 있기 때문입니다. 또 문제를 해결할 수 있는 선택지, 도구가 다양해지는 장점이 있어 재미있구요.

또 다른 패턴을 찾으셨다면 같이 공유해주세요!

최근 회사에서도 사이드 프로젝트에서도 대부분의 UI를 Jetpack Compose 로 작성하고 있습니다. UI에 동작을 추가하기 위해 [SideEffect] 들을 자주 사용하게 되는데, 공식 문서만 읽었을 때 확실치 않은 부분들이 있어 LaunchedEffect, DisposableEffect 에서 궁금한 것들을 실험해보았습니다. 그 과정에서 Side Effect들에 대하여 잘 못 이해하고 있던 것들이 있어 이를 공유해보려합니다.

🤔 LaunchedEffect, DisposableEffect 는 언제 실행될까?

저는 LaunchedEffect(Unit) 를 딱 한 번 기록되어야 할 로깅 등 Composable 첫 시작시 1회 수행되어야 할 동작을 담곤 했습니다. 이 첫 1회 라는 개념이 애매하게 느껴져 여러 경우를 테스트 해보았습니다. 첫 1회라는 것이 Composable 이 로직 흐름상 처음 호출되는 순간일 수도, Compose UI 트리에 추가되는 순간일수도, 혹은 리컴포지션이 일어나는 순간 일수도 있다고 생각했기 때문입니다.

그래서 Greeting 이라는 Composable 함수에 아래 같이 LaunchedEffect, DisposableEffect를 추가했습니다.

그리고 show 버튼으로 Greeting Composable의 visibility를, change버튼으로 Greeting 에 전달할 파라미터의 값을 변경할 수 있습니다. 화면으로는 아래 그림처럼 생겼습니다.

@Composable
fun Greeting(name: String) {
  Text(text = "Hello $name!")
  LaunchedEffect(Unit) {
    Log.d("SideEffectTest", "LaunchedEffect")
  }
  DisposableEffect(name) {
    Log.d("SideEffectTest", "DisposableEffect")

    onDispose {
      Log.d("SideEffectTest", "DisposableEffect - OnDispose")
    }
  }
}

Greeting 외부는 이렇습니다.

var showGreeting by remember { mutableStateOf(true) }
var name by remember { mutableStateOf(Math.random().toString()) }
Column {
  if (showGreeting) {
    Greeting(name)
  }
  Button(onClick = {
    showGreeting = !showGreeting
    Log.d("SideEffectTest", "Show Clicked!")
  }) {
    Text("show")
  }
  Button(onClick = {
    name = Math.random().toString()
    Log.d("SideEffectTest", "Change Clicked!")
  }) {
    Text("change")
  }
}

예상했듯이 앱 실행 시에 Greeting 컴포넌트가 그려지면서 LaunchedEffect가 실행됩니다. 이 후 show 버튼이 클릭되어 dispose가 실행되고 다시 show 버튼이 클릭된 후 LaunchedEffect가 시작됩니다.

여기서 눈여겨 볼 것 들은,

1. if 조건에 의해 Composable이 컴포즈 UI Tree에서 삭제되었다가 다시 추가될 경우 LaunchedEffect 가 기록된다.

이 부분이 제가 가장 잘 못 이해하고 있던 부분이라고 생각합니다. LaunchedEffect 기록 시점을 Composable 함수의 로직상 첫 호출이라고 생각해 if 조건에 의해서 LaunchedEffect는 찍히지 않을 것이라 생각했습니다. 하지만 show 버튼에 의해 화면에 보이지 않게 되면 onDispose 이벤트도 찍히고 다시 화면에 보이게 되면 LaunchedEffect가 찍히는 것을 볼 수 있습니다.

2. DisposableEffect의 onDispose 콜백 외부 로그(테스트 결과의 1, 6 라인)는 LaunchedEffect가 시작되는 시점에 같이 로깅되고 있습니다.

이는 DisposableEffect 내부 코드를 살펴보면 DisposableEffectImpl이 RememberObserver의 onForgotten 뿐만 아니라 onRemembered API를 활용하고 있는 것을 통해 코드로도 확인할 수 있습니다.

3. (그 외) 전체 스크린 사이즈 리사이징에 의한 화면 변화에는 configChanges 설정에 따라 LaunchedEffect가 실행될수도 안될 수도 있다.

처음 테스트에서는 앱을 분할화면으로 열어 앱 스크린 사이즈를 조절할 때 마다 onDispose와 LaunchedEffect가 찍혔습니다. 하지만 이는 스크린 크기 조정에 따른 configurationChange 로 Composable을 담은 Activity가 재시작되기 때문이었습니다. AndroidManifest 에서 configChanges 수정을 통해 스크린 사이즈에 의해 Activity가 재시작되지 않게 설정하면 LaunchedEffect는 실행되지 않습니다.

🤔 LaunchedEffect(Unit) 을 여러번 선언하면 같은 코루틴 스콥일까?

LaunchedEffect와 DisposableEffect의 차이점을 꼽자면 두 콜백의 실행시점도 있겠지만, coroutineScope이냐 아니냐도 있습니다. 아래 각 함수의 선언부에서 이 차이를 바로 볼 수 있습니다.

여기에서 LaunchedEffect를 한 Composable 내에서 여러 번 선언할 경우 같은 코루틴 스콥을 공유하는지 궁금했습니다. 사실 이 부분은 LaunchedEffect 내부 코드를 보면 아니라는 것을 쉽게 알 수 있습니다.

아래와 같이 부모의 CoroutineContext를 사용하지만 LaunchedEffectImpl 클래스 생성 시마다 새 CoroutineScope을 생성하고 있습니다.

위에 사용하였던 Greeting Composable을 아래처럼 변형하여 Scope을 한 번더 로깅해보았습니다.

@Composable
fun Greeting(name: String) {
  Text(text = "Hello $name!")

  LaunchedEffect(Unit) {
    Log.d("SideEffectTest", "LaunchedEffect 1")
    Log.d("SideEffectTest", this.coroutineContext.toString())
  }
  LaunchedEffect(Unit) {
    Log.d("SideEffectTest", "LaunchedEffect 2")
    Log.d("SideEffectTest", this.coroutineContext.toString())
  }
}

CoroutineContext에서 StandaloneCoroutine 객체만이 다른 것을 볼 수 있습니다.

테스트가 끝나고 보니 LaunchedEffect에 전달한 key값이 변할 때마다 해당 코루틴을 cancel하고 재실행해야 하는 LaunchedEffect의 기본 동작을 생각하면 코루틴 스콥을 공유하지 않아야 한다는 것을 쉽게 생각할 수 있었습니다.

✍️ 결론

궁금한 것들을 떠오르는 대로 살펴보다 보니 흐름이 자연스럽게 진행된 글은 아닌 것 같습니다. 그래도 여러 애매한 것들을 테스트하고 코드를 쫓아가다 보니 각 기능이 정확히 어떤 기능인지 더 이해하게 된 것 같습니다. 테스트해 본 SideEffect 들 외에도 derivedStateOf 등 도 파봐야겠습니다.