UIDocument & NSFileWrapper - NSFastEnumerationMutationHandler durante la modifica del file wrapper durante un salvataggio

Question

Ho un'app basata su UIDocument che utilizza NSFileWrapper s per archiviare i dati. Il wrapper di file "master" contiene molti wrapper di file di directory aggiuntivi, ognuno dei quali rappresenta una pagina diversa del documento.

Ogni volta che apporto una modifica al documento mentre è in corso il salvataggio dello UIDocument (in writeContents:andAttributes:safelyToURL:forSaveOperation:error:), l'app si arresta in modo anomalo. Ecco l'analisi dello stack:

Sembra chiaro che sto modificando la stessa istanza di involucro di file che il UIDocument enumera sopra in background. Effettivamente, ho verificato che quando si restituisce un'istantanea del modello di dati in contentsForType:error:, i wrapper del file secondario restituiti puntano agli stessi oggetti di quelli attualmente residenti (e in fase di modifica) nel modello di dati e non alle copie.

- (id)contentsForType:(NSString *)typeName error:(NSError *__autoreleasing *)outError 
{ 
    if (!_fileWrapper) { 
     [self setupEmptyDocument]; 
    } 
    return [[NSFileWrapper alloc] initDirectoryWithFileWrappers:[_fileWrapper fileWrappers]]; 
} 

Questo è l'approccio sanzionato per l'attuazione di questo metodo (secondo WWDC 2012 Session 218 - Using iCloud with UIDocument).

Quindi suppongo che la domanda sia: In che modo questo approccio può essere sicuro?

La situazione è in qualche modo diversa quando i wrapper del file master fileWrappers sono essi stessi wrapper di file di directory? Se l'approccio sanzionato è sbagliato, come dovrebbe essere ?

Answer 1

Se si sta chiamando uno dei metodi writeContents:..., non si dovrebbe. Dovresti chiamare lo saveToURL:forSaveOperation:completionHandler:. I metodi writeContents:... sono pensati per la sottoclasse avanzata.

UIDocument utilizza due thread - il thread principale e il filo "UIDocument File Access" (che, se si sottoclasse più UIDocument, si possono fare le cose in via).

La sicurezza del thread con UIDocument è simile a qualsiasi cosa in Objective C - consente solo al thread proprietario di un oggetto di modificarlo. Se l'oggetto che si desidera modificare è in fase di lettura, accodalo per essere modificato al termine della scrittura. È possibile modificare un altro oggetto di proprietà della sottoclasse UIDocument e inserirli in un nuovo NSFileWrapper in contentsForType:error:. Passa una copia del file wrapper NSDictionary.

NSFileWrapper carica effettivamente l'intero documento in memoria. Lo NSFileWrapper viene effettivamente creato nella discussione "Accesso file UIDocument" nel metodo readFromURL:error:, che viene quindi passato al metodo loadFromContents:ofType:error:. Se hai un documento di grandi dimensioni questo può richiedere un po 'di tempo.

Quando si effettua il salvataggio, in genere si desidera consentire a UIDocument di decidere quando eseguire questa operazione e far sapere che qualcosa è cambiato tramite il metodo updateChangeCount: (il parametro è UIDocumentChangeDone). Se vuoi risparmiare qualcosa al momento vuoi utilizzare il metodo saveToURL:forSaveOperation:completionHandler:.

Un'altra cosa da notare è UIDocument implementa il protocollo NSFilePresenter, che definisce i metodi per NSFileCoordinator da utilizzare. Il UIDocument coordina solo la scrittura sul documento radice, non i file secondari.Potresti pensare che coordinare i file secondari all'interno del documento possa essere d'aiuto, ma il crash che stai ottenendo è legato alla mutazione di un dizionario mentre viene iterato, quindi non ti aiuterà. Devi solo preoccuparti di scrivere il tuo NSFilePresenter se (1) vuoi ricevere le notifiche delle modifiche ai file o (2) un altro oggetto o app sta leggendo/scrivendo sullo stesso file. Che cosa fa già UIDocument funzionerà correttamente. Tuttavia, si consiglia di utilizzare NSFileCoordinator durante lo spostamento/eliminazione di interi documenti.