기존 Android(Java + XML)에서의 화면과 데이터 이동
기존 Android(Java + XML) 환경에서는
화면의 단위가 Activity와 Fragment였다.
Activity → Activity
- 화면 이동과 데이터 전달이 단순했다.
Intent에 데이터를 담아서 다음 Activity로 넘기면 됐다.- 화면과 데이터 이동이 1:1 구조였다.
Fragment → Fragment
- Fragment는 서로 직접 데이터를 주고받지 않았다.
- Activity가 중재자 역할을 담당했다.
일반적인 구조는 다음과 같았다.
- Fragment1에서 사용자 이벤트 발생
- Interface를 통한 콜백으로 Activity에 이벤트 전달
- Activity가 Fragment2를 생성
- Fragment2에
Bundle / arguments로 데이터 전달
즉,
Fragment → Fragment 데이터 이동의 책임은 Activity에 있었다.
Fragment는 “이벤트를 발생시키는 UI” 역할에 가깝고,
데이터 전달과 화면 전환의 결정권은 Activity가 가지고 있었다.
Compose에서의 화면 구조 관점
Compose에서는 화면을 바라보는 관점이 바뀐다.
- 화면의 단위는 더 이상 Activity / Fragment가 아니다.
- 상위 UI는 NavHost
- 하위 UI는 Composable 함수
이 구조를 기존 개념에 대응시키면 다음과 같이 이해할 수 있다.
- Activity → NavHost
- Fragment → Composable
- Interface 콜백 → 람다 콜백
즉,
NavHost를 상위 UI, Composable을 하위 UI로 보면
Compose 구조는 기존 Fragment → Fragment 구조와 매우 유사하다.
Compose에서의 데이터 이동 방식
Compose에서는
“화면에서 화면으로 값을 직접 넘긴다”기보다는,
공유된 상태를 저장해두고,
다음 화면이 그 상태를 읽는 방식을 사용한다.
이를 위해
- 일반 클래스
- ViewModel
같은 상태 보관용 객체를 사용한다.
예를 들어,
- Home 화면에서 값을 클래스에 저장하고
- Viewer 화면으로 이동한 뒤
- Viewer 화면이 그 값을 읽어 UI를 그리는 방식이다.
이 방식은 기존 Fragment 구조에서
Activity가 값을 들고 있다가 Fragment2에 전달하던 구조와
개념적으로 닮아 있다.
일반 클래스 vs ViewModel
일반 클래스를 사용해도
Composable 간 데이터 이동은 가능하다.
하지만 실제 앱에서는
ViewModel 사용이 더 권장된다.
이유는 다음과 같다.
-
일반 클래스 + remember
- Composable 생명주기까지만 안전
- 화면 회전이나 Activity 재생성에 취약
-
ViewModel
- 화면(Activity / NavHost) 생명주기에 안전
- 화면 회전에도 상태 유지
- 테스트와 확장이 용이
즉,
앱 규모가 커질수록 상태는 UI 밖(ViewModel)에 두는 것이 더 안정적이다.
핵심 정리
-
XML 시대
- Activity가 Fragment 간 데이터 이동을 중재
-
Compose 시대
- NavHost(상위 Composable)가 화면 전환과 상태 흐름을 중재
그리고
- Interface 콜백은 람다 콜백으로 바뀌었고
- Bundle 기반 전달은 ViewModel 기반 상태 관리로 바뀌었다
하지만 본질적으로는
“하위 UI는 이벤트만 발생시키고,
상위 구조가 상태와 화면 전환을 관리한다”는 개념은 그대로다.
