Android developer's blog. story.
+270만, -240만, 290개
이건 내가 처음부터 끝까지 서비스 하나를 만들고 약 4년간 작성해본 코드 양이며, 모듈 숫자이다.
혼자 서비스를 하면서 선택한 아키텍처 덕분에 안정적인 서비스를 해볼 수 있었다. 정승욱님이 발표한 코드 제로 관련에 나온 코드를 기반하여 수정하고 개선한 프로젝트를 사용했다.
최근엔 iOS 개발도 약 10개월 진행하였는데 iOS TCA를 이해하면서 작성한 코드 역시 +46만 줄, -32만 줄 수정하였다.
개발에서 아키텍처(Architecture)는 무엇일까? AI는 이렇게 답한다.
소프트웨어 시스템의 기본적인 구조와 구성 요소들 간의 관계, 그리고 이를 통제하는 원칙과 지침. 미래의 변경과 확장에 어떻게 대응할지를 결정하는 청사진(Blueprint).
모두가 동의하겠지만, 미래의 변경과 확장에 유연하게 대응하는 것이 아키텍처의 핵심이다. 더 빠른 개발 속도와 안정성은 덤이다.
그렇다면 오늘날 우리가 클라이언트 개발에 적용하는 아키텍처는 이 목적에 정말 충실할까? 혹시 유행하는 패턴을 ‘좋은 코드’라는 명목 아래 무비판적으로 따르고 있지는 않을까? 이 글에서는 클린 아키텍처의 상징과도 같은 ‘UseCase’의 딜레마를 통해 클라이언트 아키텍처를 좀 더 넓은 시각으로 바라보고자 한다.
원래는 Action 시스템을 활용해서 Router를 쓰려고 설계했지만, 필자가 기존에 사용하던 방식 중 하나로 돌아가 거기서부터 다시 설계되었다.
이 라우터는 크게 두 가지 상황에 활용 가능하다.
만약 싱글 액티비티(Single Activity) 구조를 쓴다면 Compose Navigation 부분만 적용하면 되니 더 쉽게 사용 가능하다.
여기서는 어떻게 활용되었을까?
IntoMap을 활용해서 Key/Value 매핑으로 ActivityRoute를 상속받아 구현한 객체를 정의해서 사용한다.NavigationRoute를 상속받아 구현한다.
Composable Architecture에 대한 세 편의 글에 이어 이번 글을 작성하게 되었다. 이번에는 전반적인 설계가 변경되어 사실상 새로운 아키텍처라고 볼 수 있다.
Action을 ViewModel에 한정하여 사용하도록 변경했다.Router를 새로 추가했으며, Action과 독립적으로 동작하도록 개선했다.Action 활용법 개선 방안을 알아본다.
이 글에서는 Composable Architecture에서 Alert(Dialog)/Toast(Snackbar) 활용법을 소개한다.
기본 형태는 1부/2부에서 소개한 Action을 활용하는 시스템을 적용했다.
이 글은 디자인 시스템이 있을 경우 Dialog/Toast를 공통화시키는 방식을 다루고 있다.