다시 2부 - Composable Architecture - 라우터 소개

다시 2부 - Composable Architecture - 라우터 소개

원래는 Action 시스템을 활용해서 Router를 쓰려고 설계했지만, 필자가 기존에 사용하던 방식 중 하나로 돌아가 거기서부터 다시 설계되었다.

이 라우터는 크게 두 가지 상황에 활용 가능하다.

  • Activity 간 화면 이동
  • Compose Navigation 간 화면 이동

만약 싱글 액티비티(Single Activity) 구조를 쓴다면 Compose Navigation 부분만 적용하면 되니 더 쉽게 사용 가능하다.

여기서는 어떻게 활용되었을까?

  • Activity는 Dagger의 IntoMap을 활용해서 Key/Value 매핑으로 ActivityRoute를 상속받아 구현한 객체를 정의해서 사용한다.
  • Compose Navigation은 NavigationRoute를 상속받아 구현한다.

이 글에서는

  • 새로운 Router의 설계 철학 및 동작 방식을 자세히 알아본다.
  • Activity 및 Compose Navigation에서 Router를 활용하는 구체적인 코드 예시를 살펴본다.

Read More

다시 - Composable Architecture 설계 변경

다시 - Composable Architecture 설계 변경

Composable Architecture에 대한 세 편의 글에 이어 이번 글을 작성하게 되었다. 이번에는 전반적인 설계가 변경되어 사실상 새로운 아키텍처라고 볼 수 있다.

가장 큰 변화는 무엇인가?

  • 싱글턴으로 활용하던 ActionViewModel에 한정하여 사용하도록 변경했다.
  • Router를 새로 추가했으며, Action과 독립적으로 동작하도록 개선했다.

이 글에서는

  • Action 활용법 개선 방안을 알아본다.
  • 이전 설계에서 발생했던 문제점들을 짚어본다.

Read More

3부 - Composable Architecture에서는 Alert/Toast는 어떻게 사용할 수 있는가?

3부 - Composable Architecture에서는 Alert/Toast는 어떻게 사용할 수 있는가?

이 글에서는 Composable Architecture에서 Alert(Dialog)/Toast(Snackbar) 활용법을 소개한다.

기본 형태는 1부/2부에서 소개한 Action을 활용하는 시스템을 적용했다.

이 글은 디자인 시스템이 있을 경우 Dialog/Toast를 공통화시키는 방식을 다루고 있다.

이 글에서는

  • Alert/Toast(Snackbar)를 공통화 시켜 다루는 내용
  • 앞에서 설명한 Action을 설명하지는 않는다.
  • 기본적인 내용을 담지 않고있어 앞선 글을 참고하면 좋다.

Read More

2부 - Composable Architecture는 만들었는데 문제가 있었네? 개선해보자.

2부 - Composable Architecture는 만들었는데 문제가 있었네? 개선해보자.

이전 글에서 Composable Architecutre를 소개하는 내용을 담아보았는데, 몇 가지 문제점을 발견하여 이를 개선한 내용을 다시 정리하는 글이다.

크게 2가지 문제점을 확인하였다.

  • ViewModel 내 Reducer 처리 후 자동 next
  • Action 스트림 처리를 위한 싱글턴 활용 시 Lifecycle 문제

이 2가지 문제점을 해결하기 위해 코드를 어떻게 수정했는지, 그리고 더 나은 방법은 없을지 고민한 과정을 정리해본다.

이 글에서는

  • 기존 아키텍처의 구조적 문제점을 파악한다.
  • 문제 해결 과정과 더 나은 구조에 대한 고민을 공유한다.
  • 기본적인 내용을 담지 않고있어 앞선 글을 참고하면 좋다.

Read More

1부 - 컴포즈에 사용할 Composable Architecture 설명(리엑트?)

1부 - 컴포즈에 사용할 Composable Architecture 설명(리엑트?)

이 글은 최근 유행하는 MVI (Model-View-Intent) 패턴과는 다른, 리액트의 Reducer, UiState, Effect, Action 개념을 포함하는 T Composable Architecture를 소개하는 글의 첫 번째 편입니다.

T는 글쓴이 이름의 첫 글자이며, 나머지는 Compose와 Architecture를 의미합니다.

Compose에서는 MVI가 가장 적합하다는 의견이 많지만, MVI를 소개하는 cycle.js.org에서는 다음과 같이 설명합니다.

cycle.js.org - Model-View-Intent - 링크

Model-View-Intent (MVI) is reactive, functional, and follows the core idea in MVC. It is reactive because Intent observes the User, Model observes the Intent, View observes the Model, and the User observes the View. It is functional because each of these components is expressed as a referentially transparent function over streams. It follows the original MVC purpose because View and Intent bridge the gap between the user and the digital model, each in one direction.

위를 번역하면 아래와 같은데,

모델-뷰-인텐트(MVI)는 반응적이고 기능적이며 MVC의 핵심 아이디어를 따릅니다. 인텐트가 사용자를 관찰하고, 모델이 인텐트를 관찰하고, 뷰가 모델을 관찰하고, 사용자가 뷰를 관찰하기 때문에 반응형입니다. 이러한 각 구성 요소는 스트림을 통해 참조적으로 투명한 함수로 표현되므로 기능적입니다. 뷰와 인텐트는 각각 한 방향으로 사용자와 디지털 모델 사이의 간극을 메우기 때문에 원래의 MVC 목적에 부합합니다.

핵심은 reactive, functional, MVC의 융합입니다. 지금 우리가 사용하는 MVI 패턴과는 다른 부분이 있는데, reactive와 functional은 같고 MVVM을 포함해서 UDF(단방향 데이터 흐름)가 더 적합하다고 보는 것이 좋아보인다.

이 글에서는

  • 필자가 생각하는 Composable 구조는?

Read More