Swemo - Iteration 2: UI 디자인 방향 탐색(Exploration)

#1 개발 목표 (Iteration Goal)

#1-1 이상(Ideal)과 징검다리

이상(Ideal)

직전 Iteration에서 앱의 아주 기초적인 틀을 잡았다. 이제 남은 것은 여기에 여러 가지 구현을 쌓아 올리는 것이다. 먼저 든 생각은 "도메인 영역을 일단 구현하자"였다. 하지만, 도메인도 결국 내가 UI에서 어떻게 표현하느냐에 따라 좌지우지될 것이라는 생각이 들었다. 왜냐하면 Swemo는 UI로 '승부'를 볼 가능성이 높은 앱이기 때문이다. 만약 Swemo 사람들에게 '좋은 앱'으로 인식된다면, 그 이유는 (기존 메모 앱들에 비해) 좋은 UI일 것이다. 결론은, 무엇을 어떻게 보여주느냐가 가장 근본적인 설계의 핵심이다. Iteration 2에서 구체화한 UI를 통해 '이상(Ideal)'의 윤곽도 보이리라 믿는다.

 

Iteration 2: UI 디자인 방향 탐색(Exploration)

정말 UI만 개발할 것이다. 앱 컴파일도 안 하고 대부분 Compose Preview만으로 작업할 것이다. 물론 UI 확인을 위해서라도 기초적인 상호작용 정도는 있어야 하므로 테스트용 State는 몇 개 넣어줄 것이다.

 

'Bubble' 개념도 여기서부터 조금씩 도입해 나간다. 사실 이 개념은 말로 표현하기가 어렵다. 그래서 구구절절 읊기보다는, 코드 그리고 스크린샷으로 보여주려고 한다.

 

#1-2 개발 범위

이번 개발 범위 (In Scope)

1. 메모 리스트를 읽기 위한 화면 UI
2. 메모를 추가하기 위한 화면 UI
3. 카테고리를 선택하기 위한 화면 UI
4. 카테고리를 추가하기 위한 화면 UI
5. Compose Runtime만으로도 테스트할 수 있는 UI (Compose Preview만 보고 개발)
6. Compose State를 위한 도메인 모델 정립
7. 'Bubble' 개념이 UI에서 표출되는 방식

 

범위 외 (Out of Scope)

1. Compose Runtime만으로는 테스트할 수 없는 UI (Compose Preview만으로는 확인 불가능한 기능)
2. 시스템 컴포넌트(Navigation Bar, Status Bar 등)을 고려한 UI
3. UI 외적인 기능
4. 'Bubble' 개념이 실제로 (백엔드에서) 작동하도록 구현
5. 기본(built-in) 애니메이션을 제외한, 추가 애니메이션

 

#2 변경 내역 (커밋 목록)

#2-1 Iteration 2-1: UI Wireframing

Jetpack Compose로 직접 구현하기에 앞서 와이어프레이밍을 진행한다.

 

관련 개발 범위

• 메모 리스트를 읽기 위한 화면 UI
• 메모를 추가하기 위한 화면 UI
• 카테고리를 선택하기 위한 화면 UI
• 카테고리를 추가하기 위한 화면 UI
• 'Bubble' 개념이 UI에서 표출되는 방식

 

주요 변경점

순수 디자인이기 때문에 코드상으로는 변한 점이 없다. 하지만, 이 작업에 기반해서 Iteration 2-2가 진행될 것이므로, Iteration 2-2의 커밋 메시지에 Iteration 2-1의 작업 내용 및 스크린샷 링크를 첨부한다.

 

스크린샷 - 메모 리스트 읽기

Swemo의 메모 하나하나는 'key-value의 리스트'다. 따라서 왼쪽에 있는 엑셀 표와 같은 데이터를 Swemo로 표현할 수도 있다. 그래서 후에 언젠가는 엑셀 ↔ Swemo 양방향 내보내기 기능을 만들어보고 싶다. 하지만 기본부터 하고 바라야 할 것이다.

 

스크린샷 - 메모 추가

key-value 쌍을 단 하나만 쓴다면, 그건 일반적인 메모 앱과 다를 바 없다. 그래서 입력 시 key-value 쌍을 추가할 수 있는 추가 영역이 필요하다. 스크린샷에 있는 '나이', '종', '키', '분류' 등의 버튼을 나는 Bubble이라고 부른다. 비눗방울처럼 동글동글한 모양이고, 또 사용자가 한번 클릭하면 사라지기 때문이다. 위의 스크린샷에서 '종' Bubble을 클릭하면, ('종'을 key로 두는 EditText가 추가되며) '종' Bubble이 사라진다.

 

