Ces informations vous aideront à migrer de la version 2.x ou 3.x de la bibliothèque iOS vers la version 4.x.
Le SDK utilise NSUserDefaults
pour stocker les données nécessaires au calcul d’utilisateurs uniques, de mesures de cycle de vie et d’autres données nécessaires dans le cadre du fonctionnement de base du SDK. Si vous modifiez ou supprimez dans NSUserDefaults
des valeurs attendues par le SDK, il peut en résulter un comportement inattendu sous la forme de données incohérentes.
Dans la bibliothèque du SDK iOS version 4.x, les méthodes publiques sont consolidées dans un en-tête. En outre, les fonctionnalités sont désormais accessibles par des méthodes de niveau de classe : ainsi, il n’est pas nécessaire d’effectuer le suivi des pointeurs, des instances ou des singletons.
Dans la version 4, vous ne pouvez plus affecter de variables telles que des événements, des eVars, des props, des héritiers et des listes directement dans votre application. Au lieu de cela, le SDK utilise des données contextuelles et des règles de traitement pour mapper les données de votre application sur les variables Analytics à des fins de reporting.
Les règles de traitement offrent les avantages suivants :
Vous pouvez modifier le mapping de vos données sans envoyer de mise à jour à la boutique d’applications.
Vous pouvez utiliser des noms significatifs pour les données au lieu de définir des variables spécifiques à une suite de rapports.
L’envoi de données supplémentaires n’a que peu d’impact.
Ces valeurs n’apparaîtront dans les rapports qu’après avoir été mappées à l’aide de règles de traitement.
Les valeurs que vous assignez directement aux variables doivent désormais être ajoutées au NSDictionary data
.
Le nouveau fichier ADBMobileConfig.json
comporte des paramètres globaux, spécifiques à une application et remplace la plupart des variables de configuration utilisées dans les versions précédentes. Voici un exemple de fichier ADBMobileConfig.json
:
{
"version" : "1.0",
"analytics" : {
"rsids" : "coolApp",
"server" : "my.CoolApp.com",
"charset" : "UTF-8",
"ssl" : true,
"offlineEnabled" : true,
"lifecycleTimeout" : 5,
"privacyDefault" : "optedin",
"poi" : [
["san francisco",37.757144,-122.44812,7000],
["santa cruz",36.972935,-122.01725,600]
]
},
"target" : {
"clientCode" : "myTargetClientCode",
"timeout" : 5
},
"audienceManager" : {
"server" : "myServer.demdex.com"
}
}
Pour déplacer le fichier de configuration :
Les tableaux suivants répertorient les variables de configuration que vous devez déplacer vers le fichier de configuration.
Déplacez la valeur de la première colonne vers la variable de la deuxième colonne.
Variable de configuration | Variable du fichier ADBMobileConfig.json |
---|---|
offlineTrackingEnabled | "offlineEnabled" |
offlineHitLimit | "batchLimit" |
reportSuiteIDs | "rsids" |
trackingServer | "server" |
charSet | "charset" |
currencyCode | "currency" |
ssl | "ssl" |
linkTrackVars | Supprimer, n’est plus utilisé. |
linkTrackEvents | Supprimer, n’est plus utilisé. |
Déplacez la valeur de la première colonne vers la variable de la deuxième colonne.
Variable de configuration | Variable du fichier ADBMobileConfig.json |
---|---|
trackOffline | "offlineEnabled" |
offlineLimit | "batchLimit" |
account | "rsids" |
trackingServer | “server”, supprimez le préfixe "https://" . Le préfixe de protocole est ajouté automatiquement en fonction du paramètre “ssl”. |
trackingServerSecure | Supprimer. Pour les connexions sécurisées, définissez "server", puis activez "ssl". |
charSet | "charset" |
currencyCode | "currency" |
ssl | "ssl" |
linkTrackVars | Supprimer, n’est plus utilisé. |
linkTrackEvents | Supprimer, n’est plus utilisé. |
timestamp | Supprimer, ne peut plus être configuré. |
dc | Supprimer, n’est plus utilisé. |
userAgent | Supprimer, ne peut plus être configuré. |
dynamicVariablePrefix | Supprimer, n’est plus utilisé. |
visitorNamespace | Supprimer, n’est plus utilisé. |
usePlugins | Supprimer, n’est plus utilisé. |
useBestPractices tous les appels à la mesure churn (getChurnInstance) | Supprimée, remplacée par des mesures de cycle de vie. Pour en savoir plus, voir la section Mesures de cycle de vie. |
Au lieu d’utiliser les appels web track
et trackLink
, le SDK version 4 utilise les méthodes suivantes :
Les états trackState:data:
sont les affichages disponibles dans l’application, par exemple home dashboard
, app settings
, cart
, etc.
Ces états sont semblables aux pages d’un site web ; les appels trackState
incrémentent les pages vues.
Les actions trackAction:data:
, par exemple logons
, banner taps
, feed subscriptions
, etc. qui se produisent dans l’application et que vous souhaitez mesurer.
Le paramètre data
pour ces deux méthodes est un NSDictionary
qui contient des paires nom-valeur envoyées en tant que données contextuelles.
Dans la version 4, vous ne pouvez plus affecter de variables telles que des événements, des eVars, des props, des héritiers et des listes directement dans votre application. Au lieu de cela, le SDK utilise des données contextuelles et des règles de traitement pour mapper les données de votre application sur les variables Analytics à des fins de reporting.
Les règles de traitement offrent les avantages suivants :
Vous pouvez modifier le mapping de vos données sans envoyer de mise à jour à la boutique d’applications.
Vous pouvez utiliser des noms significatifs pour les données au lieu de définir des variables spécifiques à une suite de rapports.
L’envoi de données supplémentaires n’a que peu d’impact.
Ces valeurs n’apparaîtront dans les rapports qu’après avoir été mappées à l’aide de règles de traitement. Pour plus d’informations, voir Règles de traitement et données contextuelles.
Les valeurs que vous avez directement attribuées aux variables doivent être ajoutées au data
NSDictionary
à la place. Cela signifie que les appels vers setProp
, setEvar
et les attributions à des données contextuelles persistantes doivent être supprimés et les valeurs doivent être ajoutées au paramètre data
.
Les données que vous configuriez sur l’objet de mesure, y compris les variables répertoriées ci-dessus, doivent être ajoutées au data
NSDictionary
à la place. Les seules données envoyées avec un appel trackState
ou trackAction
sont la charge utile dans le paramètre data
.
Dans le code, remplacez les méthodes suivantes par un appel à trackState
ou trackAction
:
trackAppState (trackState)
trackEvents (trackAction)
track (trackAction)
trackWithContextData (trackAction)
trackLinkURL (trackAction)
track (trackState)
trackLink (trackAction)
Remplacez la variable visitorID
par un appel à setUserIdentifier:
.
Le suivi hors ligne est activé dans le fichier ADBMobileConfig.json
et le reste de la configuration hors ligne est effectué automatiquement.
Dans le code, supprimez les appels aux méthodes suivantes :
setOnline
setOffline
forceOffline
forceOnline
Puisque la variable products
n’est plus disponible dans les règles de traitement, vous pouvez utiliser la syntaxe suivante pour la définir :
//create a processing rule to set the corresponding product event.
// for example, set prodView event when context data a.action = "product view"
[ADBMobile trackAction:@"LikeButtonClicked"
data:@{@"&&products" : @";Cool Shoe"}];