Android : Feature Toggle avec Google Tag Manager

Le concept de feature toggle est bien pratique en tant que développeur si l’on souhaite faire évoluer sa base de code source à un rythme différent de celui des livraisons et des fonctionnalités. C’est souvent le cas lorsqu’il y a autour du produit une équipe marketing / communication qui s’occupe d’annoncer telle ou telle nouvelle fonctionnalité.

Le problème avec Android c’est qu’il peut être vite problématique d’utiliser ces features toggle, car une fois l’application arrivée sur le téléphone des utilisateurs le développeur n’a plus la possibilité de changer la valeur des flags autrement qu’en relivrant l’application, ce qui peut vite se terminer par du spam d’updates si les activations/désactivations sont trop fréquentes ou trop rapprochées.

C’est là qu’entre en jeu Google Tag Manager, cet outil made by Google va nous offrir la possibilité d’activer/désactiver lesdites fonctionnalités et cela sans avoir à redéployer l’application sur le store.

Google Tag Manager : La configuration

Pour commencer, il faut aller dans l’interface dédiée de Google Tag Manager afin de générer la configuration nécessaire pour notre application. C’est via cette IHM et avec les informations que l’on va y ajouter que l’on pourra revenir plus tard et modifier des valeurs qui seront prises en compte dans l’application Android.

La mise en place d’une configuration pour une application Android passe donc par les étapes suivantes :

Créez un nouveau container (ce qui correspond à créer la configuration pour une application).
Donnez-lui le nom que vous voulez et sélectionnez le type Android.
Une fois le container créé un code unique du type GTM-XXXXXX lui est attribué par Google notez-le, il sera utilisé dans le code de l’application Android.
Ensuite dans ce container rendez-vous dans la partie Variables et créez une nouvelle variable.
Choisissez le type Value Collection.
Définissez sa valeur avec un objet json { 'clé' : 'valeur' }, la clé sera elle aussi réutilisée dans le code Android et la valeur peut être ce que vous souhaitez (ici un boolean ira très bien).
N’oubliez d’activer cette variable en sélectionnant Enable : Always.
Sauvegardez la variable.
Vous pouvez dès à présent publier le container, il est prêt à être utilisé.
Avant de quitter cet écran une dernière opération utile, téléchargez la première version publiée du container, il sera nécessaire de l’embarquer dans le code source en tant que configuration initiale.

Ces étapes sont résumées dans ces écrans :

Normalement arrivé là, vous avez configuré un container avec une variable dans celui-ci. Et vous disposez pour ce container de son code unique ainsi que d’un binaire de son contenu.

Application Android : Le code

La seconde partie du travail consiste à modifier son code applicatif afin de lire la variable précédemment ajoutée dans Google Tag Manager.

Pour commencer, stockez votre code Google Tag Manager (dans une constante ou un ficher xml, peu importe).

<resources>
    <string name="tag_manager_id">GTM-N8NXMK</string>
</resources>

Ensuite copiez le binaire téléchargé (correspondant à la configuration initiale du container) dans le répertoire /res/raw/, attention vous devrez surement changer le nom du fichier pour enlever les majuscules.
Ajoutez dans votre build.gradle une nouvelle dépendance vers les play services (seulement la partie analytics nous intéresse).

dependencies {
    compile 'com.google.android.gms:play-services-analytics:8.4.0'
}

Maintenant dans une Activity (ou bien dans votre Application), vous avez deux choses à faire, récupérer une instance de TagManager et faire une requête pour lire la configuration actuelle du Container.

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        final TagManager tagManager = TagManager.getInstance(this);
        PendingResult pending = tagManager.loadContainerPreferFresh(getString(R.string.tag_manager_id), R.raw.gtm_initial_conf);
        pending.setResultCallback(new ResultCallback<ContainerHolder>() {
           @Override
           public void onResult(@NonNull ContainerHolder containerHolder) {
               // If unsuccessful, return
               if (!containerHolder.getStatus().isSuccess()) {
                   // Deal with failure
                   return;
               }
               containerHolder.refresh();

               final boolean feature1Status = containerHolder.getContainer().getBoolean("feature1");
               Log.d("TagManager", String.valueOf(feature1Status));
           }
        }, 2, TimeUnit.SECONDS);
}

Et c’est tout ! Vous pouvez retourner dans l’interface de Tag Manager, pour modifier la valeur de la variable feature1, publiez la nouvelle version du container et si vous redémarrez l’application, la nouvelle valeur devrait apparaitre.

Rapide et efficace, non ?

Chargement des données du container

Via l’instance de TagManager différentes méthodes sont disponibles pour charger le container et les valeurs qu’il contient.

tagManager.loadContainerDefaultOnly(...); (1)
tagManager.loadContainerPreferFresh(...); (2)
tagManager.loadContainerPreferNonDefault(...); (2)

1	va uniquement regarder les valeurs dans le binaire ajouté dans /res/raw
2	vont essayer de prendre les dernières valeurs publiées (ou non) mais sans être garantie à 100% (notamment s’il ya des problèmes de réseaux)

Les différences sont détaillées dans la doc. Mais selon toute logique cette qui va nous intéresser sera uniquement loadContainerPreferFresh().

Conclusion

Les pour et les contre d’utiliser Tag Manager pour faire du feature toggle vont forcément dépendre du besoin du développeur.

Pour

Le principale avantage et la mise en place sans le développement d’une API rien que pour ça (si votre application n’a pas de backend dédié, pas besoin d’en créer un).
Toute la logique de configuration initiale versus configuration mise à jour est déjà implémentée et tout se gère via l’appel tagManager.loadContainer().
Ça fonctionne tout aussi bien sur iOS.
Un autre point très intéressant (et non abordé ici) est la publication d’une variable selon des critères (on va pouvoir modifier un toggle, pour par exemple faire du A/B testing en fonction d’un tas de critères comme la taille de l’écran ou bien la langue de l’utilisateur ou même la version de l’application).

Contre

Si le loadPreferFresh échoue (problème réseau par exemple) on retombe sur la config par défaut, mais est-ce que ça fonctionnerait mieux avec une solution custom ? par sûr.

Liens

Code sources d’exemple : https://github.com/fchauveau/blog-android-tag-manager
Documentation Google officielle : https://developers.google.com/tag-manager/android/v4/
Cours Udacity d’explication : https://www.udacity.com/course/viewer#!/c-ud876-2/l-4027658558/m-4328729937

Rédigé par Florian

Article précédent Article suivant

Blog