스크린샷 - 카테고리 선택 및 추가

Iteration 1-3에서 만들어둔 ModalNavigationDrawer 속에 카테고리를 구성한다.

 

참고

• [Tistory] Swemo - Iteration 1: 메모 앱의 청사진(기초)

 

#2-2 Iteration 2-2: Domain Modeling

#2-1의 디자인을 바로 만들려다가는 반드시 실패한다. 도메인 모델링(객체 간의 관계 코드화)을 작업해 주지 않았기 때문이다. ViewModel 및 UI는 도메인 모델링에 '끌려'다닌다. 따라서 지금 확실하게 정해두지 않는다면, 나중에 가서 모든 작업을 갈아엎고 다시 하게 될 수도 있다.

 

관련 개발 범위

• Compose State를 위한 도메인 모델 정립

 

주요 변경점

• 도메인 모델 추가
• 기존의 임시 도메인 모델은 제거
• 새로 추가한 도메인 모델이 TestScreen과 잘 호환되도록 업데이트

 

코드 스니펫

// in MemoContent.kt
data class MemoContent(val label: String, val text: String)

---

// in Memo.kt
data class Memo(val categoryId: String, val id: String, val contents: List<MemoContent> = emptyList())

---

// in Category.kt
data class Category(val id: String, val name: String)

Category가 Memo를 프로퍼티로 보유하게 두지 않는 이유가 있다. 카테고리는 '컨테이너'라기보다는 (SNS 게시글에 붙는) '태그'에 더 가까운 개념이다. 본 앱을 사용할 사용자의 행위를 상상해 보아도, "카테고리 수정(편집)"과 "메모 수정(편집)"을 완전히 다른 행위로 인식할 것이 그려진다.

반대로 Memo는 List<MemoContent>를 프로퍼티로 보유한다. MemoContent 는 반드시 특정 Memo에 귀속되며, 단독으로는 아무런 의미를 가지지 않는다. Memo에 귀속되어 있기 때문에 Memo가 삭제되면 같이 사라진다. 또 "Memo를 수정한다"라는 행위는 "MemoContent를 수정한다"는 행위와 사실상의 같은 행위다. 따라서 분리하지 않았다.

 

Excel의 도메인 모델과 Swemo의 도메인 모델 개념적으로 연결
추가로 (Microsoft) Excel의 도메인 모델하고도 개념적으로나마 연결 지어둘 필요가 있다. #2-1에서 말한 대로 (미래에) 엑셀과의 상호 호환을 위해서기도 하지만, 데이터베이스의 모양을 한 엑셀의 구조를 따라가서 나쁠 것도 없기 때문이다. 아래는 #2-1에 있던 엑셀 양식이다. 

 

이 엑셀 양식을 참조하면, 아래에 있는 Excel 도메인 모델 vs Swemo 도메인 모델 표를 읽기 편할 것이다.

 

여기서는 이렇게 연결점을 밝혀만 놓고, 앞으로 개발해 나갈 때 두고두고 참조하는 용도로 쓰겠다.

 

참고

• [GitHub] 이 작업의 Commit
• [Wikipedia] Domain model

 

#2-3 Iteration 2-3: TestScreen의 State 격리, @Preview 사용 준비

Android Studio의 Preview 기능을 통해 UI 개발을 하기로 했다. 그러려면 걸리적거리는 State를 분리할 필요가 있다. TestScreen()을 (메소드 오버로딩을 통해) 아래의 2개의 함수로 나눴다.

 

• TestScreen¹
  • TestScreen(viewModel: ViewModel) 
  • Stateful Screen: 화면이 사라져도 계속 유지해야 할 State들을 모아, 아래에 있는 함수에 보내줌
• TestScreen²
  • TestScreen(categories: List<Category>, memos: List<Memo>, ...)
  • Pure UI Screen: 모든 State를 매개변수로 주입받음. 단, 화면이 사라지면 아무런 의미가 없는 UI 전용 State(DrawerState 등)는 내부에서 보유

 

Preview 기능을 이용해 주로 개발할 함수는 TestScreen²다. 앞으로 @Preview 어노테이션을 사용할 것이므로 아주 간단한 Preview 하나도 만들어봤다.

 

관련 개발 범위

• Compose Runtime만으로도 테스트할 수 있는 UI (Compose Preview만 보고 개발)

 

주요 변경점

• TestScreen을 메소드 오버로딩으로 2분할. 하나는 State를 주입하는 역할, 하나는 순수하게 UI를 그리는 역할
• 간단한 @Preview 구현 (@PreviewParameter로 값 주입)

 

코드 스니펫 - TestScreen.kt

...

