NSUserDefaults persiste tramite un aggiornamento a un'app nell'Appstore?

106

È questo il caso? NSUserDefaults viene ripristinato quando si invia un aggiornamento a un'app sull'App Store o vengono ripristinati?

La mia app si arresta in modo anomalo quando viene aggiornata ma non si arresta in modo anomalo quando viene scaricata completamente, quindi sto cercando di determinare cosa potrebbe essere diverso nella sessione aggiornata rispetto alla sessione appena scaricata.

Salute, Nick.

iphone crash nsuserdefaults

— Nick Cartwright
fonte

I file in Documents e Library verranno conservati come afferma la documentazione: developer.apple.com/library/ios/#DOCUMENTATION/iPhone/…

— Geri Borbás

116

Di solito non vengono ripristinati a meno che l'utente non elimini l'app. Per i dati di base, NSUserDefaults è il modo migliore per salvare dati come preferenze, date, stringhe, ecc. Se stai cercando di salvare immagini e file, il file system è una scommessa migliore.

— coneybeare
fonte

5

C'è da qualche parte nella documentazione di Apple questo è menzionato?

— Nick Cartwright,

1

Scusa, ho dimenticato di ringraziarti per la tua rapida risposta! - Se qualcuno può trovare un collegamento a qualsiasi forma di documentazione Apple che dice questo, sarebbe eccellente .... Nella documentazione per NSUserDefaults non dice nulla al riguardo, quindi penso di aver (erroneamente) presunto che i valori predefiniti vengano cancellati. Questo sembrerebbe il modo più sicuro per Apple di aggiornare sicuramente le app!

— Nick Cartwright

Potrebbe essere il modo più sicuro, ma sarebbe incredibilmente fastidioso per gli utenti se dovessero reimpostare tutte le loro preferenze ogni volta che un'app viene aggiornata. In genere ho tre o quattro aggiornamenti dell'app al giorno; Sono sicuro che altri utenti iPhone ne hanno ancora di più. La cancellazione delle preferenze per ogni aggiornamento renderebbe sostanzialmente inutilizzabile il mio iPhone.

— Kristopher Johnson,

1

I dati nella cartella dei documenti possono scomparire con la stessa facilità di NSUserDefaults. Sono entrambe occasioni rare, tuttavia, e non hanno assolutamente nulla a che fare con il normale processo di aggiornamento

— coneybeare

1

Grazie Kristopher - e sì, sono d'accordo. Il mio problema era che avevo usato NSUserDefaults per memorizzare eventi programmatici e mi ero affidato al fatto che venissero ripristinati quando l'app è stata installata. Tutti i miei test sul dispositivo iPhone (e sui test Apple) hanno testato l'app come una nuova installazione. Senza alcuna documentazione o modo per testare come aggiornamento, non sono stato in grado di ripetere il crash dell'aggiornamento che tutti i nostri clienti stanno riscontrando. Per riassumere: probabilmente una lezione imparata nel modo più duro !!

— Nick Cartwright,

7

Credo che la risposta sia SI, persisterà. Questo è anche completamente documentato nel capitolo Directory applicazioni nella Guida alla programmazione del sistema operativo Apple iPhone.

— leon
fonte

4

Risposta diretta alla domanda pubblicata: SI.
Il tuo problema: la tua app si arresta in modo anomalo a causa di problemi di logica. Supponi di memorizzare un oggetto nei valori predefiniti e l'app controlla il suo valore all'avvio (o altrove). Durante l'aggiornamento potresti cambiare il modo in cui viene controllato o utilizzato, ad esempio ti aspetti un valore, ma l'oggetto è nullo o viceversa. Ciò potrebbe causare un SIGABRT o EXC_BAD_ACCESS.

— John Smith
fonte

2

Se avevi il modello CoreData e hai cambiato qualcosa nel tuo modello e l'aggiornamento, senza gestire la migrazione, questo è probabilmente il motivo per cui la tua app si arresta in modo anomalo durante l'aggiornamento ...

— Bojan Bozovic
fonte

