Info
Innehåll

[Android] 0. Migrationsguide

version 1.7.33

Migreringsguide till nytt SDK-förråd

SDK-förvaret har flyttats till det officiella Maven-förvaret. Här är en steg-för-steg-guide om hur du uppdaterar ditt projekt för att använda det nya arkivet och den senaste versionen av SDK.

Före migration

Steg 1: Lägg till Jitpack Repository

Lägg till Jitpack-förvaret till din root build.gradle i slutet av förråd:

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

Steg 2: Lägg till beroende

Lägg till beroendet till din app build.gradle för att få den senaste versionen av SDK:n:

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

Steg 1: Ta bort Jitpack Repository

Ta bort Jitpack-förvaret från din root build.gradle:

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

Steg 2: Lägg till Official Maven Repository

Ersätt det gamla beroendet med det nya beroendet från det officiella Maven-förvaret:

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

Nu är ditt projekt uppdaterat för att använda det nya officiella Maven-förrådet och den senaste versionen av SDK (1.7.33). Se till att synkronisera ditt projekt och uppdatera alla andra konfigurationer eller kod som kan påverkas av den här migreringen.

Från 1.xx till 1.6.3

Det är viktigt att notera att uppgradering till en ny version av en app kanske inte alltid är en sömlös process. I vissa fall kan du behöva ändra din kod eller uppdatera dina beroenden för att säkerställa att din app fungerar korrekt.

Ändringar för att kontrollera för samtyckeslager

I den tidigare versionen av CMP SDK integrerades kontrollen för samtyckesskiktet i huvudkonstruktörsfunktionen. I den nya versionen av appen separerade vi checken i en ny funktion som heter initialize(). Denna ändring har gjorts för att förbättra tillförlitligheten och konsekvensen av samtyckeslagerkontrollen.

För att använda initialize()-funktionen kan du anropa createInstance() med de nödvändiga parametrarna och lägga till initialize()-funktionen på det returnerade objektet:

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

I det här exemplet anropar vi createInstance() för att initiera samtyckesskiktet. Initieringsfunktionen kommer att begära consentmanager och avgör om samtyckeslagaren måste visas eller inte.

Om du tidigare använde autouppdateringen för samtyckeslagret i din app, måste du ändra din kod för att använda initialize()-funktionen istället. Detta kommer att säkerställa att samtyckesskiktet kontrolleras konsekvent och tillförlitligt i den nya versionen av appen. Utan initialize() kommer bara instansen att skapas.

Om du använder en anpassad layout, var uppmärksam på att skicka aktivitetsinstansen i initieringen. För att se till att fragmentet kommer att läggas till korrekt i aktiviteten. 

Ändringar av återuppringningar

I den tidigare versionen av CMP SDK hade vi olika återuppringningar som var förvirrande att använda. I den nya versionen finns det nu fyra separata callback-funktioner som kan implementeras. Dessa återuppringningsfunktioner behöver bara läggas till i instansen en gång och kommer att vara tillgängliga genom alla api-interaktioner.

De fyra återuppringningarna heter så här:

  • onOpenCallback: Denna funktion anropas när samtyckesskiktet har öppnats.
  • OnCloseCallback: Denna funktion anropas när samtyckesskiktet är stängt.
  • OnCMPNotOpenedCallback: Denna funktion anropas när samtyckeslagret inte kan öppnas.
  • OnErrorCallback: Den här funktionen anropas när ett fel uppstår under interaktion med samtyckesskiktet.

Smakämnen OnErrorCallback funktionen kommer att anropas för alla vanliga fel, istället för de separerade felåteruppringningsfunktionerna som användes i den tidigare versionen av appen.

För att använda dessa callbacks kan du implementera dem i konstruktören av samtyckeslagret, så här:

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")
        }
    }

).
Nya API-funktioner

I den tidigare versionen av CMP SDK fanns det inga funktioner för att få information om användarens aktiverade och inaktiverade leverantörer, eller för att aktivera och inaktivera leverantörs- och ändamålslistor. I den nya versionen av appen har vi lagt till flera nya API-funktioner som gör att du kan interagera djupare med samtyckesskiktet.

