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

#1 개발 목표 (Iteration Goal)

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

이상(Ideal)

'앞선 게시글'에서 말했던 내용의 충실하고 좋은 구현이 내가 바라는 이상이다. 하지만 앱을 만들다 보면 또 다른 형태로, 조금이라도 변할 거라는 직감이 든다. 그래서 현시점에 '이상'을 구체적으로 상상하는 것 자체가 시간 낭비라고 생각한다. 그뿐만 아니라, 오히려 청사진을 그려야 하는 지금 시점에서는 방해가 될 수도 있다는 생각도 든다. 지금은 '완성된 앱의 모습'을 미지수 x처럼 생각하겠다. x값은 분명 좋은 갚을 것이다.

 

앞으로도 제목이 "Iteration n"과 같은 형식의 블로그 게시글에서는 '이상'을 명시적으로 짚고 갈 것이다. 'Top-down' 적으로도 생각해야 'Bottom-up'을 정확하게 수행할 수 있기 때문이다.

 

Iteration 1: 메모 앱의 청사진(기초)

처음에는 Iteration 1의 주제를 막연히 "메모 앱의 기초"로 잡았다. 그러나 '기초'라는 단어는 너무나 추상적이고 범위가 넓기에, 어찌 보면 굉장히 무책임한 표현이 될 수도 있다. 그래서 약간 더 주제를 구체화해서, "메모 앱의 청사진(기초)"으로 잡았다. 단순히 어떤, 낮은(Low) 단계의 프로그래밍을 한다든가 전체적인 모듈 구성을 잡는다는가 하는 식이 아님을 보이기 위해서다. '뼈대' 그중에서도 '핵심 뼈대', 더 정확히는 다른 '뼈대'들의 토대가 되는 뼈대를 만들 것이다. 어떤 고민이든 가지고 놀 실체가 있어야 문제 해결이 빠릿빠릿하게 된다. 앞으로 어떤 설계를 추가해 나갈지 고심하기 위한 틀(Plate)을 만들어보겠다. 확실하지는 않지만, 아마 Iteration 2의 주제는 "메모 앱의 기본"이지 않을까?

 

#1-2 개발 범위

이번 개발 범위 (In Scope)

1. 메모 추가 기능 (사용자가 원하는 문자열을 넣을 수는 없고, 그냥 '메모 객체'만 추가)
2. 메모 읽기 기능
3. 메모 카테고리 읽기 기능 (예를 들면 카테고리 목록 리스트 등)
4. 메모 카테고리 '선택' 기능 (= 특정 메모 카테고리 속의 메모만 모아 읽는 기능)
5. 카테고리 읽기 및 선택을 위한 UI
6. Compose 기반 UI
7. Nutri Capture 시절의 코드 중 현 Iteration에서 당장 쓸 것 아니면 (나중에 다시 추가하는 한이 있더라도) 최대한 제거

 

범위 외 (Out of Scope)

1. 데이터베이스 (실제 데이터베이스 대신 목업으로만 진행)
2. 메모에 내용(어떤 문자열) 넣기
3. 메모 수정
4. 메모 삭제
5. 메모 카테고리 추가 (빌트인 가구처럼, 컴파일 단계에서 카테고리 하드 코딩해서 넣어줄 것임)
6. 다른 카테고리에 메모 넘겨주기 (예를 들면 A 카테고리에서 작성한 메모를 B 카테고리로 옮기기)
7. 메모 추가 시의 애니메이션 (기본 애니메이션 있으면 그대로만 사용)
8. 카테고리 UI 여닫을 때의 애니메이션 (기본 애니메이션 있으면 그대로만 사용)
9. 기능 확인만을 위한 최소 UI 외 모든 UI 작업
10. 'Bubble' 관련 작업

 

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

#2-1 Iteration 1-1: 기존 코드 제거

의존성 그래프다. NutrientScreen()을 호출하는 자리에 TestScreen()을 대신 뒀다. TestScreen()은 자리만 차지하게 두는, 임시 컴포넌트의 역할이다. 그리고 이 상태에서 앱 실행 구동 시 사용되지 않는, '거의' 모든 코드를 제거했다. "혹시라도 나중에 쓸 수도 있지 않을까?"라는 생각이 드는 코드는 삭제하되, "이건 머지않아 반드시 쓴다"라는 생각이 드는 코드는 남겼다. 삭제한 코드 중 추후 정말로 필요한 코드가 있다면, 그때 가서 다시 추가한다.

 

