Un piège important dans lequel j'ai puisé aujourd'hui est le suivant:
Dans de nombreux projets, j'ai vu une seule cible d'application et différents identifiants de bundle définis pour chaque configuration de cette cible. Ici, les choses se compliquent. L'objectif des développeurs était de créer une application de débogage pour la configuration de débogage et une application de production pour la cible de publication.
Si vous le faites, les deux applications partageront les mêmes NSUserDefaults lorsqu'elles sont configurées comme suit
var userDefaults = NSUserDefaults(suiteName: "group.com.company.myApp")
userDefaults!.setObject("user12345", forKey: "userId")
userDefaults!.synchronize()
Cela pose des problèmes dans de nombreux endroits:
- Imaginez que vous définissiez OUI pour une clé lorsqu'un écran d'introduction d'application spécial a été montré à l'utilisateur. L'autre application lira désormais également OUI et ne montrera pas l'intro.
- Oui, certaines applications stockent également les jetons oAuth dans leurs paramètres par défaut. Quoi qu'il en soit ... En fonction de l'implémentation, l'application reconnaîtra qu'il y a un jeton et commencera à récupérer des données en utilisant le mauvais jeton. Il y a de fortes chances que cela échoue avec d'étranges erreurs.
La solution à ce problème en général est de préfixer les clés par défaut avec la configuration actuelle construite. Vous pouvez détecter facilement la configuration au moment de l'exécution en définissant différents identificateurs de bundle pour vos configurations. Ensuite, lisez simplement l'identifiant du bundle à partir de NSBundle.mainBundle()
. Si vous avez les mêmes identifiants de bundle, vous devez définir différentes macros de préprocesseur comme
#ifdef DEBUG
NSString* configuration = @"debug";
#elif RELEASE
NSString* configuration = @"release";
#endif
Dans Swift, ce sera presque le même:
#if DEBUG
let configuration = "debug"
#elseif RELEASE
let configuration = "release"
#endif