에러 번호와 측정 상태(v3.3.2)

3.3.1에서 3.3.2로 올릴 때 대부분 바꿔야 하는 코드는 없습니다. 앱이 받는 에러 케이스는 그대로이고, 새 기능은 필요할 때만 쓰면 됩니다. 아래 5. 에러 케이스가 바뀌는 곳과 6. 동작이 바뀌는 곳만 확인해 주세요.

1. 측정이 끊기지 않도록 개선

측정 중이 아닐 때 오디오 엔진이 실패하면 예전처럼 audioInitializationFailed 입니다.

2. 5자리 에러 코드(베타) 정리

3.2.0부터 베타로 제공하는 5자리 에러 코드(error.errorCode)의 번호를 원인별로 정리하고, 번호 이름으로 분기할 수 있게 했습니다. 케이스 정리와 정식 전환은 v4.0.0에 예정되어 있습니다.

번호 이름으로 분기하기

func didFail(error: Asleep.AsleepError) {
    switch error.errorCode {
    case .createConflict:          // 22409 이전 세션이 아직 닫히지 않음
        // ...
    case .commonExpired:           // 11403 플랜 만료 · 요청 과다
        // ...
    case .uploadTrackingTerminated: // 23499 업로드 오류로 측정 종료
        // ...
    default:
        print(error.errorCode.code, error.errorCode.message ?? "")
    }
}

• 기존처럼 케이스(case .httpStatus, case .startTrackingNetworkFail 등)로 분기하는 코드도 그대로 동작합니다.
• startTrackingNetworkFail, stopTrackingNetworkFail 에 deprecated 경고가 붙습니다. 경고만 나고 동작은 같으며, v4.0.0 전까지 그대로 전달됩니다.
• 전체 번호표는 Error Codes 를 참고하세요.

errorCode.message

서버가 보낸 문구가 있으면 그 문구가 들어갑니다. 원인 확인(로그)용이며 문구는 예고 없이 바뀔 수 있으니, 앱 로직은 번호(code) 또는 번호 이름으로 분기하세요.

== 는 번호만 비교합니다

message 가 서버 문구라 매번 다를 수 있어, AsleepErrorCode 의 == 는 code 만 비교합니다.

// 3.3.2: 서버 문구와 관계없이 true
[.audioSilenced, .audioUnsilenced, .uploadFailed].contains(error.errorCode)

3. 바뀐 번호

아래 상황에서는 앱이 받는 에러 번호(errorCode.code)가 3.3.1과 달라집니다. 이 숫자로 분기하거나 통계를 내고 있다면 확인해 주세요.

4. 겹친 호출 처리 (측정 상태)

측정이 시작되는 중, 진행 중, 끝나는 중에 다른 호출이 겹치면 아래처럼 처리합니다.

Asleep.isSleepTrackingAlive()

측정이 진행 중인지 알려 주는 함수가 추가되었습니다.

if Asleep.isSleepTrackingAlive() {
    // 측정 시작 중 · 측정 중 · 종료 중
}

• startTracking() 뒤 시작 중이거나, 측정 중이거나, stopTracking() 뒤 종료 처리 중이면 true 입니다.
• 상태는 메모리에만 있습니다. 앱이 종료되었다가 다시 실행되면 false 입니다.

5. 에러 케이스가 바뀌는 곳

3.3.x 는 앱이 받는 에러 케이스를 바꾸지 않는 것이 원칙이지만, 아래는 바뀝니다.

6. 동작이 바뀌는 곳

• 분석 완료 알림(didComplete)은 부른 함수로 정해집니다. createSleepTrackingManager(config:delegate:recordingPath:recordingType:) 로 만든 매니저만 분석 완료를 확인하고 didComplete 를 보냅니다. createSleepTrackingManager(config:delegate:) 에 AsleepCompletableTrackingDelegate 를 넘긴 경우, 3.3.1 은 didComplete 를 보냈지만 3.3.2 는 보내지 않습니다. didCreate(sessionId:) 는 두 경우 모두 그대로 호출됩니다.
• 측정 중 createSleepTrackingManager 는 새 매니저가 아니라 지금 매니저를 돌려줍니다. 화면마다 매니저를 새로 만들어 delegate 를 바꾸던 앱은, 측정 중에는 처음 넘긴 delegate 로 콜백이 갑니다.
• 측정 종료 직후 마지막 조각 이 세션 종료보다 늦게 도착해 거절되면, 3.3.1 은 uploadTrackingTerminated 를 보냈지만 3.3.2 는 보내지 않습니다. 측정 중인 세션의 거절은 예전과 같습니다.

7. 알아 두면 좋은 것