관련 개발 범위

• Nutri Capture 시절의 코드 중 현 Iteration에서 당장 쓸 것 아니면 (나중에 다시 추가하는 한이 있더라도) 최대한 제거

 

주요 변경점

• 거의 모든 코드 제거
• 여러 실험적인 시도들을 수행할 TestScreen() 컴포넌트 생성

 

참고

• [GitHub] 이 작업의 Commit

 

#2-2 Iteration 1-2: Data entity와 Data access abstraction 추가

처음에는 "일단 데이터베이스를 만들어야 하나?"라고 막연히 생각했다. 그러나 현 단계에서는 불필요한 구현이라고 판단했다. 그 대신, DIP 원칙을 고려해 먼저 '정책'에 해당하는 'MemoRepository'를 만들기로 했다. 그러려면 Repository에서 다룰 데이터 클래스가 필요하므로 Memo 클래스도 만들었다.

 

app 모듈이 data 모듈을 참조할 수 있어야 하므로, build.gradle에

implementation(project(":data"))

를 추가해 주어야 하는데, Now in Android에서는

implementation(projects.data)

와 같은 형태로 모듈 의존성 추가를 하고 있었다. 후자의 방식은 Gradle의 Type-safe Project Accessors 기능인데, 나도 이번 커밋부터 적용했다.

 

관련 개발 범위

• 메모 추가 기능 (사용자가 원하는 문자열을 넣을 수는 없고, 그냥 '메모 객체'만 추가)
• 메모 읽기 기능
• Compose 기반 UI

 

주요 변경점

• Data entity (Memo)와 Repository (MemoRepository) 추가
• FakeMemoRepository 추가 및 이를 활용해 TestScreen()에 아주 간단한 테스트 UI 작성
• build.gradle에 Type-safe Project Accessors 기능 적용

 

스크린샷

 

Flow 개념 복습

@Composable
fun TestScreen() {
    val repository: MemoRepository = remember { FakeMemoRepository() }
    val memos by repository.getMemos().collectAsState(initial = emptyList())
    val memosText = memos.joinToString("\n") { it.content }

    Box(
        modifier = Modifier
            .fillMaxSize()
            .clickable(
                onClick = {
                    repository.insertMemo("Inserted memo")
                }
            ),
        contentAlignment = Alignment.Center
    ) {
        Text(memosText)
    }
}

Flow는 단어 그대로 '데이터(값)의 흐름'이라, 현재 값이라는 개념이 없다. 반면, UI(Jetpack Compose)는 '지금' 그려야 할 값이 무엇인지를 알아야 한다. 그래서 위의 코드처럼 Flow -> State로 변환하는 Flow.collectAsState()를 써야 한다.

좀 더 지엽적인 추가 설정을 하려면, Flow -> StateFlow -> State로 변환해야한다. StateFlow -> State는 Flow.collectAsState()를 똑같이 쓰면 되고, Flow -> StateFlow 변환엔 Flow.stateIn()을 쓰면 된다. stateIn()은 Flow의 수명을 코루틴과 동기화시킬 수 있는 scope 매개변수와 Flow의 collect를 언제 시작하고 언제 멈출 것인지를 정하는 started 매개변수를 보유한다.

 

2026-01-15 수정

Repository에서 반환해야 하는 건 Data entity가 아니라, Domain model이다. 따라서 여기서 다룬 건 사실 Domain model이다. 이런 깨알 같은 용어 가지고 이러는 걸로, 스스로 쪼잔하다는 생각도 조금 든다. 다만 사소하다는 이유로, 넘겨짚듯이 스르륵 빠져나가다 보면 나중엔 회피형(?) 개발자가 되어 버릴지도 모른다.

 

참고

• [GitHub] 이 작업의 Commit
• [Tistory] [Gradle] Type-safe Project Accessors 도입 배경 및 사용법
• [Tistory] Unit Testing - Test double
• [Wikipedia] Entity–relationship model

 

#2-3 Iteration 1-3: 청사진을 위한 최소 UI

