# Mobile APP

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-cover data-type="files"></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td></td><td>ANDROID SDK</td><td></td><td><a href="https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-84149aba8bdce06ff7f5513d2cc5e8c775caac2a%2FAndroid_symbol_green_RGB%5B1%5D.png?alt=media">Android_symbol_green_RGB[1].png</a></td><td><a href="mobile-app/android">android</a></td></tr><tr><td></td><td>IOS SDK</td><td></td><td><a href="https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-7c5fd14f39e540e0a4fd11cbef2a2acd26578a01%2Fapple-logo-png-dallas-shootings-don-add-are-speech-zones-used-4%5B1%5D.png?alt=media">apple-logo-png-dallas-shootings-don-add-are-speech-zones-used-4[1].png</a></td><td><a href="mobile-app/ios">ios</a></td></tr><tr><td></td><td>FLUTTER SDK</td><td></td><td><a href="https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-cd24ef0942b958b1847f0255cddc5a7b80b2626f%2Fflutter5786%5B1%5D.jpg?alt=media">flutter5786[1].jpg</a></td><td><a href="mobile-app/flutter">flutter</a></td></tr><tr><td></td><td>REACT NATIVE SDK</td><td></td><td><a href="https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-4320d59923b83bbd10e14945a928e236ad2c0f18%2F2300px-React-icon.svg%5B1%5D.png?alt=media">2300px-React-icon.svg[1].png</a></td><td><a href="mobile-app/react-native">react-native</a></td></tr><tr><td>HTTP TRACKING API</td><td></td><td></td><td><a href="https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-be1580a5c83060c530e176626ef1a3669a96a08e%2FHTTP.jpg?alt=media">HTTP.jpg</a></td><td><a href="https://doc.commandersact.com/features/sources/sources-catalog/server/http-tracking-api">https://doc.commandersact.com/features/sources/sources-catalog/server/http-tracking-api</a></td></tr></tbody></table>

## Introduction au tagging des applications mobiles

de CommandersAct **SDK** vous permet de déclencher des destinations depuis une application mobile.

Commanders Act propose un SDK dit « super light » que vous pouvez intégrer au code de votre application mobile ; son objectif est de réduire autant que possible les appels vers les solutions partenaires afin d’améliorer les performances et l’expérience utilisateur de votre application. Un appel unique est envoyé aux serveurs de CommandersAct pour chaque action enregistrée dans l’application. Les informations liées à la page consultée ou à l’élément cliqué sont ensuite envoyées séparément aux solutions partenaires par les serveurs de CommandersAct ; cela permet d’éviter tout ralentissement de la vitesse de chargement des applications.

**Note**: Toutes les solutions ne sont pas compatibles avec cette méthode. Comme le light SDK envoie les informations de l’application aux serveurs des solutions partenaires, celles-ci ne peuvent pas « remonter » vers l’application. Les solutions d’adserving (celles qui affichent des publicités) et les fournisseurs de notifications push ne sont donc pas compatibles avec cette méthode.

Le principe de fonctionnement de base du light SDK de Commanders est :

– **Étape 1**: le data layer mobile et le SDK de CommandersAct sont appelés dans le code source de l’application à chaque chargement d’écran ou lors d’un clic sur un élément. (votre équipe IT devrait avoir mis cela en place au début du projet).

– **Étape 2**: le SDK de CommandersAct envoie des appels aux serveurs de CommandersAct et transmet automatiquement le contenu du data layer mobile. Voici la structure des hits server-side : <https://collect.commander1.com/events?tc\\_s=`${siteID}`\\&token=`${YOUR_SOURCE_KEY}`>

`${siteID}` et `${YOUR_SOURCE_KEY}` doivent être fournis au SDK et seront remplacés automatiquement.

Le reste des paramètres est envoyé dans le body en POST comme présenté ici :

