[Android] 0. Guía de migración

Versión 1.7.33

Guía de migración al nuevo repositorio de SDK

El repositorio del SDK se ha trasladado al repositorio oficial de Maven. Aquí hay una guía paso a paso sobre cómo actualizar su proyecto para usar el nuevo repositorio y la última versión del SDK.

Antes de la migración

Paso 1: agregar el repositorio Jitpack

Agregue el repositorio Jitpack a su build.gradle raíz al final de los repositorios:

allprojects {  
  repositories {    
    ...    
    maven { url 'https://jitpack.io' }  
  }
}

Paso 2: agregar dependencia

Agregue la dependencia al build.gradle de su aplicación para obtener la última versión del SDK:

dependencies {
  implementation 'org.bitbucket.consentmanager:android-consentmanager:1.5.+'
}

Después de la migración

Paso 1: eliminar el repositorio Jitpack

Elimine el repositorio Jitpack de su build.gradle raíz:

allprojects {  
  repositories {    
    ...    
    // Remove the following line 
    maven { url 'https://jitpack.io' }  
  }
}

Paso 2: agregar el repositorio oficial de Maven

Reemplace la dependencia anterior con la nueva dependencia del repositorio oficial de Maven:

dependencies {
  implementation 'net.consentmanager.sdk:android:1.7.33'
}

Ahora su proyecto está actualizado para utilizar el nuevo repositorio oficial de Maven y la última versión del SDK (1.7.33). Asegúrese de sincronizar su proyecto y actualizar cualquier otra configuración o código que pueda verse afectado por esta migración.

De 1.xx a 1.6.3

Es importante tener en cuenta que la actualización a una nueva versión de una aplicación puede no ser siempre un proceso fluido. En algunos casos, es posible que deba modificar su código o actualizar sus dependencias para asegurarse de que su aplicación funcione correctamente.

Cambios para verificar Consentlayer

En la versión anterior del SDK de CMP, la verificación de la capa de consentimiento se integró en la función del constructor principal. En la nueva versión de la aplicación, separamos el cheque en una nueva función llamada initialize(). Este cambio se ha realizado para mejorar la confiabilidad y la consistencia de la verificación de capa de consentimiento.

Para usar la función initialize(), puede llamar a createInstance() con los parámetros requeridos y agregar la función initialize() en el objeto devuelto:

createInstance(
    applicationContext,
    CMP_ID,
    CMP_DOMAIN,
    CMP_APP_NAME,
    LANG
).initialize(this)

En este ejemplo, llamamos a createInstance() para inicializar la capa de consentimiento. La función de inicialización solicitará la consentmanager y determina si se debe mostrar o no el consentidor.

Si anteriormente estaba usando la actualización automática para la capa de consentimiento en su aplicación, deberá modificar su código para usar la función initialize() en su lugar. Esto garantizará que la capa de consentimiento se verifique de manera consistente y confiable en la nueva versión de la aplicación. Sin initialize() solo se creará la instancia.

Si está utilizando un diseño personalizado, preste atención para pasar la instancia de actividad en la inicialización. Para asegurarse de que el fragmento se agregará correctamente a la actividad. 

Cambios en las devoluciones de llamada

En la versión anterior del SDK de CMP, teníamos diferentes devoluciones de llamada que eran confusas de usar. En la nueva versión, ahora hay cuatro funciones de devolución de llamada separadas que se pueden implementar. Esta función de devolución de llamada solo debe agregarse a la instancia una vez y estará disponible a través de todas las interacciones de API.

Las cuatro devoluciones de llamada se nombran así:

• onOpenCallback: Esta función se llama cuando la capa de consentimiento se abre con éxito.
• OnCloseCallback: Esta función se llama cuando se cierra la capa de consentimiento.
• OnCMPNotOpenedCallback: Esta función se llama cuando no se puede abrir la capa de consentimiento.
• OnErrorCallback: Esta función se llama cuando se produce un error al interactuar con la capa de consentimiento.

La OnErrorCallback se llamará a la función para todos los errores comunes, en lugar de las funciones de devolución de llamada de error separadas utilizadas en la versión anterior de la aplicación.

Para usar estas devoluciones de llamada, puede implementarlas en el constructor de consentlayer, así:

createInstance(
    applicationContext,
    CMP_ID,
    CMP_DOMAIN,
    CMP_APP_NAME,
    LANG,
    openListener = object : OnOpenCallback {
        override fun onWebViewOpened() {
            Log.d(TAG, "opened callback")
        }
    },
    closeListener = object : OnCloseCallback {
        override fun onWebViewClosed() {
            Log.d(TAG, "closed callback")
        }
    },
    cmpNotOpenedCallback = object : OnCMPNotOpenedCallback {
        override fun onCMPNotOpened() {
            Log.d(TAG, "cmp not opened")
        }
    },
    errorCallback = object : OnErrorCallback {
        override fun errorOccurred(message: String) {
            Log.d(TAG, "error occurred")
        }
    }

).