De nya API-funktionerna är:

  • getAgreedVendors: Denna funktion returnerar en sträng som innehåller ID:n för de leverantörer som användaren har accepterat.
  • getAgreedVendorList: Denna funktion returnerar en lista över ID:n för de leverantörer som användaren har accepterat.
  • getDisabledVendors: Denna funktion returnerar en lista över ID:n för de leverantörer som användaren har inaktiverat.
  • enableVendorList: Denna funktion aktiverar de angivna leverantörerna.
  • disableVendorList: Denna funktion inaktiverar de angivna leverantörerna.
  • enablePurposeList: Den här funktionen aktiverar de angivna syftena och uppdaterar leverantörslistan som standard.
  • disablePurposeList: Den här funktionen inaktiverar de angivna syftena och uppdaterar leverantörslistan som standard.
  • rejectAll: Denna funktion simulerar en användares avvisande av alla leverantörer och syften. Det kräver en OnConsentReceivedCallback återuppringningsfunktion för att hantera API:ets asynkronitet.
  • acceptAll: Denna funktion simulerar en användares acceptans av alla leverantörer och syften. Det kräver en OnConsentReceivedCallback återuppringningsfunktion för att hantera API:ets asynkronitet.

Smakämnen rejectAll och acceptAll funktioner kräver att tillhandahålla en återuppringningsfunktion för att hantera API:ets asynkronitet. Du bör implementera all affärslogik som beror på resultaten av dessa funktioner i återuppringningsfunktionerna för att säkerställa att din app uppdateras korrekt.

Ändringar av importConsent-funktionen

I den tidigare versionen av CMP SDK, importCMPData funktionen användes för att importera cmp-samtyckessträngen till appens delade inställningar. I den nya versionen av appen har denna funktion uppdaterats. Denna funktion kommer att synkroniseras med Consentmanager Backend för bättre konsekvens och färre fel.

För att säkerställa funktionaliteten hos den uppdaterade importCMPData funktion har en återuppringning implementerats. Denna återuppringning meddelar dig om importen lyckades eller inte. All affärslogik som beror på resultatet bör också implementeras i denna callback.

Den uppdaterade funktionen har följande signatur:

fun importCMPData(context: Context, cmpData: String, callback: CmpImportCallback)

Du kan använda den här funktionen för att importera en fullständig samtyckessträng genererad av en ConsentWebView till de delade inställningarna för din enhet. För att anropa funktionen måste du ange följande parametrar:

  • context: Appkontexten
  • cmpData: Samtyckessträngen att importera, kodad i base64
  • callback: En återuppringningsfunktion för att ta emot resultatet av importoperationen

Om importen lyckas kommer funktionen att anropa onImportResult metod för återuppringning med success parameter inställd på true och ett meddelande som indikerar att importen lyckades. Om importen inte lyckas kommer funktionen att anropa onImportResult metod för återuppringning med success parameter inställd på false och ett meddelande som anger varför importen inte lyckades.

All affärslogik som beror på resultatet av importen bör implementeras i återuppringningen för att säkerställa att din app uppdateras korrekt.

Ändringar av Kotlins programmeringsspråk

Migrering till nya Kotlin SDK kräver några ändringar i hur du använder SDK. Appen har omstrukturerats från ett Java-bibliotek till ett Kotlin-bibliotek, och som ett resultat finns det några förändringar att vara medveten om.

För Java-applikationer måste du vara uppmärksam på statiska metoder och överbelastade funktioner. I vissa delar av SDK:n kan du behöva använda Companion objekt för att komma åt statiska metoder, och det kanske inte är möjligt att instansiera SDK-hanterarklassen på samma sätt som tidigare.

Vi har försökt se till att skillnaderna för migreringen är minimala, men det rekommenderas att du noggrant granskar dokumentationen och exempelkoden för den uppdaterade Kotlin SDK för att förstå eventuella ändringar i användningen. Granska dessutom din befintliga kodbas och uppdatera eventuella anrop till föråldrade eller borttagna metoder för att undvika problem under migreringsprocessen.

Överlag bör migreringen till den nya Kotlin SDK vara okomplicerad. Ändringarna har gjorts för att förbättra funktionaliteten och konsekvensen i SDK:n. Det är dock viktigt att noggrant testa din kodbas efter migreringen för att säkerställa att allt fungerar korrekt.

