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' 개념도 여기서부터 조금씩 도입해 나간다. 사실 이 개념은 말로 표현하기가 어렵다. 그래서 구구절절 읊기보다는, 코드 그리고 스크린샷으로 보여주려고 한다 (#2-5 참조).

 

#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가 생성

 

관련 개발 범위

• 메모를 추가하기 위한 화면 UI
• '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: MemoEditor - 여러 버튼 추가

• MemoEditor를 일부 구현했다
  • MemoEditor는 본 프로젝트에서 아마 제일 복잡한 컴포넌트이기 때문에 적절하게 나눠줄 필요가 있다. 그래서 하위 컴포넌트 2개를 새로 선언했다.

 

관련 개발 범위

• 메모를 추가하기 위한 화면 UI
• 'Bubble' 개념이 UI에서 표출되는 방식

 

주요 변경점

• MainActivity에 있던 'IME에 의해 UI가 밀리지 않게 하는 코드'를 제거
• MemoEditor의 하위 컴포넌트인 MemoEditorActionBar 추가
• EditableFieldList의 하위 컴포넌트인 MemoContentTextField 추가

 

스크린샷

맨 아래에 있는 + 버튼과 ▷ 버튼은 MemoEditorActionBar 속에 있다.

 

참고

• [GitHub] 이 작업의 Commit

 

#2-7 Iteration 2-7: MemoEditor - 토글 버튼

토글 버튼을 통해서 MemoEditor를 접거나 펼칠 수 있게 만들려 했다. 그런 동작을 수행하는 데에 쓸만한 UI는 FAB다. FAB를 수월하게 배치하기 위해서 Scaffold를 도입 후 FAB을 구현했다.

 

관련 개발 범위

• 메모를 추가하기 위한 화면 UI

 

주요 변경점

• TestScreen에 Scaffold 선언 후 Scaffold의 topBar, bottomBar, content 슬롯에 각각 TopAppBar, MemoEditor, MemoFeed 배치
• Scaffold의 FAB 슬롯에 배치한 버튼 클릭 시 MemoEditor를 펼치거나 접을 수 있게 함

 

스크린샷 - MemoEditor 접힘

 

스크린샷 - MemoEditor 펼침

 

코드 스니펫 - Scaffold 구조

// state 주입용
@Composable
fun TestScreen(...) {
    ...

    // etc
    var isMemoEditorVisible by remember { mutableStateOf(false) }

    TestScreen(
        ...
        isMemoEditorVisible = isMemoEditorVisible,
        ...
        onMemoEditorToggleButtonClick = {
            isMemoEditorVisible = !isMemoEditorVisible
        },
    )
}

// 순수 UI
@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun TestScreen(
    ...
    isMemoEditorVisible: Boolean,
    ...
    onMemoEditorToggleButtonClick: () -> Unit,
) {
    ...

    ModalNavigationDrawer(
        ...
    ) {
        Scaffold(
            topBar = {
                TopAppBar(
                    ...
                )
            },
            bottomBar = {
                if (isMemoEditorVisible) {
                    ... // MemoEditor()
                }
            },
            floatingActionButton = {
                Button(
                    onClick = {
                        onMemoEditorToggleButtonClick()
                    }
                ) {
                    ...
                }
            },
            ...
        ) { ...
            MemoFeed(
                ...
            )
        }
    }
}

 

얻은 경험치

• rememberSaveable를 오랜만에 마주쳤다(?). remember와는 달리 화면 회전 등으로 인한 Compose UI의 초기화 시에도 값을 유지한다. 물론 나는 추후 ViewModel을 사용할 것이므로 여기에서 사용하진 않았다.

 

참고

• [GitHub] 이 작업의 Commit
• [Tistory] [Android] Jetpack Compose - Scaffold
• [Material Design 3] FAB
• [Tistory] [Android] Jetpack Compose - State Remembering

 

#2-8 Iteration 2-8: AddCategoryDialog

