Notre univers
Contenu

[iOS] 0. Guide de migration

1.99.2
Nouveau CmpConfig 
        let cmpConfig : CmpConfig = CmpConfig.shared.setup(withId: config.appId, domain: config.domain, appName: config.appName, language: config.language);
        cmpConfig.isAutomaticATTRequest = true;
        cmpConfig.isDebugMode = true
        cmpConfig.designId = 10
        cmpConfig.idfa = "idfa"
        cmpConfig.isJumpToSettingsPage = true
        cmpConfig.timeout = 6000
Nouveau CmpLayout
     let cmpLayout = CmpLayout.default()
        cmpLayout?.cornerRadius = 10.0
        cmpLayout?.customLayout = CGRect(x: 0, y: 0, width: 200, height: 300)
Nouveaux rappels
            .withCmpViewControllerConfigurationBlock({ viewController in
                viewController?.modalPresentationStyle = .fullScreen
            })
            .withOnCmp(atTrackingStatusChangedCallback: { oldStatus, newStatus, dateChanged in
                print(oldStatus, newStatus, dateChanged)
            })
            
 Changement de dépôts

Nous changeons nos référentiels en Github d'Iubenda. Afin de conserver les dernières mises à jour, veuillez suivre les étapes ci-dessous :

Cacaopod

Pour les cacaopodes, il n'y a pas de changement. Assurez-vous simplement d'utiliser le pod CmpSdk.

  • Assurez-vous que Cocoapods est installé.
  • Mettez à jour votre version de Cocoapods vers 1.6.4 ou une version ultérieure.
Cadre XC

Gestionnaire de paquets Swift

Nous prenons désormais en charge le Swift Package Manager.

  • Mettez à jour les dépendances de votre projet pour inclure notre SDK à l'aide de SPM.
  • L'URL du référentiel pour Swift Package Manager est : https://github.com/iubenda/cm-sdk-xcframework.
  • Suivez la documentation officielle de Swift Package Manager pour intégrer le SDK dans votre projet.
 De 1.xx à 1.6.0

Il est important de noter que la mise à niveau vers une nouvelle version d'une application peut ne pas toujours être un processus transparent. Dans certains cas, vous devrez peut-être modifier votre code ou mettre à jour vos dépendances pour vous assurer que votre application fonctionne correctement.

Mettre à jour les identifiants CMP en identifiants de code pour une utilisation continue du SDK

Nous apportons quelques modifications aux identifiants CMP qui sont utilisés pour identifier notre CMP. Pour vous assurer de pouvoir continuer à utiliser notre SDK, il sera nécessaire de mettre à jour le ID CMP avec le nouveau ID de code qui se trouve dans la zone d'administration pour le code SDK.

Comment mettre à jour les identifiants CMP ?

Pour mettre à jour les identifiants CMP, vous devrez vous connecter à la zone d'administration du Consentmanager et trouvez les nouveaux identifiants de code (Obtenir le code -> Configuration des applications (Android/iOS)). Une fois que vous avez le nouveau ID de code, vous pouvez remplacer le ID CMP dans votre code SDK avec

SetupCodeId.png

Nous vous recommandons de mettre à jour votre code SDK avec le nouveau ID de code dès que possible pour vous assurer que vous pouvez continuer à utiliser notre CMP sans interruption.

Veuillez noter que la fin de vie du CMP-ID est prévue pour décembre 2023. Cela signifie que le CMP-ID ne sera plus pris en charge après cette date. Si vous avez des questions ou des préoccupations concernant cette migration, n'hésitez pas à contacter notre équipe d'assistance pour obtenir de l'aide !

Changements de constructeur

Nous avons changé les appels du constructeur et le rendons plus facile. Il y a essentiellement deux constructeurs principaux maintenant. Qui peut être initialisé comme ceci : 

/** Initialize with CmpConfig */
cmpConsentTool = CMPConsentTool(cmpConfig: cmpConfig, viewController: self)
  
/** Initialize without CmpConfig */
  
cmpConsentTool = cmpConsentTool(CMPConsentTool(domain: myCmpConfig.domain, codeId: myCmpConfig.appId, appName: myCmpConfig.appName, language: myCmpConfig.language, viewController: self))
        
/** Optionally chain callbacks */
cmpConsentTool = cmpConsentTool.withOpenListener(onOpen)
            				   .withOnCmpButtonClickedCallback(onButtonClickedEvent)
            				   .withCloseListener(onClose)
           					   .withErrorListener(onCmpError)
Modifications à vérifier pour Consentlayer

Dans la version précédente du SDK CMP, la vérification de la couche de consentement était intégrée dans la fonction de constructeur principal indiquée par le mise à jour automatique paramètre. Dans la nouvelle version de l'application, nous avons séparé la vérification dans une nouvelle fonction appelée initialize(). Cette modification a été apportée pour améliorer la fiabilité et la cohérence de la vérification du consentement.

Pour utiliser la fonction initialize(), vous pouvez appeler createInstance() avec les paramètres requis et ajouter la fonction initialize() sur l'objet renvoyé :

CMPConsentTool(cmpConfig: cmpConfig, viewController: self).initialize()
Nouvelles fonctions API

Dans la version précédente du SDK CMP, aucune fonction n'était fournie pour obtenir des informations sur les fournisseurs activés et désactivés de l'utilisateur, ou pour activer et désactiver les listes de fournisseurs et d'objectifs. Dans la nouvelle version de l'application, nous avons ajouté plusieurs nouvelles fonctions API qui vous permettent d'interagir plus profondément avec la couche de consentement.

