Firebase + XCode
Il est courant maintenant d’utiliser Firebase dans les applications mobiles. Que ce soit pour la partie statistiques, les notifications ou le reporting des crashes. L’intégration est très facile, mais peut devenir compliquée dès lors qu’on manipule des target différentes avec des configurations différentes. Cet article va vous détailler une façon simple mais efficace de gérer ces différences.
Multiples fichiers plist
Les fichiers plist sont des fichiers XML de
configuration pour XCode. Lors de la création d’un
projet dans Firebase, il est possible de récupérer une version
générée contenant les bonnes variables pour votre projet. Le
problème qui peut se produire est lorsqu’on génère
plusieurs livrables avec des configurations qui doivent être
différentes grace aux target. Il n’est pas
possible, ni confortable, de gérer le cas de plusieurs
fichiers plist dans les sources. La redéfinition
du nom du fichier à faire utiliser par Firebase ne marche pas
à tous les coups et il a tendance à aller lire la valeur par
défaut GoogleService-Info.plist.
L’idée est donc d’utiliser un script au build qui
se chargera de configurer correctement le fichier
plist qui sera inclu dans le livrable.
Première étape : variabilisation
Pour être capable de générer le fichier
plist correctement, il est nécessaire de le
variabiliser. Dans mon cas, j’ai identifié les valeurs
suivantes qui devaient être variabilisées:
-
GOOGLE_APP_ID
-
BUNDLE_ID
-
CLIENT_ID
-
REVERSED_CLIENT_ID
J’ai donc ajouté des variables à la configuration de mon
build pour représenter ces valeurs qui doivent être
personnalisées. J’utilise des fichiers
.xcconfig mais ceci fonctionne également avec
l’ajout manuel (dans
Build Settings > + > Add User-Defined settings)
Unresolved directive in 2018-03-16-FirebasePListXCode.adoc - include::site/static/lightbox.adoc[]
En plus de ça, j’ai modifié le fichier
GoogleService-Info.plist téléchargé sur Firebase
pour enlever les éléments qui allaient être remplacés à terme.
Plus exactement, j’ai remplacé les valeurs par des
chaînes du type WILL BE REPLACED AT BUILD TIME,
qui me permettent facilement de me rendre compte d’un
oubli de configuration.
Deuxième étape : génération du fichier
Une fois le fichier et l’environnement préparé, il ne
reste qu’à générer la version finale. Pour se faire, je
me base sur le système de build de XCode qui permet
de définir simplement des étapes. Les variables définies dans
la configuration du projet sont en effet disponibles
simplement lors de l’exécution des étapes de
build. En utilisant l’outil
defaults inclu dans macOS pour la manipulation
des fichiers plist, il est donc facile de définir
les valeurs attendues dans le fichier. J’ai ainsi
rajouté une étape shell script correspondant à ceci
dans le processus de build.
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" GOOGLE_APP_ID ${GOOGLE_APP_ID}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" BUNDLE_ID ${PKG_IDENTIFIER}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" CLIENT_ID ${CLIENT_ID}
defaults write "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/GoogleService-Info.plist" REVERSED_CLIENT_ID ${REVERSED_CLIENT_ID}Enfin, il faut ordonner cette étape de build après celle de copie des ressources, pour effectuer la modification uniquement dans le fichier binaire de l’application et non dans les sources du projet.
Bénéfices
Il est donc facile de disposer de configuration différente de Firebase entre le debug et la release par exemple. Ainsi vous pouvez tester l’envoi de notification, par exemple, sans risquer de polluer des utilisateurs de production, ou activer le crash reporting uniquement en production par exemple.