2016-06-14 18 views
6

Prima che l'analisi di Firebase sia disponibile, utilizziamo un'impostazione del progetto Grader multi flavour e multi build di tipo Android e forniamo un ID contenitore GTM diverso per ogni variante di costruzione, come segue:Configura Firebase Analaytics + Google Tag Manager (GTM) per variante di costruzione

TagManager.getInstance(context) 
     .loadContainerPreferNonDefault(BuildConfig.GTM_CONTAINER_ID, -1); 
TagManager.getInstance(context).getDataLayer().pushEvent(eventName, eventData); 

dove Gradle introdurrebbe diverso GTM_CONTAINER_ID per costruire variante.

Come otteniamo lo stesso risultato con Firebase Analytics + GTM? Secondo docs, abbiamo bisogno di scaricare:

  • un file contenitore GTM GTM da cruscotto [1]
  • un file di google-services.json dalla console Firebase [2]

e poi basta iniziare a sparare eventi con this:

FirebaseAnalytics.getInstance(context).logEvent(eventName, bundle); 

Dove si specifica l'ID del contenitore GTM da utilizzare? Oppure è auto derivato dal nome del file che scarichiamo dalla dashboard di GTM e posta sotto assets/containers? In tal caso, come utilizziamo diverse configurazioni GTM per variante di build come facciamo con il contenitore Android legacy GTM?

+0

@ DevZer0 come mai questo è uno spam di voto? –

+0

@AnirudhSharma è uno scherzo tra me e lui, lavoriamo nella stessa azienda :) sto solo aspettando che mi faccia un pisolino in ritardo :) – DevZer0

+0

@ DevZer0 Haha.Good one :) –

risposta

3

L'ID del contenitore è derivato dal nome del file contenitore, come ipotizzato. Per utilizzare una variante per build è possibile utilizzare l'attività di copia gradle per mettere in scena il contenitore corretto.

+0

Grazie per la conferma. Penso che andrò con la fusione delle risorse per le risorse sovrascritte: http://tools.android.com/tech-docs/new-build-system/resource-merging – hidro

2

Questo è come abbiamo impostato il nostro progetto multi-sapore Gradle di utilizzare diversi contenitori GTM per ciascuna variante di costruzione:

/ 
|_app/ 
    |_src/ 
    |_flavor1/ 
    | |_google-services.json # Google services config for debug 
    | |_release/ 
    | |_google-services.json # Google services config for flavor1 
    |_flavor1Release/ 
    | |_assets/ 
    | |_containers/ 
    |  |_GTM-ABCXY1.json # GTM container for flavor1 
    | 
    |_flavor2/ 
    | |_google-services.json # Google services config for debug 
    | |_release/ 
    | |_google-services.json # Google services config for flavor2 
    |_flavor2Release/ 
    | |_assets/ 
    | |_containers/ 
    |  |_GTM-ABCXY2.json # GTM container for flavor2 
    | 
    |_debug/ 
    | |_assets/ 
    | |_containers/ 
    |  |_GTM-ABCXY3.json # GTM container for debug 
    | 
    |_main/ 
     |_res/ 
     |_java/ 

Supponendo di avere 2 sapori flavor1 e flavor2, e vogliono avere 3 contenitori GTM, 1 condivisa per la compilazione di debug di entrambi gli aromi e 1 per ciascuna versione di rilascio di ciascun aroma.

GTM si collegherà alla dashboard FA del progetto specificato dal vostro google-services.json. Il supporto multi-flavor di tipo multi-build google-services.json è disponibile dal plug-in versione 2.1.0 [1]