우리가 만들 흐름

지금은 이것만 기억하세요

준비물

일반 앱과 비교하면 쉽습니다

Remote Compose는 여기서 무엇을 하나요?

언제 유용할까요?

• 앱 배포 주기와 별개로 프로모션, 설문, 체크리스트 구성을 바꾸고 싶을 때
• Android가 허용한 UI와 액션 범위 안에서 서버가 화면 순서를 결정하게 할 때
• 여러 앱 버전이 같은 문서를 안전하게 재생하도록 호환성 규칙을 운영할 수 있을 때

다음 단계에서는 설명보다 먼저 실제 샘플을 실행합니다.

1. 서버 실행

server/는 독립 Gradle 프로젝트입니다. 아래 명령은 Android 앱을 빌드하지 않고 서버만 실행합니다.

cd samples/remote-state-lab/server
./gradlew run

2. 앱 실행과 연결

cd samples/remote-state-lab
./gradlew :app:assembleDebug

1. 1
   앱을 에뮬레이터에서 실행

   처음 보이는 화면은 일반 Jetpack Compose로 만든 연결 화면입니다.

2. 2
   http://10.0.2.2:8080 입력

   Android Emulator에서 Mac의 8080 포트로 접근하는 주소입니다.

3. 3
   연결 선택

   앱이 GET /document로 바이트를 받고 Remote Compose 화면을 엽니다.

관찰할 것

이름은 비슷해도 실행 장소가 다릅니다

가장 작은 작업 목록

private fun RcScope.TaskListContent() {
    Column(
        modifier = Modifier.fillMaxSize().padding(18f),
    ) {
        Text("오늘 할 일")
        Text("API 회귀 테스트")
    }
}

1. 1
   RcScope. 확장 함수

   Remote Compose writer를 receiver로 받아 operation을 추가합니다.

2. 2
   Column

   세로 container를 문서에 기록하고 block 안의 child operation을 이어서 기록합니다.

3. 3
   Text(String)

   procedural DSL에는 일반 String overload가 있으므로 이 경로에서는 .rs가 필요하지 않습니다.

왜 restricted 배지가 붙나요?

alpha14에서 이 저장소가 사용하는 RcScope와 createRcBuffer는 AndroidX source상 LIBRARY_GROUP 제한 API입니다. 서버 중심 SDUI를 가장 직접적으로 실험할 수 있지만, 안정 public 계약으로 간주하면 안 됩니다.

서버 안에서 일어나는 네 단계

실제 서버의 문서 생성 함수

fun buildChecklistDocument(snapshot: ChecklistServerSnapshot): ByteArray =
    createRcBuffer(
        rcProfile,
        RemoteComposeWriter.HTag(Header.DOC_WIDTH, 390),
        RemoteComposeWriter.HTag(Header.DOC_HEIGHT, 720),
        RemoteComposeWriter.HTag(
            Header.DOC_DENSITY_BEHAVIOR,
            CoreDocument.DENSITY_BEHAVIOR_DP,
        ),
    ) {
        TaskListContent()
    }

1. 1
   rcProfile

   writer와 player가 어떤 Remote Compose profile을 전제로 하는지 정합니다.

2. 2
   Header.*

   문서 viewport와 density behavior 같은 해석 조건을 기록합니다.

3. 3
   { TaskListContent() }

   createRcBuffer가 자동으로 RootLayoutComponent를 기록하고, 이 block의 layout/text operation을 그 아래에 넣습니다.

4. 4
   ByteArray

   createRcBuffer가 Header와 operation을 전송 가능한 binary document로 반환합니다.

Header, root, state를 섞지 마세요

Jetpack Compose state와 실행 방식이 다릅니다

procedural DSL로 완료 토글 만들기

val done = remoteNamedInteger("done", 0)

StateLayout(stateIndex = done) {
    Box(modifier = Modifier.onClick { setValue(done, 1) }) {
        Text("미완료")
    }
    Box(modifier = Modifier.onClick { setValue(done, 0) }) {
        Text("완료")
    }
}

1. 1
   remoteNamedInteger("done", 0)

   초깃값 0을 가진 document state를 만들고 writer가 사용할 ID를 연결합니다.

2. 2
   StateLayout(stateIndex = done)

   state 값과 같은 순서의 child 하나를 표시하는 selector operation을 기록합니다.

3. 3
   첫 번째 layout child

   done = 0일 때 첫 Box와 “미완료”를 표시하고, click action은 값을 1로 바꿉니다.

4. 4
   두 번째 layout child

   done = 1일 때 두 번째 Box와 “완료”를 표시하고, click action은 값을 0으로 되돌립니다.

