L'API Mobile Engage v2

CocoaPods est un gestionnaire de dépendance pour iOS, qui automatise et simplifie le processus d'utilisation de bibliothèques tierces.

Vous pouvez l'installer avec la commande suivante :

Gradle est un système de construction pour Android, qui automatise et simplifie le processus d'utilisation de bibliothèques tierces.

Pour intégrer le SDK Mobile Engage dans votre projet Android sur Gradle, vous devez le spécifier dans le fichier build.gradle de votre application :

La version minimum d'Android doit être au moins API level 14.

Le SDK Mobile Engage va de pair avec les dépendances Firebase, mais il ne vous fournit pas tous les paramètres nécessaires pour que votre appli fonctionne.

Pour intégrer Firebase dans votre appli, suivez les instructions dans la documentaiton Firebase. En revanche, vous n'avez pas besoin d'ajouter les dépendances de Firebase pourfirebase-core et firebase-messaging, car ils sont déjà inclus dans le SDK Mobile Engage.

Pour permettre au SDK Mobile Engage de gérer automatiquement les appelssetPushToken and trackMessageOpen pour vous, merci de d'inscrire ces services dans votre fichier manifest.

De plus, vous pouvez installer une icône de notification personnalisée, en précisant qu'il s'agit de méta-données entre le tag de votre application :

Pour configurer le Kit de Développement (SDK), vous devez exécuter ce qui suit dans la méthodeonCreate dans la classe Application, Et nous pouvons configurer le statusListener également :

LestatusListenerpeut également être réglé plus tard; il n'est pas obligatoire pour l'initialisation de Mobile Engage:

Chaque appel renvoie un eventId, qui peut être utilisé avec le statusListener pour tracer nos appels. Le statusListener définit deux méthodes:

Lorsque l'installation de l'application est terminée, vos pouvez utiliser les méthodes d'appLogin pour identifier l'utilisateur. Si vous souhaitez vérifier les uilisateurs aninymes, vous pouvez utiliser appLogin sans paramètres:

Si l'utilisateur est déjà connu, vous pouvez utiliser les paramètres : appLogin avec contactFieldID et contactFieldValue :

Si vous souhaitez vérifier si les messages push ont été ouverts, c'est la fonction trackMessageOpen qu'il faut utiliser; et nous envoyons le RemoteMessage que nous recevons du FCM :

Si vous souhaitez vérifier les événements personnalisés, c'est la fonction trackCustomEvent qu'il faut utliser, où le paramètre nom est obligatoire, mais tous les autres attributs sont facultatifs:

Lorsque l'utilisateur se déconnecte, la fonction appLogout doit être utilisée :

Chaque appel MobileEngage (appLogin, appLogout, trackCustomEvent) renvoie un unique eventId, ce qui vous permet de tracer le résultat de chaque appel.

Aussitôt que le SDK Mobile Engage reçoit une réaction de nos serveurs, le statusDelegate fourni sur iOS ou bien le MobileEngageStatusListener sur Android est notifié du succès de cet eventId:

• Si la requête a fonctionné, les méthodes mobileEngageLogReceived (iOS), ou onStatusLog (Android) sont appelées avec l'eventId et un message de log.
• Si la demande a échoué, les méthodes mobileEngageErrorHappened (iOS), ou onError (Android) sont sollicitées avec l' eventId et l'Erreur/Exception. L'erreur/exception peut être une erreur de réseau (IOException) ou une exception personnalisée accompagnant la réponse du serveyr. Par exemple : 400 - Mauvaise demande.

Vous pouvez vérifier si les appels SDK ont été reçus par nos serveurs en cliquant sur l'icône SDK events sur les onglets e Apps De l'interface utilisateur Mobile Engage.

La colonne Nom montre l'événement qui a été reçu alors que la colonne Statut montre le code de réponse. Si sa valeur est 201 ou 202,l'intégration du SDK est réussie.

Chaque nouvelle sortie du SDK apporte soit de nouvelles fonctionnalités, soit des corrections de problèmes connus, donc il est toujours avantageux de mettre à jour vers la nouvelle version.

Nous faisons en sorte d'assurer que le SDK sot de qualité maximale, et cela implique de prendre en compte la compatibilité rétroactive.

De manière générale, il est conseillé de mettra à jour votre version aussi souvent que possible. Même si vous ne prévoyez pas d'incorporer des nouvelles fonctionnalités à votre appli, nous vous encourageons quand même à faire au moins une mise à jour lorsqu'une nouvelle version patch sort, afin de ne pas manquer les corrections de bogues et d'autres améliorations du SDK.

Le Versioning du SDK suit la logique x,y,z pour laquelle xest une version majeure, y est une version mineure, etz une version de correction (patch)

• Version majeure - C'est une nouvelle version importante, qui implique par exemple une fonctionnalité attendue impatiemment.Bien que cela arrive contre notre plein gré, il se peut qu'une nouvelle version majeure affecte la compatibilité rétroactive avec la précédente version.Nous nous efforçons d'en sortir un minimum et ce pour une raison importante. Ceci sera toujours communiqué avant.
• version mineure - Elle apporte de nouvelles petites fonctionnalités. Les versions mineures ne régressent jamais sur la compatibilité.
• Version de correction - Elle vous apporte des corrections de bugs, de la stabilité et des améliorations de performance.Les versions de correction ne régressent pas non plus sur la compatibilité.