Android Architecture은 어떻게 해야할까? (2) UI Layer

이 내용은 Android Developer내용을 읽어보면서 정리한 내용이므로,

더 자세한 내용을 알고 싶으면 공식홈페이지에서 읽으면 됩니다!.!

 

UI Layer

UI Layer가 일단 무엇을 하는 계층인가?

사용자에게 보여지는 계층으로, 사용자에게 데이터를 보여주고 앱 상호작용을 담당한다고 보면 된다.

 

이전에 나는 MVVM 구조와 MVI구조에 대해서 많이 고민을 했었는데,

Compose의 등장과 현재 보여주어야 하는 뷰를 하나의 상태로 관리한다는 점이 매력적이어서 이를 사용하기로 하였고,

좀 구현시에는 귀찮은 과정이 몇몇 존재하지만 더 깔끔하게 UI Layer을 구성할 수 있지 않을까라는 생각이 든다..

내가 참고한 많은 게시글 중에 아래의 글이 기본적으로 도움이 많이 되었다.

https://codingtroops.com/android/compose-architecture-part-1-mvvm-or-mvi-architecture-with-flow/

Compose architecture: MVVM or MVI with Flow?

 

그런데 위와같은 MVIViewModel이 따로 필요한 것인가에 대해서는 의문이 든다..

왜 저러한 구조의 ViewModel이 필요한가에 대해서는

공부를 해서 정리를 해보고 필요에 의해서 사용할지 결정해봐야 겠음.

 

일단은 안드로이드 공식 예제들이 UI State를 통한 관리를 하는것을 보아 나도 그런식으로 개발을 해야겠다.

 

 

본격적으로 UI Layer는 다음과 같은 동작을 한다.

 

1. Data에는 사용자에게 보여줄 데이터 말고도 다른 데이터가 포함되어 있다.

그러한 데이터중 사용자에게 필요한 데이터로 가공한다.

 

2. 위의 데이터를 사용하여 UI 로 변환하다.

 

3. UI를 통해 표현된 뷰와 상호작용하는 동작에 의한 결과를 반영한다.

 

 

 

Android Developer 페이지에서는 다음과같은 순서로 설명을 한다.

 1. UI State 저장 방법

 

 2. UI 상태를 생성하고 관리하는 Unidirectional data flow

 

 3. UDF 원칙에 따라 관찰 가능한 데이터 유형으로 UI 상태를 노출하는 방법

 

 4. 관찰 가능한 UI 상태를 사용하는 UI를 구현하는 방법

 

이러한 흐름을 따르되 내가 사용하는 방법을 추가해서 정리를 해야겠다.

 

1. UI State 저장 방법

1. UI State 정의

 

UI에 사용될 모든 데이터들을 정의해준다.

공식 가이드의 예에 로딩하는 UI State를 추가한다면,

data class NewsUiState(
    val isSignedIn: Boolean = false,
    val isPremium: Boolean = false,
    val newsItems: List<NewsItemUiState> = listOf(),
    val userMessages: List<Message> = listOf(),
    val isLoading : Boolean = false
)

data class NewsItemUiState(
    val title: String,
    val body: String,
    val bookmarked: Boolean = false,
    ...
)

하나의 뷰에 나타나를 UI State를 하나의 Data Class를 통해서 관리한다.

이 Data Class를 통해서 관리하면 장점이.

Copy가 가능하다는 건데 변화가 있는 부분만 쉽게 변경하여 상태를 관리 할 수 있다.

 

2. 불변성

위의 예처럼 모두 변하지 않는 상태로 UI State를 정의함으로 ,

  일관성을 유지할 수 있으며, UI Layer에서는 이를 변경하지 않아야함.

데이터의 업데이트나 변화는 Data Layer의 몫이다.

Event에 의해서만 UI State가 변하게 된다.

 

위의 불변성의 설명에는 의문이 드는데, 만약 게시판의 글을 작성한다고 생각을 해보자

1) 내가 글을 작성함

2) 서버에 내 글을 저장함

3) 서버에서 저장된 내 글을 불러온다

4) 불러온 글을 통해 뷰를 업데이트 한다.

 

또는 좋아요를 누를 경우

1) 글에 좋아요를 누름

2) 로컬 DB 또는 서버(Data Source) 에 좋아요 누름이 입력됨

3)  서버에서 변경된 사항을 받아온다

4) 글에 좋아요가 눌러짐

 

위의 방식으로 업데이트를 하는게 맞나? 

내가 이해하기로는 맞음..

 

이렇게 하는 이유가 하나의(유일한) Data Source를 통해서 데이터를 관리하는게

복잡해 지지 않는다는 이유임.

 

만약 

1) 좋아요 누름

2) ViewModel에서 좋아요 누른 Item의 상태를 변경함

3) Data Source에 올림

2,3은 동시에 작업

4) 좋아요 눌려진 것이 보임

여기서 에러에 의해 2에 의해서만 반영이 되고 3은 정상적으로 동작하지 않았다면

 데이터 일관성이 성립안함.

 

2. UI 상태를 생성하고 관리하는 Unidirectional data flow

 

앞서 얘기한 것처럼 UI Controller에서 Data를 표시하는것 이외의 다른 역할을 부여하게 되면 복잡해지게 됨

역할을 분리하는 아키텍쳐 패턴을 Uni Directional Data Flow라고 함.

아래의 그림과 같은 패턴을 말한다.

데이터는 아래를 향해서 내려가고 이벤트는 위를 향함. 

이해하기 쉽다.

 

Compose 쓰면서 State는 하위로 내리고 Event는 상위로 올리는 것과 비슷함.

Composable에 대해서는 담에 다시 정리해 봐야겠다.

 

 

위와 같이 UDF로 구성하면 좋은 점은

1) 데이터의 일관성

2) 테스트 용이성

3) 유지 관리성

이 될 수 있다고 한다.

 

3,4 의 설명의 경우는 직접 사용하면서 익히는게 더 좋을거 같아서 생략!