비터치 수신기 앱
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
수신기는 콘텐츠를 재생하고 상태를 사용자에게 반영합니다.
수신자는 발신자 앱의 작업에 즉시 응답해야 합니다 . 예를 들어 콘텐츠가 수신기에서 일시중지되면 일시중지 아이콘이 표시되고 사용자가 전송자 앱에서 재생을 누르면 수신기에서 콘텐츠 재생이 시작되고 일시중지 아이콘이 삭제됩니다.
수신기 UI 피드백의 예:
- 재생 중
- 일시중지됨
- 재생 위치 / 탐색
- 버퍼링
필수
대부분의 UI 요소를 화면 하단 1/4 내에 배치하고 다른 UX와 일관성을 유지합니다.
B 요소를 대화형 컨트롤로 표시하지 마세요. 예를 들어 수신자 UI에서 전송자 UI를 재현하지 마세요.
권장사항
- 전환 (페이드), 투명도, 미묘한 차이를 사용하여 시각 효과를 부드럽게 만듭니다.
- 사용자는 최대한 많은 콘텐츠를 보고 싶어 한다는 점을 고려하세요. 사용자는 콘텐츠를 자세히 살펴보기 위해 일시중지하는 경우가 많으므로 가능한 경우 불필요한 UI를 페이드 아웃하세요.
Android
발신자 UI
수신기 UI
iOS
발신자 UI
수신기 UI
Chrome
발신자 UI
수신기 UI
수신기가 전송기에 연결되어 있지만 전송하지 않는 경우 수신기에 유휴 화면이 표시됩니다.
필수
A 로드된 수신기 앱을 식별합니다.
권장사항
- 유휴 화면을 사용하여 발신자 앱의 콘텐츠 또는 기능을 홍보합니다.
- 30~60초마다 콘텐츠를 변경하여 더 많은 콘텐츠를 표시하고 화면 번인을 방지합니다.
- 5분 동안 유휴 상태이면 수신자 앱에서 연결을 해제하고 실행을 중지합니다.
중지되면 수신기 홈 화면이 표시되어 화면 번짐을 방지하는 데 도움이 됩니다.
Android
전송 대화상자, 연결되었지만 전송되지 않음
수신기 앱 로드됨 / 유휴 상태
iOS
전송 대화상자, 연결되었지만 전송되지 않음
수신기 앱 로드됨 / 유휴 상태
사용자가 리시버에 연결하면 리시버 앱이 먼저 로드되어야 앱 유휴 상태를 표시하거나 콘텐츠 재생을 시작할 수 있습니다.
필수
A 앱 로고를 표시하여 로드 중인 수신자 앱을 식별합니다.
B 애니메이션 로드 스피너를 표시하여 수신자 앱이 로드 중임을 식별합니다.
Android
발신자 연결 중
수신기 앱 로드
iOS
발신자 연결 중
수신기 앱 로드
Chrome
발신자 연결 중
수신기 앱 로드
수신자 앱이 로드되면 콘텐츠가 수신자에게 스트리밍될 수 있습니다.
필수
A 콘텐츠 제목 또는 아트워크를 표시하여 로드되는 콘텐츠를 식별합니다.
B 애니메이션 로드 스피너를 표시하여 콘텐츠가 로드 중임을 식별합니다.
권장사항
일시중지된 콘텐츠를 재개할 때 시청자가 전송자에서 수신자로 전환되는 동안 놓치는 부분이 없도록 재생을 5~10초 되감습니다.
Android
발신자 콘텐츠 로드
리시버 콘텐츠 로드
iOS
발신자 콘텐츠 로드
리시버 콘텐츠 로드
Chrome
발신자 콘텐츠 로드
리시버 콘텐츠 로드
필수
A 콘텐츠가 시작될 때 재생 중인 항목 식별
B 위치가 조정될 때 재생 위치 식별
C 재생 위치가 변경되었지만 아직 재생되지 않은 경우 수신기가 콘텐츠를 탐색하고 있음을 식별
Android
발신자가 재생 위치 조정
수신기 콘텐츠 탐색
iOS
발신자가 재생 위치 조정
수신기 콘텐츠 탐색
Chrome
발신자가 재생 위치 조정
수신기 콘텐츠 탐색
필수
A 일시중지된 아이콘과 재생 위치를 표시하여 콘텐츠가 일시중지되었음을 식별합니다.
B 콘텐츠 제목 또는 아트를 표시하여 일시중지된 콘텐츠를 식별합니다.
C 앱 로고를 표시하여 로드된 수신자 앱을 식별합니다.
권장사항
- 사용자는 콘텐츠를 자세히 살펴보기 위해 일시중지하는 경우가 많으므로 일시중지 아이콘을 표시하여 몇 초 동안 일시중지되면 불필요한 UI가 사라지도록 합니다.
- 수신기 앱은 사용자가 재생을 시작하도록 명시적으로 요청하지 않는 한(예: 다시 시작, 대기열의 항목 건너뛰기) 콘텐츠 재생을 계속해서는 안 됩니다.
- 20분 동안 유휴 상태인 경우 수신기 앱에서 연결을 해제하고 실행을 중지합니다.
중지되면 수신기 홈 화면이 표시되어 화면 번짐을 방지하는 데 도움이 됩니다. 사용자가 나중에 해당 지점에서 재생을 재개할 수 있도록 일시중지된 위치를 저장합니다.
Android
발신자가 일시중지함
수신기 콘텐츠가 일시중지됨
발신자가 일시중지함
5초 후 수신기 일시중지
iOS
발신자가 일시중지함
수신기 콘텐츠가 일시중지됨
발신자가 일시중지함
5초 후 수신기 일시중지
Chrome
발신자가 일시중지함
수신기 콘텐츠가 일시중지됨
발신자가 일시중지함
5초 후 수신기 일시중지
수신기에서 버퍼링은 네트워크 지연 시간 또는 기타 요인으로 인해 재생이 지연될 때 발생합니다.
필수
몇 초 후에 버퍼링 스피너를 표시하여 수신기가 버퍼링 중임을 식별합니다. 버퍼링을 나타내기 위해 몇 초간 기다리면 네트워크 상태가 좋지 않을 때 버퍼링 스피너가 너무 자주 표시되지 않습니다.
권장사항
5초 후에도 버퍼링이 계속되면 버퍼링되는 콘텐츠를 확인합니다.
Android
발신자가 수신기 버퍼링을 나타냄
수신기 콘텐츠 버퍼링
iOS
발신자가 수신기 버퍼링을 나타냄
수신기 콘텐츠 버퍼링
Chrome
발신자가 수신기 버퍼링을 나타냄
수신기 콘텐츠 버퍼링
재생이 중지되거나 시간이 초과되면 수신기 UI는 전송자 앱에서 사용할 수 있는 다른 콘텐츠나 기능을 홍보해야 합니다.
필수
앱 로고를 표시하여 로드된 수신기 앱 또는 유휴 상태인 수신기 앱을 식별합니다.
권장사항
- 재생 후 유휴 화면을 사용하여 방금 전송된 콘텐츠를 기반으로 발신자 앱의 콘텐츠 또는 기능을 추천합니다.
- 화면 번짐을 방지하려면 유휴 화면 콘텐츠를 30~60초마다 변경하세요.
- 5분 동안 유휴 상태이면 수신자 앱에서 연결을 해제하고 실행을 중지합니다.
중지되면 수신기 홈 화면이 표시되어 화면 번짐을 방지하는 데 도움이 됩니다.
Android
전송자 앱 유휴 상태
수신기 앱 유휴 상태
발신자가 연결을 끊음
홈 화면 전송
iOS
전송자 앱 유휴 상태
수신기 앱 유휴 상태
발신자가 연결을 끊음
홈 화면 전송
Chrome
전송자 앱 유휴 상태
수신기 앱 유휴 상태
발신자가 연결을 끊음
홈 화면 전송
이 설계 가이드에 사용된 이미지는 Blender Foundation에서 제공하며 저작권 또는 크리에이티브 커먼즈 라이선스에 따라 공유됩니다.
- Elephant's Dream: (c) copyright 2006, Blender Foundation / Netherlands Media Art Institute /
www.elephantsdream.org
- Sintel: (c) copyright Blender Foundation | www.sintel.org
- Tears of Steel: (CC) Blender Foundation | mango.blender.org
- Big Buck Bunny: (c) copyright 2008, Blender Foundation / www.bigbuckbunny.org
달리 명시되지 않는 한 이 페이지의 콘텐츠에는 Creative Commons Attribution 4.0 라이선스에 따라 라이선스가 부여되며, 코드 샘플에는 Apache 2.0 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 Google Developers 사이트 정책을 참조하세요. 자바는 Oracle 및/또는 Oracle 계열사의 등록 상표입니다.
최종 업데이트: 2025-07-26(UTC)
[null,null,["최종 업데이트: 2025-07-26(UTC)"],[[["\u003cp\u003eReceiver UIs should be minimally intrusive, displaying playback status and content information primarily in the lower quarter of the screen, without replicating sender app controls.\u003c/p\u003e\n"],["\u003cp\u003eWhen the receiver is idle or loading, clear app identification and loading indicators are crucial for a smooth user experience.\u003c/p\u003e\n"],["\u003cp\u003eContent loading and playback states should be clearly communicated to the user, with provisions for buffering and seeking.\u003c/p\u003e\n"],["\u003cp\u003eThe receiver should transition to an idle state when paused or playback is complete, displaying app branding and potentially promoting content to avoid screen burn-in.\u003c/p\u003e\n"],["\u003cp\u003eThroughout all states, visual feedback such as icons, spinners, and content metadata contribute to an intuitive and responsive user interface.\u003c/p\u003e\n"]]],["The receiver displays content and mirrors its state based on sender actions. Key actions include playing, pausing, seeking, and buffering, each visually represented on the receiver. When idle, the receiver shows the app logo and may promote content. When the app is loading or content is loading, it also displays its logo along with a loading spinner. When the receiver stops casting, it reverts to an idle state promoting other content or features.\n"],null,["# Non-Touch Receiver App\n\nThe receiver plays content and reflects its state to the user.\nThe receiver must respond immediately to actions in the sender app . For example, when content is\npaused on the receiver, it displays a pause icon and when the user presses play on the sender app,\nthe receiver starts playing the content and removes the pause icon.\n\nExamples of receiver UI feedback:\n\n- Playing\n- Paused\n- Playback position / seeking\n- Buffering\n\n### [Receiver UI](#receiver-ui-elements)\n\n\n**Required**\n\n\nA Place most UI elements within the lower 1/4 of the screen\nand keep it consistent with your other UX's.\n\n\nB Do not present elements as interactive controls. For\nexample, do not reproduce the sender UI on the receiver UI.\n\n\n**Best practices**\n\n- Use transition (fade), transparency, and nuance to soften the visual effect.\n- Consider the fact that users want to see as much of the content as possible. Users will often pause content to examine it, so fade away unnecessary UI when possible.\n\n### Android\n\nSender UI \nReceiver UI \n\n### iOS\n\nSender UI \nReceiver UI \n\n### Chrome\n\nSender UI \nReceiver UI \n\n### [Receiver app idle](#receiver-ui-idle)\n\nAn idle screen is displayed on the receiver, when the receiver is connected to a sender but not\ncasting.\n\n\n**Required**\n\n\nA Identify which receiver app is loaded\n\n**Best practices**\n\n- Use the idle screen to promote content or features from the sender app.\n- Change the content every 30-60 seconds to display more and prevent screen burn.\n- Disconnect from the receiver app and stop it from running if idle for 5 minutes. When stopped, the receiver home screen appears and will help prevent screen burn.\n\n### Android\n\nCast dialog, connected but not casting \nReceiver app loaded / idle \n\n### iOS\n\nCast dialog, connected but not casting \nReceiver app loaded / idle \n\n### [Receiver app loading](#receiver-player-loading)\n\nWhen a user connects to a receiver, the receiver app must first load before it can display the\napp idle state or begin playing content.\n\n\n**Required**\n\n\nA Identify which receiver app is loading by displaying the\napp logo\n\n\nB Identify that the receiver app is loading by displaying\nthe animated loading spinner \n\n### Android\n\nSender connecting \nReceiver app loading \n\n### iOS\n\nSender connecting \nReceiver app loading \n\n### Chrome\n\nSender connecting \nReceiver app loading \n\n### [Receiver content loading](#receiver-content-loading)\n\nOnce the receiver app has loaded, content can begin streaming to the receiver.\n\n\n**Required**\n\n\nA Identify what content is being loaded by displaying the\ncontent title or artwork\n\n\nB Identify that content is loading by displaying an\nanimated loading spinner\n\n\n**Best practices**\n\n\nWhen resuming paused content, rewind playback 5-10 seconds so the viewer doesn't miss anything\nduring the transition from sender to receiver. \n\n### Android\n\nSender content loading \nReceiver content loading \n\n### iOS\n\nSender content loading \nReceiver content loading \n\n### Chrome\n\nSender content loading \nReceiver content loading \n\n### [Receiver playback](#receiver-ui-seek)\n\n\n**Required**\n\n\nA Identify what is playing when content starts\n\n\nB Identify playback position when position is adjusted\n\n\nC Identify that the receiver is seeking content when the\nplayback position is changed, but not yet playing \n\n### Android\n\nSender adjusting play position \nReceiver content seeking \n\n### iOS\n\nSender adjusting play position \nReceiver content seeking \n\n### Chrome\n\nSender adjusting play position \nReceiver content seeking \n\n### [Receiver paused](#receiver-ui-pause)\n\n\n**Required**\n\n\nA Identify that content is paused by displaying a paused\nicon and playback position\n\n\nB Identify what content is paused by displaying content\ntitle or artwork\n\n\nC Identify which receiver app is loaded by displaying an\napp logo\n\n**Best practices**\n\n- Users will often pause content to examine it, so have unnecessary UI fade away when paused for a few seconds by displaying a pause icon.\n- The receiver app should not continue content playback unless there is an explicit request from the user to begin playback such as resume, or skipping an item on the queue.\n- Disconnect from the receiver app and stop it from running if idle for 20 minutes. When stopped, the receiver home screen appears and will help prevent screen burn. Store the paused location so that the user can resume playback from that point at a later time.\n\n### Android\n\nSender paused \nReceiver content paused \nSender paused \nReceiver paused, after 5 seconds \n\n### iOS\n\nSender paused \nReceiver content paused \nSender paused \nReceiver paused, after 5 seconds \n\n### Chrome\n\nSender paused \nReceiver content paused \nSender paused \nReceiver paused, after 5 seconds \n\n### [Receiver buffering](#receiver-ui-buffer)\n\nBuffering on the receiver happens when network latency or other factors cause a delay in playback.\n\n\n**Required**\n\n\nA Identify that the receiver is buffering after a few\nseconds by displaying a buffering spinner. Waiting a few seconds to indicate buffering will\nprevent the buffering spinner from appearing too frequently under bad network conditions\n\n\n**Best practices**\n\n\nIdentify what content is buffering if buffering continues after 5 seconds. \n\n### Android\n\nSender indicates receiver buffering \nReceiver content buffering \n\n### iOS\n\nSender indicates receiver buffering \nReceiver content buffering \n\n### Chrome\n\nSender indicates receiver buffering \nReceiver content buffering \n\n### [Receiver stops cast](#receiver-ui-complete)\n\nWhen playback stops or times out, the receiver UI should promote other content or features\navailable in the sender app.\n\n\n**Required**\n\n\nA Identify which receiver app is loaded or idle by\ndisplaying an app logo\n\n**Best practices**\n\n- Use the idle screen after playback to recommend content or features from the sender app, based on what was just cast\n- Change the idle screen content every 30-60 seconds to prevent screen burn\n- Disconnect from the receiver app and stop it from running if idle for 5 minutes. When stopped, the receiver home screen appears and will help prevent screen burn.\n\n### Android\n\nSender app idle \nReceiver app idle \nSender disconnected \nCast home screen \n\n### iOS\n\nSender app idle \nReceiver app idle \nSender disconnected \nCast home screen \n\n### Chrome\n\nSender app idle \nReceiver app idle \nSender disconnected \nCast home screen \n\n**Images used in this design guide**\nare courtesy of the Blender Foundation, shared under copyright or Creative Commons license.\n\n- Elephant's Dream: (c) copyright 2006, Blender Foundation / Netherlands Media Art Institute / www.elephantsdream.org\n- Sintel: (c) copyright Blender Foundation \\| www.sintel.org\n- Tears of Steel: (CC) Blender Foundation \\| mango.blender.org\n- Big Buck Bunny: (c) copyright 2008, Blender Foundation / www.bigbuckbunny.org"]]
