Gestión de errores en el SDK de Kotlin Multiplatform

Esta página cubre la gestión de errores en el SDK de Adapty para Kotlin Multiplatform.

Conceptos básicos del manejo de errores

Los métodos del SDK de Adapty son funciones suspend que devuelven un AdaptyResult, que puede ser un éxito o un error. Gestiona ambos casos con onSuccess y onError:

Adapty.getProfile()
    .onSuccess { profile ->
        // Handle success
    }
    .onError { error ->
        // Handle error
        println("Adapty error: ${error.message}")
    }

AdaptyResult es una clase sellada, por lo que también puedes ramificar directamente sobre ella cuando necesites el resultado como valor:

when (val result = Adapty.getProfile()) {
    is AdaptyResult.Success -> {
        val profile = result.value
        // Handle success
    }
    is AdaptyResult.Error -> {
        val error = result.error
        // Handle error
    }
}

Códigos de error comunes

AdaptyError.code es un valor enum de tipo AdaptyErrorCode, no un número; compáralo contra la constante del enum, no contra el código numérico. Los números que aparecen a continuación se muestran únicamente porque son los que suele mostrar una línea de log o un ticket de soporte.

Para ver la lista completa de códigos, consulta AdaptyErrorCode en la referencia de modelos del SDK.

Gestión de errores específicos

Errores de red

Adapty.getFlow("YOUR_PLACEMENT_ID")
    .onSuccess { flow ->
        // Use the flow
    }
    .onError { error ->
        when (error.code) {
            AdaptyErrorCode.NETWORK_FAILED -> {
                // Network error - show offline message
                showOfflineMessage()
            }
            else -> {
                showErrorMessage(error.message)
            }
        }
    }

Errores de compra

makePurchase reporta fallos y resultados por separado. Un AdaptyResult.Error significa que la llamada falló; un resultado exitoso devuelve un AdaptyPurchaseResult que indica si el usuario completó la compra, la canceló o la dejó pendiente:

Adapty.makePurchase(product)
    .onSuccess { purchaseResult ->
        when (purchaseResult) {
            is AdaptyPurchaseResult.Success -> showSuccessMessage()
            AdaptyPurchaseResult.UserCanceled -> {
                // The user dismissed the store sheet — not an error
            }
            AdaptyPurchaseResult.Pending -> {
                // Awaiting an out-of-band payment, such as a prepaid plan
                showPendingMessage()
            }
        }
    }
    .onError { error ->
        when (error.code) {
            AdaptyErrorCode.CANT_MAKE_PAYMENTS -> showPaymentNotAvailableMessage()
            AdaptyErrorCode.PRODUCT_NOT_FOUND -> showProductNotAvailableMessage()
            else -> showPurchaseErrorMessage(error.message)
        }
    }

Estrategias de recuperación ante errores

Reintentos ante errores de red

Dado que los métodos del SDK son funciones suspend, un bucle de reintentos es simplemente un bucle con delay entre intentos:

suspend fun getFlowWithRetry(placementId: String, maxRetries: Int = 3): AdaptyFlow? {
    repeat(maxRetries) { attempt ->
        when (val result = Adapty.getFlow(placementId)) {
            is AdaptyResult.Success -> return result.value
            is AdaptyResult.Error -> {
                if (result.error.code != AdaptyErrorCode.NETWORK_FAILED) {
                    showErrorMessage(result.error.message)
                    return null
                }
                delay(1000L * (attempt + 1))
            }
        }
    }
    return null
}

Usa datos en caché como respaldo

No necesitas gestionar la caché de los flows tú mismo. El SDK de Adapty los guarda en caché en el dispositivo y devuelve la copia en caché cuando falla la red, así que pasa una fetch policy en lugar de implementar tu propia caché:

Adapty.getFlow(
    placementId = "YOUR_PLACEMENT_ID",
    fetchPolicy = AdaptyPaywallFetchPolicy.ReturnCacheDataElseLoad
)
    .onSuccess { flow ->
        // Use the flow
    }
    .onError { error ->
        showErrorMessage(error.message)
    }

Con ReturnCacheDataElseLoad, los usuarios con una conexión inestable obtienen un flow más rápido, aunque es posible que no vean la versión más reciente. Si ni la red ni la caché producen un flow, el SDK recurre al archivo de respaldo que incluyes con la app.

Próximos pasos

• Solución para el error Code-1000 noProductIDsFound
• Solución para el error Code-1003 cantMakePayments
• Referencia completa de la API - Documentación completa del SDK