새 카테고리 추가 버튼 그리고 버튼을 클릭했을 때 새 카테고리 이름 입력을 위한 Dialog의 모양을 잡았다.

 

관련 개발 범위

• 카테고리를 추가하기 위한 화면 UI

 

주요 변경점

• 카테고리 리스트에 '+' 버튼 추가
• 카테고리 리스트의 '+' 버튼 클릭 시, 카테고리를 추가하기 위한 Dialog 뜨게 만듦

 

스크린샷

 

코드 스니펫 - TestScreen()

@Composable
fun TestScreen(
    ...
    isAddCategoryDialogVisible: Boolean,
    ...
    onAddCategoryDialogVisibleChange: (Boolean) -> Unit,
) {
    ...

    ModalNavigationDrawer(
        ...
        drawerContent = {
            CategorySelector(
                ...
                onAddCategoryButtonClick = {
                    onAddCategoryDialogVisibleChange(true)
                }
            )
        }
    ) {
        Scaffold(
            ...
        ) { ...
            MemoFeed(
                ...
            )
        }
    }

    if (isAddCategoryDialogVisible) {
        AddCategoryDialog(
            ...
        ) {
            ...
        }
    }
}

 

참고

• [GitHub] 이 작업의 Commit
• [Material Design 3] Dialogs

 

#2-9 Iteration 2-9: 코드 정리

Iteration 2에서 중점적으로 개발한 모듈은 :feature:test 모듈이다. 개발이 진행되면서 이 모듈은 ('UI의 큰 틀'이라는 역할을 얻은 대신) 'test'로서의 의미를 잃어버렸다. 따라서 이름을 :feature:memo로 변경했다. 그리고 Now in Android의 코드에 기반해서, 이번 Iteration에서 추가한 코드들을 정리했다. 기능적으로는 바뀐 게 전혀 없다. 마지막으로 Iteration 1-1에서 제거하지 않았던 코드들을 제거했다. 다음에 다시 추가할 확률이 높은 코드지만, 아무런 의미도 없는 코드를 오랫동안 방치하는 상황이 싫었다.

 

주요 변경점

• :feature:test 모듈의 이름을 :feature:memo로 변경
• TestScreen의 이름을 MemoScreen으로 변경
• MemoScreen에서 사용하는 여러 컴포넌트들을 components라는 이름의 패키지에 몰아 넣음
• 아이콘 파일들을 :designsystem 모듈로 이동시키고, object SwemoIcons를 통해 접근하도록 만듦
• :database, :common, :datastore 모듈 제거

 

참고

• [GitHub] 이 작업의 Commit
• [GitHub] android/nowinandroid

 

#4 개발 결과 (Iteration Outcome)

#4-1 이번 Iteration 요약

Swemo의 프론트엔드의 윤곽을 잡았다. 앞으로도 위의 모습에서 크게 달라질 일은 없을 것으로 예상한다.

 

#4-2 다음 개발을 위한 상황 정리

Iteration 1과 2는 개발 방향에 대해 '간을 보는' 성격이 컸다. 이후론 Swemo의 속살을 채우는 작업을 하게 될 것이다. 다음에 뭘 할지는 아직 정하지 않았지만, 당장 생각나는 후보들은 아래와 같다.

 

• ViewModel 구조 정비
  
  • 현재 편의상 UI 레이어에 자리 잡은 상태(State)들을 ViewModel로 이관
  • 상태 관리 책임을 더 명확히 분리
• Preview 중심 구현의 런타임 동작 보장
  • Iteration 2에서 구성한 UI 구조가 Preview 환경에 국한되지 않고, 실제 Android 런타임 환경에서도 동일하게 동작하도록 보완
• IME 대응을 고려한 UI 구조 (고도화)
  • Iteration 2에서 설계한 UI는 (의도적으로) IME 영역을 고려하지 않은 상태이므로, 향후 IME 펼침ㆍ숨김 상황에서도 자연스럽게 동작하도록 개선