Nuevas funciones de la API

En la versión anterior del SDK de CMP, no se proporcionaban funciones para obtener información sobre los proveedores habilitados y deshabilitados del usuario, o para habilitar y deshabilitar las listas de propósitos y proveedores. En la nueva versión de la aplicación, hemos agregado varias funciones API nuevas que le permiten interactuar con el capataz de consentimiento de manera más profunda.

Las nuevas funciones de la API son:

• getAgreedVendors: esta función devuelve una cadena que contiene los ID de los proveedores que el usuario ha aceptado.
• getAgreedVendorList: esta función devuelve una lista de los ID de los proveedores que el usuario ha aceptado.
• getDisabledVendors: esta función devuelve una lista de los ID de los proveedores que el usuario ha deshabilitado.
• enableVendorList: Esta función activa los proveedores especificados.
• disableVendorList: Esta función desactiva los proveedores especificados.
• enablePurposeList: Esta función habilita los propósitos especificados y actualiza la lista de proveedores de forma predeterminada.
• disablePurposeList: esta función desactiva los propósitos especificados y actualiza la lista de proveedores de forma predeterminada.
• rejectAll: Esta función simula el rechazo de un usuario de todos los proveedores y propósitos. Requiere un OnConsentReceivedCallback función de devolución de llamada para manejar la asincronía de la API.
• acceptAll: Esta función simula la aceptación de un usuario de todos los proveedores y propósitos. Requiere un OnConsentReceivedCallback función de devolución de llamada para manejar la asincronía de la API.

La rejectAll y acceptAll Las funciones requieren proporcionar una función de devolución de llamada para manejar la asincronía de la API. Debe implementar cualquier lógica comercial que dependa de los resultados de estas funciones dentro de las funciones de devolución de llamada para asegurarse de que su aplicación se actualice correctamente.

Cambios en la función importConsent

En la versión anterior del CMP SDK, el importCMPData La función se usó para importar la cadena de consentimiento de cmp en las preferencias compartidas de la aplicación. En la nueva versión de la aplicación, esta función se ha actualizado. Esta función se sincronizará con la Consentmanager Backend para una mejor consistencia y menos errores.

Para garantizar la funcionalidad de la versión actualizada importCMPData función, se ha implementado una devolución de llamada. Esta devolución de llamada le notifica si la importación fue exitosa o no. Cualquier lógica comercial que dependa del resultado también debe implementarse en esta devolución de llamada.

La función actualizada tiene la siguiente firma:

Puede usar esta función para importar una cadena de consentimiento total generada por ConsentWebView en las preferencias compartidas de su dispositivo. Para llamar a la función, debe proporcionar los siguientes parámetros:

• context: El contexto de la aplicación
• cmpData: La cadena de consentimiento para importar, codificada en base64
• callback: una función de devolución de llamada para recibir el resultado de la operación de importación

Si la importación es exitosa, la función llamará al onImportResult método de la devolución de llamada con el success parámetro establecido en true y un mensaje indicando que la importación fue exitosa. Si la importación no tiene éxito, la función llamará al onImportResult método de la devolución de llamada con el success parámetro establecido en false y un mensaje que indica por qué la importación no tuvo éxito.

Cualquier lógica comercial que dependa del resultado de la operación de importación debe implementarse en la devolución de llamada para garantizar que su aplicación se actualice correctamente.

Cambios en el lenguaje de programación Kotlin

La migración al nuevo SDK de Kotlin requiere algunos cambios en la forma en que usas el SDK. La aplicación se refactorizó de una biblioteca de Java a una biblioteca de Kotlin y, como resultado, hay algunos cambios a tener en cuenta.

Para las aplicaciones Java, debe prestar atención a métodos estáticos y funciones sobrecargadas. En algunas partes del SDK, es posible que deba usar el Compañero objeto para acceder a métodos estáticos, y es posible que no sea posible instanciar la clase de administrador SDK de la misma manera que antes.

Hemos tratado de asegurarnos de que las diferencias para la migración sean mínimas, pero se recomienda que revise detenidamente la documentación y el código de muestra del SDK de Kotlin actualizado para comprender cualquier cambio en el uso. Además, revise su base de código existente y actualice cualquier llamada a métodos obsoletos o eliminados para evitar problemas durante el proceso de migración.

En general, la migración al nuevo SDK de Kotlin debería ser sencilla. Los cambios se han realizado para mejorar la funcionalidad y la coherencia del SDK. Sin embargo, es importante probar a fondo su base de código después de la migración para asegurarse de que todo funcione correctamente.

De 1.5.7 a 1.6.0

Actualice los ID de CMP a ID de código para el uso continuado del SDK

Estamos realizando algunos cambios en los ID de CMP que se utilizan para identificar nuestro CMP. Para asegurarse de que puede continuar usando nuestro SDK, será necesario actualizar el ID de CMP con la nueva ID de código que se puede encontrar en el área de administración para el código SDK.