생성된 문서를 단순화하면 이렇습니다

ID #42는 이해를 위한 예시입니다. 실제 ID는 writer가 문서를 만들며 할당합니다.

Player 동작을 직접 눌러봅니다

어떤 상태를 어디에 둘까요?

실제 샘플의 StateLayout 구조

val screen = remoteNamedInteger("screen", 0)

StateLayout(
    stateIndex = screen,
    modifier = Modifier.fillMaxSize(),
) {
    TaskListScreen(snapshot, screen)

    snapshot.tasks.forEach { task ->
        TaskDetailScreen(snapshot, task, screen)
    }
}

행을 누르면 왜 상세가 보이나요?

snapshot.tasks.forEachIndexed { index, task ->
    TaskRow(
        task = task,
        detailScreenIndex = index + 1,
        screen = screen,
    )
}

// TaskRow 내부
Modifier.onClick {
    setValue(screen, detailScreenIndex)
}

// 상세의 뒤로 버튼
Modifier.onClick {
    setValue(screen, 0)
}

1. 1
   문서 생성

   서버 snapshot의 task 수만큼 상세 child를 미리 기록합니다.

2. 2
   행 click

   Player가 screen ID에 index + 1을 기록합니다.

3. 3
   child 선택

   StateLayout이 바뀐 index에 해당하는 상세 child를 표시합니다. UI를 위에 덮는 방식이 아닙니다.

4. 4
   목록 복귀

   screen = 0으로 바꾸면 첫 번째 child인 목록을 다시 표시합니다.

이것은 Android Navigation인가요?

아닙니다. Activity, Fragment, Navigation Compose destination이나 back stack은 변하지 않습니다.

task.create가 API 요청으로 이어지는 전체 과정

서버가 문서에 기록하는 action

ActionButton(label = "+  새 작업 작성") {
    hostAction("task.create")
}

ActionButton(label = "삭제") {
    hostAction("task.delete.${task.id}")
}

hostAction 자체는 HTTP 요청을 보내지 않습니다. 문자열을 문서 action으로 기록할 뿐이며, Android host가 그 이름을 해석했기 때문에 결과적으로 API 호출이 일어납니다.

Android 앱이 business action으로 번역합니다

RemoteDocumentPlayer(
    document = document,
    documentWidth = 390,
    documentHeight = 720,
    onNamedAction = { name, value, _ ->
        viewModel.handleHostAction(name, value)
    },
)

documentWidth와 documentHeight는 alpha14 signature의 필수 인자입니다. RemoteDocumentPlayer 자체도 고정 source 기준 restricted이므로 안정 public player 계약으로 제시하지 않습니다.

왜 텍스트 입력은 Android가 담당하나요?

현재 POC에서 확인한 procedural component surface에는 일반 Android TextField처럼 IME로 자유 입력을 받는 component가 없습니다. 그래서 task.create를 받으면 Android가 native 입력 UI를 열고, 입력 완료 후 Repository가 서버에 저장합니다.

POC의 GET /document

get("/document") {
    call.respondBytes(
        bytes = buildChecklistDocument(taskStore.snapshot()),
        contentType = ContentType.Application.OctetStream,
    )
}

1. 1
   taskStore.snapshot()

   현재 서버 작업 데이터를 읽습니다.

2. 2
   buildChecklistDocument(...)

   데이터에 맞는 Remote Compose 문서 바이트를 만듭니다.

3. 3
   respondBytes(...)

   Ktor가 그 바이트를 HTTP 응답으로 보냅니다.

4. 4
   Android player

   앱이 받은 바이트를 검증하고 화면으로 그립니다.

누가 무엇을 소유하나요?

서버가 바꾸면 앱에 무엇이 보일까요?

작업을 추가한 뒤 새 문서를 요청하면 서버는 새로운 목록으로 문서를 다시 만듭니다. 앱은 새 바이트를 받아 player에 전달하고, 사용자는 갱신된 목록을 봅니다. 이 POC의 “자동 동기화”는 이 재요청 과정을 뜻합니다.

한 번에 다시 보기

이 코드랩에서 사용한 것의 지위

다른 제작 방식은 별도 심화 과제입니다

Android 또는 Android 기반 CI에서 @RemoteComposable content를 capture하는 public Compose frontend도 존재합니다. 그 경로에서 RemoteText, .rs, .rb, valueChange가 등장합니다. 하지만 서버에서 RcScope.Text(String)를 직접 사용하는 이번 경로에는 필요하지 않습니다.

실제 앱 도입 전에 확인할 것