Una trappola importante in cui mi sono imbattuto oggi è la seguente:
In molti progetti ho visto un'unica destinazione dell'app e con diversi identificatori di bundle impostati per ogni configurazione di quella destinazione. Qui le cose si complicano. L'obiettivo degli sviluppatori era creare un'app di debug per la configurazione di debug e un'app di produzione per l'obiettivo di rilascio.
Se lo fai, entrambe le app condivideranno gli stessi NSUserDefaults quando sono impostate in questo modo
var userDefaults = NSUserDefaults(suiteName: "group.com.company.myApp")
userDefaults!.setObject("user12345", forKey: "userId")
userDefaults!.synchronize()
Ciò causa problemi in molti punti:
- Immagina di impostare SÌ per una chiave quando una speciale schermata introduttiva dell'app è stata mostrata all'utente. Anche l'altra app ora leggerà SÌ e non mostrerà l'introduzione.
- Sì, alcune app memorizzano anche token oAuth nelle impostazioni predefinite dell'utente. Comunque ... A seconda dell'implementazione, l'app riconoscerà che c'è un token e inizierà a recuperare i dati usando il token sbagliato. È molto probabile che questo fallisca con strani errori.
La soluzione a questo problema in generale è anteporre alle chiavi di default la configurazione corrente creata. È possibile rilevare facilmente la configurazione in fase di esecuzione impostando diversi identificatori di bundle per le proprie configurazioni. Quindi leggi l'identificatore del bundle da NSBundle.mainBundle()
. Se hai gli stessi identificatori di bundle, devi impostare diverse macro del preprocessore come
#ifdef DEBUG
NSString* configuration = @"debug";
#elif RELEASE
NSString* configuration = @"release";
#endif
In Swift sembrerà quasi lo stesso:
#if DEBUG
let configuration = "debug"
#elseif RELEASE
let configuration = "release"
#endif