Mi aspetto che potrebbe essere un caso :) non un NSUserdefault

— Julian Król

1

Ho un'esperienza simile. La nostra app memorizza un numero di versione in Settings.Bundle / Root.Plist. Questo viene visualizzato tramite l'app Impostazioni iPhone. Quello che troviamo è che su un'installazione il numero di versione viene caricato dall'app bundle, quindi il numero di versione è corretto. Su un aggiornamento tuttavia il numero di versione non cambia. Ciò dà l'impressione che l'utente stia eseguendo una versione precedente dell'app. Non abbiamo alcuna logica collegata al numero di versione, è solo per la visualizzazione (potrebbe essere utilizzata dal personale del contact center per la diagnosi dei guasti).

La nostra esperienza è che NSUserDefaults non viene cancellato quando un utente aggiorna la nostra app, ma nemmeno la visualizzazione delle impostazioni viene aggiornata.

— Derek Knight
fonte

0

Tieni presente questo caso, quando la tua app è in esecuzione in background e non puoi accedere ai valori archiviati in NSUserDefaults:

Eric:

Ci sono stati molti thread e bug su questo, ma mi sta succedendo di nuovo in ios 9. Ho un'app che si avvia in background in risposta alle attività NSURLSession e ai push di contenuti disponibili. Riproducibile, se riavvio il telefono e aspetto l'avvio in background della mia app, quando apro l'app scopro che [[NSUserDefaults standardUserDefaults] dictionaryRepresentation] contiene tutti i valori di sistema, ad esempio AppleITunesStoreItemKinds, ecc. Ma non contiene uno qualsiasi dei valori che ho impostato. Se esco forzatamente e riavvio l'app, tutti i miei valori tornano. C'è un modo per evitare che memorizzi nella cache gli standardUserDefaults "vuoti" da prima che il telefono venga sbloccato, o almeno per determinare quando sono incasinati e risolverli senza dover chiudere l'app?

Eskimo (eskimo1@apple.com):

Il problema qui è che NSUserDefaults è in definitiva supportato da un file nel contenitore della tua app e il contenitore della tua app è soggetto alla protezione dei dati. Se non fai nulla di speciale, su iOS 7 e versioni successive, il tuo contenitore utilizza NSFileProtectionCompleteUntilFirstUserAuthentication, un valore ereditato dall'archivio di backup di NSUserDefaults e quindi non puoi accedervi prima del primo sblocco.

IMO il modo migliore per aggirare questo è evitare NSUserDefaults per cose su cui fai affidamento nei percorsi di codice che possono essere eseguiti in background. Memorizza invece queste impostazioni nel tuo file delle preferenze, di cui puoi gestire la protezione dei dati in modo esplicito (in questo caso significa "impostato su NSFileProtectionNone").

Esistono due problemi con NSUserDefaults in un contesto di protezione dei dati:

È un'API completamente astratta: la presenza e l'ubicazione del suo backing store non sono considerate parte di quell'API, quindi non puoi gestirne esplicitamente la protezione dei dati.

Nota Nelle versioni recenti di OS X NSUserDefaults è gestito da un demone e le persone che tentano di manipolare direttamente il suo archivio di backup hanno riscontrato problemi. È facile immaginare lo stesso genere di cose in arrivo su iOS ad un certo punto.

Anche se la modifica della protezione dei dati fosse possibile, NSUserDefaults non ha alcun meccanismo per classificare i dati in base al contesto in cui li stai utilizzando; è un'API "tutto o niente". Nel tuo caso non vuoi rimuovere la protezione da tutte le impostazioni predefinite dell'utente, solo quelle a cui devi accedere in background prima del primo sblocco.

Infine, se qualcuno di questi dati è veramente sensibile, dovresti metterlo nel portachiavi. In particolare, il portachiavi ha la capacità di impostare la protezione dei dati articolo per articolo.

Fonte: https://webcache.googleusercontent.com/search?q=cache:sR9eZNHpZtwJ:https://forums.developer.apple.com/thread/15685

— Grand M
fonte