// state 주입용
@Composable
fun TestScreen(viewModel: ViewModel? = null) {
    ...

    // category
    ...
    val categories = listOf(allMemosCategory) + categoriesFromRepo
    var selectedCategory: Category by remember { mutableStateOf(allMemosCategory) }

    // memo
    ...
    val memos by memosFlow.collectAsState(initial = emptyList())

    TestScreen(
        categories = categories,
        selectedCategory = selectedCategory,
        memos = memos,
        // events
        onCategorySelected = { category: Category ->
            selectedCategory = category
        },
        ...
    )
}

// 순수 UI
@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun TestScreen(
    categories: List<Category>,
    selectedCategory: Category,
    memos: List<Memo>,
    // events
    onCategorySelected: (Category) -> Unit,
    onAddMemoClick: () -> Unit,
) {
    ...
}

@DevicePreviews
@Composable
fun TestScreenPreview(
    @PreviewParameter(MemoPreviewParameterProvider::class)
    memos: List<Memo>,
) {
    SwemoTheme {
        TestScreen(
            categories = emptyList(),
            selectedCategory = Category(id = "-1", name = "전체 메모"),
            memos = memos,
            // events
            onCategorySelected = {},
            onAddMemoClick = {},
        )
    }
}

2분할된 TestScreen()과 TestScreenPreview()다. 위의 코드가 100% 완성된 앱의 코드였다면, 첫 번째 TestScreen()에서 State를 Repository가 아니라 ViewModel로부터 받아올 것이다 (State Hoisting). 하지만, 본 Iteration에서는 UI에 집중하므로 나중에 업데이트한다.

 

코드 스니펫 - DevicePreviews.kt

package com.example.ui

import androidx.compose.ui.tooling.preview.Preview

/**
 * Multipreview annotation that represents various device sizes. Add this annotation to a composable
 * to render various devices.
 */
@Preview(name = "phone", device = "spec:shape=Normal,width=360,height=640,unit=dp,dpi=480")
@Preview(name = "landscape", device = "spec:shape=Normal,width=640,height=360,unit=dp,dpi=480")
@Preview(name = "foldable", device = "spec:shape=Normal,width=673,height=841,unit=dp,dpi=480")
@Preview(name = "tablet", device = "spec:shape=Normal,width=1280,height=800,unit=dp,dpi=480")
annotation class DevicePreviews

Now in Android에 있는 코드를 그대로 가져왔다. @DevicePreviews 어노테이션을 붙이면, 4개의 프리뷰 화면이 생성된다.

 

스크린샷 -  컴포넌트의 배경이 투명하게 나오는 현상

처음에는, 이 화면이 '논리적 에러'에 가깝다고 생각했다. 하지만, 가만 생각해 보니 아니었다. Preview 화면은 현재 파일 속에 있는 코드만 참조한다. TestScreen.kt 파일 외부의 코드에서 Scaffold(같이 배경색이 존재하는 컨테이너)를 선언한 다음에 TestScreen를 호출하는, 이른바 정석적인 방법이어도 위와 같은 화면이 정상이라는 말이다.

 

배경색이 검은색인 것이 뭔가 거슬린다고 @Preview가 붙은 함수에 별도로 Scaffold를 선언한다? 이러면 객체지향의 의미가 사라져 버린다. Now in Android에 구현된 Preview들도 (컨테이너가 파일 내 없는 경우) 배경이 투명했다.

 

스크린샷 -  보기 방식 변경

'색맹 모드' 설정이 있었다. Preview 화면을 보기 힘들 때 써야겠다.

 

참고

• [GitHub] 이 작업의 Commit
• [Tistory] [Android] Jetpack Compose - State Hoisting
• [GitHub] ForYouScreen.kt at b9a80fc038e8dd1e2dc08fff4ff9feb40d6f3ef3 · android/nowinandroid

 

#2-4 Iteration 2-4: TestScreen 내부 컴포넌트 분리

// in TestScreen.kt
@Composable
fun TestScreen(
    ...
) {
    ...

    ModalNavigationDrawer(
        ...
        drawerContent = {
            // 이번 커밋에 새로 선언한 컴포넌트
            CategorySelector(
                categories = categories,
                ...
            )
        }
    ) {
        Column {
            ...

            // 이번 커밋에 새로 선언한 컴포넌트
            MemoFeed(
                memos = memos,
                ...
            )
        }
    }
}

---

// in MemoFeed.kt
@Composable
fun MemoFeed(
    memos: List<Memo>,
    ...
) {
    LazyColumn(
        ...
    ) {
        items(memos) { memo ->
            // 이번 커밋에 새로 선언한 컴포넌트
            MemoCard(memo = memo)
            ...
        }
    }
}

