같은 곡을 두 번 연주한 뒤 첫 번째 기록을 열었다고 해봅시다. 화면에 곡명이 맞게 표시돼도 점수와 틀린 위치가 두 번째 연주의 것이라면, 사용자는 첫 번째 연주에서 무엇을 고쳐야 할지 판단할 수 없습니다. 반대로 악기 이름만 늦게 도착한 경우라면, 점수와 악보부터 확인할 수 있습니다.

얼쑤의 이전 연주 결과 화면은 이 두 상황을 서로 다른 상태로 처리합니다. 선택한 기록의 결과인지 먼저 확인한 뒤, 점수를 읽는 데 필요한 데이터와 나중에 도착해도 되는 데이터를 나눴습니다.

같은 곡을 연주한 기록도 구별한다

화면 경로에 들어 있는 기록 ID를 기준으로 평가를 조회합니다. 응답을 화면에 넣기 전에 세 가지를 비교합니다.

  1. 응답의 평가 ID가 사용자가 선택한 기록 ID와 일치하는지 확인합니다.
  2. 평가가 가리키는 곡 ID와 불러온 악보의 곡 ID가 일치하는지 확인합니다.
  3. 평가에 악보 판본이 있으면 불러온 악보의 판본과 비교합니다.

판본이 중요한 이유는 틀린 음을 악보 위에 표시하기 때문입니다. 같은 곡이라도 판본이 다르면 음의 순서나 위치가 달라질 수 있습니다. 결과가 누락되거나 식별 정보가 어긋나면 결과를 찾을 수 없는 상태로 표시합니다. 조회 도중 예외가 발생하면 실패 상태와 재시도 동작을 제공합니다.

점수를 먼저 보여주고 부가 정보를 채운다

식별이 끝난 평가와 악보는 바로 화면 상태에 넣습니다. 추천 연습 구간, 악기 이름, 기록의 읽음 처리는 그 뒤에 각각 자식 코루틴에서 수행합니다. 추천을 가져오지 못하면 추천 구간이 비고, 악기 목록을 가져오지 못하면 제목에는 곡명만 남습니다. 그동안 점수와 틀린 위치는 계속 볼 수 있습니다.

보조 조회에서 일반 예외는 해당 정보의 누락으로 처리합니다. CancellationException은 다시 던져 계정 범위의 작업이 취소될 때 보조 조회도 함께 끝나도록 했습니다. 실패한 요청 하나의 영향은 해당 정보에 머무르고, 화면을 소유하는 쪽의 취소는 그대로 전파됩니다.

두 기록을 번갈아 열어 보기

회귀 테스트에는 같은 곡의 두 연주를 각각 73점과 91점으로 두었습니다. 기록을 바꿀 때 점수와 오류 위치가 선택한 ID를 따라가는지 검사했습니다. 곡이 같아도 다른 세션을 반환하는 경우와 곡·판본이 어긋나는 경우에는 평가를 표시하지 않는지 확인했습니다. 추천과 악기명 조회를 실패시켰을 때는 73점 결과가 남고 두 보조 항목만 비는지도 검사했습니다. 최종 Android 호스트 테스트에서 이 로딩 테스트 11건이 통과했습니다.

로컬 웹에서는 고정 데이터를 연결해 390×844 화면에서 두 결과를 전환했습니다. 73점·단소에서 91점·소금으로 바뀔 때 점수, 오류 수, 선택한 정간의 설명이 함께 바뀌는 것을 확인했습니다. 실제 API에서 두 기록을 불러오는 기기별 전체 흐름은 별도의 검증 범위로 남았습니다.

화면을 여러 API로 구성할 때는 사용자가 지금 확인하러 온 정보부터 정할 수 있습니다. 이전 연주 결과에서는 어떤 연주의 평가인지 확신할 수 있을 때 점수를 보여주고, 그 뒤에 부가 정보를 채웠습니다.