Les nouvelles fonctions de l'API sont :

  • getAgreedVendors (getEnabledVendors): Cette fonction renvoie une chaîne contenant les ID des fournisseurs que l'utilisateur a acceptés.
  • getAgreedVendorList(getEnabledVendorList): Cette fonction renvoie une liste des ID des fournisseurs auxquels l'utilisateur a donné son accord.
  • getDisabledVendors: Cette fonction renvoie une liste des ID des fournisseurs que l'utilisateur a désactivés.
  • enableVendorList: Cette fonction active les fournisseurs spécifiés.
  • disableVendorList: Cette fonction désactive les fournisseurs spécifiés.
  • enablePurposeList: Cette fonction active les objectifs spécifiés et met à jour la liste des fournisseurs par défaut.
  • disablePurposeList: Cette fonction désactive les objectifs spécifiés et met à jour la liste des fournisseurs par défaut.
  • rejectAll: Cette fonction simule le rejet par un utilisateur de tous les fournisseurs et objectifs. Cela nécessite une OnConsentReceivedCallback fonction de rappel pour gérer l'asynchronicité de l'API.
  • acceptAll: Cette fonction simule l'acceptation par un utilisateur de tous les fournisseurs et objectifs. Cela nécessite une OnConsentReceivedCallback fonction de rappel pour gérer l'asynchronicité de l'API.

Le plus rejectAll et acceptAll nécessitent de fournir une fonction de rappel pour gérer l'asynchronicité de l'API. Vous devez implémenter toute logique métier qui dépend des résultats de ces fonctions dans les fonctions de rappel pour vous assurer que votre application est correctement mise à jour.

Mise à jour vers les nouvelles conventions de dénomination d'interface

Nous avons apporté quelques modifications à nos conventions de nommage d'interface afin de synchroniser l'API des SDK natifs et pour une meilleure compréhension du domaine. À la suite de ces changements, certaines signatures d'API ont été modifiées et de nouvelles méthodes ont été introduites.

Voici les changements qui ont été apportés :

Ancienne signature API Nouvelle signature d'API
getLastConsentString();

getConsentstring();

exportCMPData();

exportCmpString();

importCMPData(cmpData: string);

importCmpString(cmpString: string);

getAgreedVendor();

getEnabledVendors();

Mettre à jour le rappel d'erreur avec les types d'erreur CMP

Nous introduisons des types d'erreur CMP dans le rappel d'erreur pour offrir une plus grande flexibilité et permettre un comportement plus distingué en fonction du type d'erreur qui se produit. Avec cette mise à jour, vous serez en mesure de gérer plus efficacement différents types d'erreurs, ce qui contribuera à garantir à vos utilisateurs la meilleure expérience possible.

Quels sont les types d'erreurs CMP ?

Les types d'erreur CMP sont un ensemble de types d'erreur qui ont été introduits dans le rappel d'erreur. Ces types d'erreur sont utilisés pour identifier le type d'erreur qui s'est produit, et ils peuvent être utilisés pour déclencher différents comportements selon le type d'erreur.

Les quatre types d'erreur CMP qui ont été introduits sont :

  • Erreur réseau
  • Erreur de délai d'attente
  • ConsentReadWriteError
  • erreur inconnue

Quel sera l'impact de ce changement sur votre code ?

Pour prendre en charge les nouveaux types d'erreur CMP, la signature du rappel d'erreur a été mise à jour. La nouvelle signature est :

func onCMPError(type: CmpErrorType, message: String?)

Vous devrez mettre à jour votre code pour utiliser la nouvelle signature et gérer les différents types d'erreurs de manière appropriée.

Comment pouvez-vous gérer différents types d'erreurs ?

Pour gérer différents types d'erreurs, vous pouvez utiliser le paramètre CmpErrorType qui est passé au rappel d'erreur. Ce paramètre contiendra le type d'erreur qui s'est produite, que vous pouvez utiliser pour déclencher différents comportements.

Par exemple, vous pouvez gérer une NetworkError différemment d'une ConsentLayerError. Vous pouvez utiliser le paramètre CmpErrorType pour déterminer le type d'erreur et déclencher le comportement approprié.

Un exemple d'implémentation peut ressembler à ceci : 

func onCMPError(type: CmpErrorType, message: String?) -> Void {
        switch type {
        case .networkError:
            print(message)
            print("error network")
            break
        case .timeoutError:
            print(message)
            print("error timeout")
            break
        case .consentDataReadWriteError:
            print(message)
            print("error consent read/write")
            break
        case .unknownError:
            print(message)
            print("error unknown")
            break
        @unknown default:
            print(message)
            print("error network")
            break
        }
}
Nouveau rappel pour identifier les événements du bouton utilisateur : 

Nous avons ajouté une nouvelle fonction de rappel, OnCmpButtonClickedCallback, qui peut être utilisé pour déterminer les interactions des utilisateurs avec la couche de consentement en capturant les événements de clic de bouton spécifiques. Ce rappel aide les développeurs à mieux comprendre les préférences des utilisateurs et à personnaliser l'expérience utilisateur en conséquence.

Un exemple d'implémentation peut ressembler à ceci : 

func onButtonClickedEvent(event: CmpButtonEvent) -> Void {
    switch event {
        case .acceptAll:
            print("user accepted all")
            break
        case .rejectAll:
            print("user accepted all")
            break
        case .save:
            print("user saved custom settings")
            break
        case .close:
            print("user closed consent layer without giving consent")
            break
        @unknown default:
            print("unknown button event")
        }
}
Retour en haut de la page