바로가기 권장사항

앱 바로가기를 디자인하고 만든다면 다음 가이드라인을 따르세요.

디자인 가이드라인 준수

앱 바로가기를 시스템 앱에 사용된 바로가기와 시각적으로 일관되도록 하려면 앱 바로가기 디자인 가이드라인을 따르세요.

개별 바로가기를 4개만 게시

현재 API는 정적 및 동적 바로가기를 합해 최대 15개까지 언제라도 앱에 지원하지만 런처에서 시각적 모양을 개선하도록 개별 바로가기를 4개만 게시하는 것이 좋습니다.

런처에 바로가기를 표시하는 것 외에도 Google 바로가기 통합 라이브러리를 사용하여 Google 어시스턴트와 같은 Google 표시 경로에 바로가기를 표시할 수 있습니다. 이 라이브러리는 개수 제한 없이 동적 바로가기의 푸시를 지원합니다. 이 라이브러리를 사용하여 많은 수의 바로가기를 푸시하는 경우 setRank() 메서드를 호출하여 지원되는 런처에 표시할 바로가기의 `순위`를 설정하는 것이 좋습니다.

바로가기 설명 길이 제한

런처에서 앱의 바로가기를 표시하는 메뉴 내 공간이 제한됩니다. 가능하다면 바로가기의 '짧은 설명' 길이를 10자로, '긴 설명' 길이를 25자로 제한합니다.

정적 바로가기의 라벨에 관한 자세한 내용은 속성 값 맞춤설정을 참조하세요. 동적 및 고정된 바로가기의 경우 setLongLabel()과 setShortLabel()에 관한 참조 문서를 읽어보세요.

바로가기 및 작업 사용 내역 유지

바로가기를 만들 때 사용자가 앱 내에서 동일한 작업을 직접 완수할 수 있는 다양한 방법을 고려합니다. 이러한 각 상황에서 reportShortcutUsed()를 호출하여 사용자가 바로가기를 표시하는 작업을 얼마나 자주 실행하는지 런처에서 정확한 기록을 유지하도록 합니다.

의미가 유지될 때만 바로가기 업데이트

동적 및 고정된 바로가기를 변경할 때는 그 의미가 유지된 바로가기의 정보를 변경할 때만 updateShortcuts()를 호출합니다. 의미가 유지되지 않은 경우에는 다시 만드는 바로가기 유형에 따라 다음 메서드 중 하나를 사용해야 합니다.

예를 들어 슈퍼마켓으로 이동하는 바로가기를 만든다면 슈퍼마켓 이름은 변경되었지만 위치가 그대로인 경우 바로가기를 업데이트하는 것이 적절할 수 있습니다. 그러나 사용자가 다른 슈퍼마켓 위치에서 쇼핑을 시작했다면 새로운 바로가기를 만드는 것이 더 좋을 수 있습니다.

앱을 실행할 때마다 동적 바로가기 확인

동적 바로가기는 사용자가 새로운 기기에 데이터를 복원할 때 유지되지 않습니다. 이러한 이유로 백업 및 복원의 코드 스니펫과 같이 앱을 실행할 때마다 getDynamicShortcuts()에서 반환한 객체 수를 확인하고 필요에 따라 동적 바로가기를 다시 게시하는 것이 좋습니다.