Error Codes and Tracking State (v3.3.2)

In most cases no code changes are required to upgrade from 3.3.1 to 3.3.2. The error cases your app receives are unchanged, and new features are only needed when you want them. Please check only 5. Where the error case changes and 6. Where the behavior changes below.

1. Tracking keeps going in more situations

If the audio engine fails while not tracking, it is audioInitializationFailed as before.

2. 5-digit error codes (Beta) cleaned up

The numbers of the 5-digit error code (error.errorCode), provided as Beta since 3.2.0, are now organized by cause, and you can branch on them by name. Cleaning up the cases and the official switch to 5-digit codes are planned for v4.0.0.

Branching by code name

func didFail(error: Asleep.AsleepError) {
    switch error.errorCode {
    case .createConflict:           // 22409 the previous session is not closed yet
        // ...
    case .commonExpired:            // 11403 plan expired · too many requests
        // ...
    case .uploadTrackingTerminated: // 23499 tracking ended due to an upload error
        // ...
    default:
        print(error.errorCode.code, error.errorCode.message ?? "")
    }
}

• Code that branches on cases (case .httpStatus, case .startTrackingNetworkFail, etc.) keeps working as before.
• startTrackingNetworkFail and stopTrackingNetworkFail now show a deprecation warning. Only the warning is new; the behavior is the same, and they are delivered as before until v4.0.0.
• For the full code table, see Error Codes.

errorCode.message

If the server sent a message, it is included here. It is for checking the cause (logging) and may change without notice, so branch your app logic on the number (code) or the code name.

== compares only the number

Because message holds the server message and can differ each time, == on AsleepErrorCode compares only code.

// 3.3.2: true regardless of the server message
[.audioSilenced, .audioUnsilenced, .uploadFailed].contains(error.errorCode)

3. Changed codes

In the situations below, the error number your app receives (errorCode.code) differs from 3.3.1. If you branch on this number or collect statistics with it, please check.

4. Overlapping calls (tracking state)

When another call overlaps while tracking is starting, in progress, or stopping, it is handled as below.

Asleep.isSleepTrackingAlive()

A function that tells whether tracking is in progress has been added.

if Asleep.isSleepTrackingAlive() {
    // starting · tracking · stopping
}

• Returns true while starting after startTracking(), while tracking, and while stopping after stopTracking().
• The state is kept only in memory. After the app is terminated and launched again, it is false.

5. Where the error case changes

In 3.3.x the error cases your app receives are not supposed to change, but the following do.

6. Where the behavior changes

• The analysis completion notification (didComplete) is decided by the function you called. Only a manager created with createSleepTrackingManager(config:delegate:recordingPath:recordingType:) checks for analysis completion and sends didComplete. If you pass an AsleepCompletableTrackingDelegate to createSleepTrackingManager(config:delegate:), 3.3.1 sent didComplete but 3.3.2 does not. didCreate(sessionId:) is called in both cases as before.
• createSleepTrackingManager during tracking returns the current manager instead of a new one. Apps that created a new manager per screen to change the delegate will receive callbacks on the delegate passed first while tracking.
• When the last chunk arrives after the session is closed right after tracking ends and is rejected, 3.3.1 sent uploadTrackingTerminated, but 3.3.2 does not. A rejection for the session being tracked is handled as before.

7. Good to know