TestScreen의 내부 컴포넌트들을 분리해 별도의 컴포넌트 함수로 만들었다. 만든 컴포넌트들은 아래와 같다.

 

• CategorySelector: List<Category>를 받아서 Category를 선택할 수 있는 화면을 구현
• MemoFeed: List<Memo>를 받아서 Memo 아이템들이 모여있는 화면을 구현
• MemoCard: Memo 아이템 하나의 정보를 표시

 

관련 개발 범위

• 메모 리스트를 읽기 위한 화면 UI
• 카테고리를 선택하기 위한 화면 UI
• Compose Runtime만으로도 테스트할 수 있는 UI (Compose Preview만 보고 개발)

 

주요 변경점

• TestScreen의 내부 컴포넌트들을 분리해 별도의 컴포넌트 함수 선언
• Memo 아이템 하나를 Card로 감싼 임시 UI (MemoCard())

 

스크린샷 - TestScreen의 Preview

 

참고

• [GitHub] 이 작업의 Commit

 

#2-5 Iteration 2-5: MemoEditor 뼈대 구현

• 본 게시글 맨 위에서부터 언급되는 'Bubble'이라는 개념의 이름을 'Chip'으로 변경했다.
  
  • Chip이라는 UI 컴포넌트 양식이 있다는 걸 몰랐기 때문에 굳이 'Bubble'이라는 이름을 내가 지어내서 사용해 왔다.
  • 이제 Bubble과 (완전히 같진 않더라도) 비슷한 역할을 수행하는 UI 컴포넌트의 일반적인 이름을 알게 되었으니, 'Bubble'이라는 이름은 이제 쓸 이유가 없다.
  • Chip 버튼 하나가 label (#2-2) 하나에 대응한다.
• MemoEditor는 본 앱의 핵심이 되는 UI 컴포넌트다. 많은 정성을 들여야 한다. 작업량이 많을 것이므로, 우선 뼈대만 선언했다.
  • TestScreen¹ (#2-3)에 editingMemo: Memo 와 allLables: Set<Memo>를 선언해서 TestScreen²에 내려주었다.
  • MemoEditor의 하위 컴포넌트인 EditableFieldList 및 LabelChipGroup은 각각 순서대로 editingMemo와 allLabels를 매개변수로 받는다.
  • 이후의 개발 방향: LabelChipGroup에서 추가하고자 하는 label을 선택하면 editingMemo에 해당 label에 대응하는 TextField가 생성

 

관련 개발 범위

• 'Bubble' 개념이 UI에서 표출되는 방식

 

주요 변경점

• MemoEditor의 뼈대 구현
• MemoEditor 하위 컴포넌트(EditableFieldList, LabelChipGroup)들의 뼈대 구현
• 순수 UI를 담당하는 TestScreen()의 매개변수에 editingMemo: Memo 및 allLables: Set<Memo> 추가

 

스크린샷

 

코드 스니펫 - label들의 Set 만들기

val memosFlow = remember(selectedCategory.id) {
    repository.getMemosByCategory(selectedCategory.id)
}
val memos by memosFlow.collectAsState(initial = emptyList())
val allLabels by remember(memos) {
    derivedStateOf {
        memos
            .asSequence()
            .flatMap { it.contents }
            .map { it.label }
            .toSet()
    }
}

'현재 카테고리 (selectedCategory)'에 존재하는 모든 메모가 보유한 label의 교집합인 allLabels를 구하는 코드. allLabels는 LabelChipGroup 컴포넌트에 전달된다.

 

얻은 경험치

• Material Chip의 존재를 알았다.
• Sequence의 존재를 알았다. Sequence는 결과가 실제로 필요(소비)해질 때까지 계산을 미루기 때문에 (Collection에 비해) 자원 낭비가 적다.
• asSequence()는 Collection을 Sequence로 변환한다.
• map()과 flatMap()의 차이는 평탄화다.
• 구조 분해 선언(Destructuring declaration)으로 람다 함수를 더 짧게 쓸 수 있다.
• 거슬리는 변수 이름을 바꾸기 위해서, git rebase를 처음으로 사용해 보았다. 막상 해보니까 별거 없었다!

 

참고

• [GitHub] 이 작업의 Commit
• [Material Design 3] Chips
• [Kotlin Programming Language] Collection | Core API
• [Kotlin Programming Language] Sequence | Core API
• [Kotlin Programming Language] asSequence | Core API
• [velog] map, flatMap 의 차이
• [Kotlin Programming Language] Destructuring declarations

 

#2-6 Iteration 2-6

추가 예정.

 

#3 테스트

추가 예정.

 

#4 개발 결과 (Iteration Outcome)

추가 예정.