¿Cómo se actualizan los ID de CMP?

Para actualizar las ID de CMP, deberá iniciar sesión en el área de administración para el Consentmanager y busque los nuevos ID de código (Obtener código -> Configuración para aplicaciones (Android/iOS)). Una vez que tenga el nuevo código de identificación, puedes reemplazar el ID de CMP en su código SDK con él

Le recomendamos que actualice su código SDK con el nuevo ID de código tan pronto como sea posible para garantizar que pueda continuar utilizando nuestro CMP sin interrupción.

Tenga en cuenta que el final de la vida útil de CMP-ID está programado para Diciembre 2023. Esto significa que el CMP-ID ya no será compatible después de esa fecha. Si tiene alguna pregunta o inquietud sobre esta migración, no dude en ponerse en contacto con nuestro equipo de soporte para obtener ayuda.

Actualización a las nuevas convenciones de nomenclatura de interfaz

Hicimos algunos cambios en nuestras convenciones de nomenclatura de interfaz para sincronizar la API de los SDK nativos y para una mejor comprensión del dominio. Como resultado de estos cambios, se modificaron algunas firmas de API y se introdujeron algunos métodos nuevos.

Estos son los cambios que se han realizado:

Actualización de devolución de llamada de error con tipos de error de CMP

Estamos introduciendo tipos de error de CMP en la devolución de llamada de error para proporcionar una mayor flexibilidad y permitir un comportamiento más distinguido según el tipo de error que se produzca. Con esta actualización, podrá manejar diferentes tipos de errores de manera más efectiva, lo que ayudará a garantizar que sus usuarios tengan la mejor experiencia posible.

¿Cuáles son los tipos de error de CMP?

Los tipos de error de CMP son un conjunto de tipos de error que se han introducido en la devolución de llamada de error. Estos tipos de error se utilizan para identificar el tipo de error que se ha producido y se pueden utilizar para desencadenar diferentes comportamientos según el tipo de error.

Los cuatro tipos de errores de CMP que se han introducido son:

• Error de red
• Error de tiempo de espera
• Error de escritura de lectura de consentimiento
• Error de capa de consentimiento

¿Cómo afectará este cambio a su código?

Para admitir los nuevos tipos de error de CMP, se actualizó la firma de la devolución de llamada de error. La nueva firma es:

fun errorOccurred(type: CmpError, message: String)

Deberá actualizar su código para usar la nueva firma y manejar los diferentes tipos de errores de manera adecuada.

¿Cómo se pueden manejar los diferentes tipos de errores?

Para manejar diferentes tipos de errores, puede usar el parámetro CmpError que se pasa a la devolución de llamada de error. Este parámetro contendrá el tipo de error que se ha producido, que puede utilizar para desencadenar diferentes comportamientos.

Por ejemplo, puede manejar un NetworkError de manera diferente a un ConsentLayerError. Puede utilizar el parámetro CmpError para determinar el tipo de error y desencadenar el comportamiento adecuado.

Un ejemplo para una implementación puede verse así: 

override fun errorOccurred(type: CmpError, message: String) {
                    when (type) {
                        CmpError.NetworkError -> {
                            Log.e(TAG, "Network error: $message")
                            // Handle network error
                        }
                        CmpError.TimeoutError -> {
                            Log.e(TAG, "Timeout error: $message")
                            // Handle timeout error
                        }
                        CmpError.ConsentReadWriteError -> {
                            Log.e(TAG, "Consent read/write error: $message")
                            // Handle consent read/write error
                        }
                        CmpError.ConsentLayerError -> {
                            Log.e(TAG, "Consentlayer error: $message")
                            // Handle consentlayer error
                        }
                        else -> {
                            Log.d(TAG, "default")
                        }
                    }
                }

Nueva devolución de llamada para identificar eventos de botón de usuario: 

Hemos agregado una nueva función de devolución de llamada, OnCmpButtonClickedCallback, que se puede usar para determinar las interacciones de los usuarios con la capa de consentimiento al capturar los eventos de clic de botón específicos. Esta devolución de llamada ayuda a los desarrolladores a obtener información sobre las preferencias del usuario y personalizar la experiencia del usuario en consecuencia.

Un ejemplo para una implementación puede verse así: 

            cmpButtonClickedCallback = object : OnCmpButtonClickedCallback {
                override fun onButtonClicked(event: CmpButtonEvent) {
                    when (event) {
                        CmpButtonEvent.RejectAll -> {
                            Log.d(TAG, "User clicked Reject all")
                        }
                        CmpButtonEvent.Save -> {
                            Log.d(TAG, "User saved custom settings")
                        }
                        CmpButtonEvent.AcceptAll -> {
                            Log.d(TAG, "User clicked accept all")
                        }
                        CmpButtonEvent.Close -> {
                            Log.d(TAG, "user closed layer without giving consent")
                        }
                        else -> {
                            Log.d(TAG, "no button event logic needed")
                        }
                    }
                }
            }