'메뉴 바'를 구현했다. 왜냐하면 개발 범위에 있는 '메모 카테고리 읽기 기능' 구현을 위해 카테고리 리스트를 둘 장소가 필요했기 때문이다. 처음에는 메뉴 바가 임시 UI로는 부적합하다고 판단했다. 메뉴 바 구현에 시간이 걸릴 수 있기 때문이다. 이때, Jetpack Compose에 기본 제공되는 ModalNavigationDrawer의 존재를 알았다. 이를 이용해 쉽고 빠르게 구현할 수 있었다.

 

관련 개발 범위

• 카테고리 읽기 및 선택을 위한 UI
• Compose 기반 UI

 

주요 변경점

• :feature:test 모듈 만들고 해당 모듈로 TestScreen() 옮김
• ModalNavigationDrawer를 이용해 TestScreen()에 '메뉴 바' 추가

 

스크린샷

 

TestScreen()의 구조

@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun TestScreen() {
    ...
    ModalNavigationDrawer(
        drawerState = drawerState,
        drawerContent = {
            ...
        }
    ) {
        ...

        Column(
            modifier = Modifier.fillMaxSize()
        ) {
            TopAppBar(
                ...
                navigationIcon = {
                    IconButton(
                    ...
                },
                actions = {
                    IconButton(
                    ...
                }
            )
            Text(
                text = memosText,
                modifier = Modifier.fillMaxWidth()
            )
        }
    }
}

ModalNavigationDrawer는 표시할 컴포넌트에 '씌우듯이' 사용하면 된다. 지금은 Column에 씌웠지만, 나중에는 아마 Scaffold에 씌우지 않을까?

 

참고

• [GitHub] 이 작업의 Commit
• [Android Developers] Navigation drawer  |  Jetpack Compose
• [Material Design] Navigation drawer

 

#2-4 Iteration 1-4: Fake Catetory 및 상호작용

#2-2와 유사한 방식으로, Category라는 Data entity를 추가했다. 이에 맞춰 MemeRository와 Memo 클래스를 수정했다. 마지막으로 사용자가 (UI에서) 카테고리와 상호작용을 할 수 있게 했다.

 

관련 개발 범위

• 메모 카테고리 읽기 기능 (예를 들면 카테고리 목록 리스트 등)
• 메모 카테고리 '선택' 기능 (= 특정 메모 카테고리 속의 메모만 모아 읽는 기능)

 

주요 변경점

• Data entity (Category) 추가
• data class인 Memo에 카테고리 표시를 위한 프로퍼티("categoryName") 추가
• MemoRepository의 메소드들이 카테고리 개념을 포함하도록 업데이트
• TestScreen() 속 '메뉴 바'(#2-3)에 카테고리 목록을 표시, 카테고리의 각 항목 클릭 시 해당 항목에 속하는 메모만 표시

 

스크린샷

#2-3에 있는 스크린샷과 비교하면 TopAppBar()의 색이 다른데, #2-3은 다크 모드일 때 스크린샷을 찍었고 여기서는 라이트 모드일 때 찍었기 때문이다. 앞으로는 모드의 일관성을 지켜서 스크린샷을 찍어야겠다.

 

카테고리별 메모 데이터 조회 (FakeMemoRepository)

package com.example.data

...

class FakeMemoRepository : MemoRepository {
    private val categoriesFlow = MutableStateFlow<List<Category>>(
        ...
    )

    private val memosFlow = MutableStateFlow<List<Memo>>(
        listOf(
            Memo(content = "Fake memo 1 (category 1)", categoryName = "category 1"),
            Memo(content = "Fake memo 2 (category 1)", categoryName = "category 1"),
            Memo(content = "Fake memo 3 (category 2)", categoryName = "category 2"),
            Memo(content = "Fake memo 4 (category 2)", categoryName = "category 2"),
            Memo(content = "Fake memo 5 (category 3)", categoryName = "category 3"),
            Memo(content = "Fake memo 6 (category 3)", categoryName = "category 3"),
        )
    )

    ...

    override fun getMemosByCategory(categoryName: String?): Flow<List<Memo>> {
        return memosFlow.map { memos ->
            if (categoryName == null) {
                memos
            } else {
                memos.filter { it.categoryName == categoryName }
            }
        }
    }

    ...
}

Test double에서 카테고리별 메모 데이터를 가져오는 메소드.

 

참고

• [GitHub] 이 작업의 Commit
• [Tistory] Unit Testing - Test double