{% content-ref url="../../../developpeurs/tracking-and-integrations/tracking/about-events/mobile-sdk-event-specificity" %}
[mobile-sdk-event-specificity](https://doc.commandersact.com/fr/developpeurs/tracking-and-integrations/tracking/about-events/mobile-sdk-event-specificity)
{% endcontent-ref %}

– **Étape 3**: les serveurs de CommandersAct envoient les informations reçues aux différentes destinations. Il y a autant de hits sortants qu’il y a de solutions partenaires auxquelles vous souhaitez envoyer des informations.

<figure><img src="https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-6593ac66eba107802fcc1fea4e06a597b0a12e0f%2Fimage.png?alt=media" alt="" width="563"><figcaption></figcaption></figure>

Ex. : si vous souhaitez envoyer un appel à la fois à Criteo et à Google, un hit sera envoyé aux serveurs de l’une ou l’autre solution.

L’implémentation de nos SDK sur une application mobile est un projet qui comprend les étapes listées ci-dessous :

* Définition du plan de tagging de l’application mobile : sélection et définition des événements.
* Création d’une source mobile et de destinations
* Implémentation du SDK de CommandersAct dans le code source de l’application.
* Tests d’acceptation de l’implémentation dans un environnement de test.
* Publication

## Étape n°1 : définition du plan de tagging de l’application

Le plan de tagging correspond à la liste des événements qui seront envoyés.

## Étape n°2 : création d’une source mobile et configuration des destinations dans l’interface CommandersAct

* **Création d’une source pour iOS, Android ou les deux.**
* **Implémenter ou sélectionner des destinations.**

L’implémentation d’une destination mobile est la même que l’implémentation de destinations cloud-base

## Étape n°3 : implémentation du SDK dans le code source des applications

L’implémentation du SDK est effectuée par des équipes techniques ou des services IT.

Ces éléments doivent être fournis :

* Le plan de tagging de l’application CommandersAct, qui permet à l’équipe IT de savoir quels événements déclarer et sur quels écrans ou éléments.
* La documentation technique relative à chaque application. Elle doit contenir les éléments clés pour configurer le SDK ainsi que des captures d’écran d’exemples de configuration.

Cliquez ici pour lire la documentation technique correspondante. iOS : <https://github.com/CommandersAct/iOSV5/> android : <https://github.com/CommandersAct/androidv5/>

L’ID du site (numéro de compte Commanders Act) et la clé source sont nécessaires pour configurer le SDK. Ces deux éléments peuvent être récupérés dans l’interface.

## Étape n°4 : test de la configuration dans un environnement de test

Le SDK de Commanders Act peut être testé avec de nombreux outils différents :

### **Tests pour iOS avec XCode**

Le SDK de Commanders Act pour iOS peut être testé avec le logiciel de développement d’Apple « XCode » :

<https://itunes.apple.com/fr/app/xcode/id497799835>

Vous devrez connecter votre iPhone à votre Mac.

Ouvrez XCode, allez dans « Window » ), > « Devices » (2), puis sélectionnez votre appareil dans la colonne de gauche (3) :

![](https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-b8576181107b9ff6c9171c4ec4dae16cd9939941%2Fxcode_1%5B1%5D.png?alt=media)

Ces éléments seront affichés lorsque vous analyserez les logs mobiles :

* Numéro de version du SDK de Commanders Act\
  exemple pour le module de consentement : « Commanders Act Privacy module init with version: 5.2.0 »
* ID du site Commanders Act
* Événements Server-Side envoyés contenant toutes les propriétés que vous avez envoyées aux serveurs de Commanders Act (méthode POST). Pour plus d’informations sur la construction des événements, vous pouvez vous référer à nos [exemples de codes d’événements](https://doc.commandersact.com/fr/developpeurs/tracking-and-integrations/tracking/events-reference)

![](https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-1d4017a54d1b1cef8792f7817a0ebc0cecaabbd0%2Fxcode_2%5B1%5D.png?alt=media)

\*\*\*

### **Exécution des tests pour Android ou iOS avec Charles Debugger**

Le SDK de Commanders Act pour les systèmes iOS et Android peut être testé avec le proxy « Charles Debugger », téléchargeable gratuitement ici : [https://www.charlesproxy.com/](https://www.charlesproxy.com)

La première chose à faire est de configurer votre téléphone afin qu’il puisse communiquer avec Charles.

Dans les paramètres de votre téléphone, allez dans l’onglet de configuration Wi-Fi.

Sélectionnez votre réseau et accédez aux options avancées pour modifier les paramètres Wi-Fi.

Ajoutez un proxy manuellement :

* Nom du proxy (server)(1) : IP de l’ordinateur (vous pouvez la trouver dans l’onglet « Local IP address » des options de Charles)
* Port (2) : 8888

Enregistrez.

![](https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-e18b8a380a1854093788f60131dbfb4ede6a8996%2Fcharles_1%5B1%5D.png?alt=media)

Allez dans l’application Charles et autorisez-la à se connecter au téléphone.

![](https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-d42eed05aa76e5f8a22fbbabc1ec0d30b41f8b68%2Fcharles_2%5B1%5D.png?alt=media)

Naviguez sur le web avec votre téléphone et, dans Charles (sur votre ordinateur), appliquez un filtre « Commander » pour voir les hits server-side affichés dans la section « Overview ». Ils ressemblent à ceci :\
<https://collect.commander1.com/events?tc_s=XXXX&token=XYZZ>

Lorsque vous allez dans la zone « Request », vous pourrez voir toutes les variables et les valeurs correspondantes envoyées via le SDK de Commanders Act.

![](https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-6adcea882aa2e8604d3956223ef6a6c80df787cd%2Fcharles_3%5B1%5D.png?alt=media)

Protocole HTTPS :

La plupart du temps, les appels server-side sont effectués via un protocole https.

Voir des hits https avec Charles nécessite une configuration plus complexe. Vous devrez ouvrir le navigateur de votre téléphone pendant que Charles s’exécute sur votre ordinateur et aller sur cette URL depuis votre téléphone <http://www.charlesproxy.com/getssl/>

Téléchargez le certificat et installez-le ; vous devrez saisir son nom pour deux applications : « VPN and applications » et « Wi-fi ».

Retournez dans Charles > « SSL proxy settings » > « SSL Proxying » > cochez « Enable SSL Proxying » > cliquez sur « Add » et saisissez « \* » dans le champ « Host » (pour autoriser n’importe quel hôte).

Ensuite, procédez aux tests de la même manière que pour les hits http.

## Étape n°5 : publication

Lorsque l’implémentation est correcte dans votre environnement de test, vous devez soumettre votre application aux stores (Apple Store ou Android Market) et attendre qu’ils approuvent les modifications et intègrent la nouvelle version dans leurs catalogues.