Från 1.5.7 till 1.6.0
Uppdatera CMP-ID:n till kod-ID:n för fortsatt användning av SDK:n

Vi gör några ändringar i CMP-ID:n som används för att identifiera vår CMP. För att säkerställa att du kan fortsätta att använda vår SDK kommer det att vara nödvändigt att uppdatera CMP ID:n med den nya Kod-ID:n som finns i administratörsområdet för SDK-koden.

Hur uppdaterar du CMP-ID:n?

För att uppdatera CMP-ID:n måste du logga in på adminområdet för Consentmanager och hitta de nya kod-ID:n (Hämta kod -> Konfiguration för appar (Android/iOS)). När du har den nya Kod ID, du kan byta ut CMP-ID i din SDK-kod med den

SetupCodeId.png

Vi rekommenderar att du uppdaterar din SDK-kod med den nya Kod-ID:n så snart som möjligt för att säkerställa att du kan fortsätta använda vår CMP utan avbrott.

Observera att slutet av livet för CMP-ID:t är planerat till december 2023. Detta innebär att CMP-ID inte längre kommer att stödjas efter det datumet. Om du har några frågor eller funderingar kring den här migreringen, tveka inte att kontakta vårt supportteam för hjälp!

Uppdatering till nya gränssnittsnamnkonventioner

Vi har gjort några ändringar i våra gränssnittsnamnkonventioner för att synkronisera API:erna för de inbyggda SDK:erna och för bättre domänförståelse. Som ett resultat av dessa ändringar har vissa API-signaturer modifierats och några nya metoder har introducerats.

Här är ändringarna som har gjorts:

Gammal API-signatur Ny API-signatur
checkAndOpenCmpLayer();

checkAndOpenCmpLayer(appInterface: string);

getLastConsentString();

getConsentstring();

exportCMPData();

exportCmpString();

importCMPData(cmpData: string);

importCmpString(cmpString: string);

getAgreedVendor();

getEnabledVendors();

Uppdatera Error Callback med CMP-feltyper

Vi introducerar CMP-feltyper i felåteruppringningen för att ge större flexibilitet och för att möjliggöra mer distingerat beteende beroende på vilken typ av fel som uppstår. Med den här uppdateringen kommer du att kunna hantera olika typer av fel mer effektivt, vilket hjälper till att säkerställa att dina användare får bästa möjliga upplevelse.

Vad är CMP-feltyper?

CMP-feltyper är en uppsättning feltyper som har introducerats till felåteruppringningen. Dessa feltyper används för att identifiera typen av fel som har uppstått, och de kan användas för att utlösa olika beteenden beroende på typen av fel.

De fyra CMP-feltyperna som har introducerats är:

  • Nätverksfel
  • TimeoutError
  • ConsentReadWriteError
  • ConsentLayerError

Hur kommer denna förändring att påverka din kod?

För att stödja de nya CMP-feltyperna har signaturen för felåteruppringningen uppdaterats. Den nya signaturen är:

fun errorOccurred(type: CmpError, message: String)

Du måste uppdatera din kod för att använda den nya signaturen och för att hantera de olika typerna av fel på rätt sätt.

Hur kan man hantera olika typer av fel?

För att hantera olika typer av fel kan du använda parametern CmpError som skickas till felåteruppringningen. Den här parametern kommer att innehålla typen av fel som har uppstått, som du kan använda för att utlösa olika beteenden.

Till exempel kan du hantera ett nätverksfel annorlunda än ett ConsentLayerError. Du kan använda parametern CmpError för att fastställa typen av fel och för att utlösa lämpligt beteende.

Ett exempel på en implementering kan se ut så här: 

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")
                        }
                    }
                }
Ny återuppringning för att identifiera användarknapphändelser: 

Vi har lagt till en ny återuppringningsfunktion, OnCmpButtonClickedCallback, som kan användas för att fastställa användarnas interaktioner med samtyckesskiktet genom att fånga de specifika knappklickshändelser. Denna återuppringning hjälper utvecklare att få insikter i användarpreferenser och anpassa användarupplevelsen därefter.

Ett exempel på en implementering kan se ut så här: 

            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")
                        }
                    }
                }
            }
Tillbaka till toppen