타일에서 위젯으로 이전

타일과 위젯은 모두 원격 시스템 화면에 콘텐츠를 표시하지만 빌드하려면 서로 다른 접근 방식이 필요합니다. 기존 타일을 위젯으로 이전하면 엄격한 레이아웃 생성에서 동적 선언형 UI로 전환하여 새로운 기능과 간소화된 개발 모델을 사용할 수 있습니다.

구현 전략 선택

기존 타일을 유지하는 앱을 이전하는 경우 앱에서 시스템에 콘텐츠를 제공하는 방법을 결정해야 합니다. 새 위젯은 단일 위젯 서비스를 사용해야 하지만 기존 타일이 있는 앱은 두 서비스를 모두 유지하거나 단일 위젯 서비스로 통합해야 합니다.

권장사항: 이중 서비스 (타일 + 위젯)

기존 타일이 있는 모든 앱에는 타일과 위젯을 모두 유지하는 것이 좋습니다. 두 가지 고유한 서비스를 제공하면 다양한 기기에서 최상의 사용자 환경을 제공할 수 있습니다.

이중 서비스 설정의 시스템 동작:

OS / 기기 기능 결과 환경
Wear OS 3 타일 이 사용됩니다.
Wear OS 4, 5, 6 타일 이 사용됩니다.
Wear OS 7 (부분 높이 지원 없음, 예: Pixel Watch) 타일 이 사용됩니다.
Wear OS 7 (부분 높이 지원, 예: Galaxy Watch) 위젯 이 사용됩니다.

대안: 단일 서비스 (위젯만)

단일 서비스가 두 프로토콜을 모두 처리합니다. 이 접근 방식은 구현 속도가 더 빠르지만 Wear OS의 이전 버전을 실행하는 기기에서 위젯을 타일로 '조정'하기 위해 호환성 모드를 사용합니다.

이 접근 방식을 선택하는 경우 다음을 실행합니다.

  1. 두 인텐트 필터 모두 지정: 서비스에 androidx.wear.tiles.action.BIND_TILE_PROVIDER 및 androidx.glance.wear.action.BIND_WIDGET_PROVIDER의 인텐트 필터가 모두 포함되어야 합니다. 이렇게 하면 위젯이 Wear 4, 5, 6, 7 (필요한 경우)의 타일 화면에 표시됩니다.
  2. 기존 서비스 이름 유지 (원활한 업그레이드): 활성 타일을 교체하는 경우 동일한 서비스 클래스 이름을 유지하면 캐러셀에 타일이 있는 사용자가 새 위젯으로 자동 업데이트되는 것을 확인할 수 있습니다. Wear OS 7은 위젯 구성 XML의 group 속성을 사용하여 여러 구성요소를 논리적으로 연결하지만 Wear OS 7 미만의 버전은 서비스 이름을 사용하여 '동일한' 구성요소로 식별합니다. 새 서비스 이름을 사용하려는 경우 앱은 계속 완벽하게 작동하지만 Wear OS 버전 6 이하를 실행하는 기기의 사용자는 캐러셀에 위젯을 수동으로 다시 추가해야 합니다.

단일 서비스 설정의 시스템 동작:

OS / 기기 기능 결과 환경
Wear OS 3 지원되지 않음
Wear OS 4, 5, 6 위젯이 전체 화면 타일로 표시됨
Wear OS 7 (부분 높이 지원 없음) 위젯이 타일로 변환됨
Wear OS 7 (부분 높이 지원) 위젯 이 사용됩니다.

*렌더러 1.6 이상이 필요합니다.

UI 번역 관련 팁

ProtoLayout (타일)에서 Remote Compose (위젯)로 UI를 번역할 때 정신 모델은 명령형 레이아웃 빌더에서 UI 업데이트가 리컴포지션을 통해 처리되는 상태 기반 Compose 기반 아키텍처로 전환됩니다. 다음 원칙을 염두에 두세요.

  • 선언형 UI 채택: 명령형 ProtoLayout 빌더 (LayoutElementBuilders)를 선언형 Remote Compose 동등 항목 (예: RemoteText, RemoteColumn, RemoteBox)으로 바꿉니다.
  • 핵심 콘텐츠 (mainSlot)에 집중: 부분 높이 위젯 (예: SMALL 및 LARGE 컨테이너 유형)은 집중된 한눈에 볼 수 있는 화면을 제공합니다. 밀도가 높은 전체 화면 타일 레이아웃을 일대일로 포팅하는 대신 디자인을 간소화하여 기본 콘텐츠 영역 내에서 기본 정보를 강조합니다.
  • 가장자리 정렬 작업 재설계: 타일 아키텍처에서 화면에 밀착되는 구성요소는 전용 bottomSlot에 고정되었습니다.EdgeButton 부분 높이 위젯은 세로로 스크롤되는 화면에 직접 통합되므로 이 고정된 bottomSlot 패러다임은 더 이상 존재하지 않습니다. 가장자리 정렬 버튼은 매우 눈에 띄는 기본 작업으로 자주 사용되므로 이전하려면 직접 구성요소를 교체하는 대신 의도적인 UI 재설계가 필요합니다. 기본 작업의 대체 UX 전략을 평가합니다.
    • 인라인 작업: 인라인 RemoteButton을(를) mainSlot 레이아웃 내에 직접 통합합니다.
    • 컨테이너 탭: 전체 위젯 컨테이너를 탭할 수 있도록 하여 상호작용을 통합합니다. PendingIntentAction
    • 콘텐츠 피벗: 위젯의 초점을 재평가합니다. 전용 작업 슬롯이 없는 경우 위젯 화면에서 특정 작업을 격리하는 대신 더 풍부한 한눈에 볼 수 있는 데이터를 표시하고 한 번의 탭으로 전체 애플리케이션을 여는 것을 고려합니다.
  • 이벤트 처리 이전 (작업 대 람다): 타일은 UI를 새로고침하기 위해 전체 서비스 콜백을 트리거하는 상호작용(예: LoadAction)에 의존합니다. Wear 위젯은 클라이언트 측에서 실행됩니다. 표준 Compose 람다는 원격으로 실행할 수 없습니다. 대신 직렬화 가능한 선언형 작업 (예: ValueChange 또는 PendingIntentAction)을 제공합니다. 이를 선언형 상태 (예: rememberMutableRemoteInt)와 결합하여 앱 왕복 없이 즉각적인 UI 업데이트를 지원합니다.
  • 크기 및 유형 조정: 레이아웃 크기를 이전할 때는 표준 Dp보다 RemoteDp (예: 10.rdp)를 사용하는 지연된 레이아웃 해결을 선호합니다. 이렇게 하면 시스템 렌더러가 표시 시간에 픽셀 값을 올바르게 계산합니다. 마찬가지로 Remote Compose 확장 함수(.rc는 Color, .rs는 String, .rdp는 Dp)를 사용하여 표준 Kotlin 및 Remote Compose 유형을 원활하게 변환합니다.
  • 샘플 코드 검토: 레이아웃을 빌드하고, 시맨틱 타이포그래피를 적용하고, Remote Compose에서 상태를 관리하는 방법을 보여주는 포괄적인 예를 보려면 Wear OS 샘플 저장소에서 제공되는 공식 샘플 코드를 살펴보세요.