Mam aplikację opartą na UIDocument, która używa NSFileWrapper s do przechowywania danych. Opakowanie "master" zawiera wiele dodatkowych obwolut plików katalogowych, z których każdy reprezentuje inną stronę dokumentu.UIDocument i NSFileWrapper - NSFastEnumerationMutationHandler podczas zmiany pakowania pliku podczas zapisywania
Ilekroć dokonuję zmiany w dokumencie, gdy zapisuje się UIDocument (w writeContents:andAttributes:safelyToURL:forSaveOperation:error:), aplikacja ulega awarii. Oto ślad stosu:
Wydaje się oczywiste, że jestem taką samą modyfikację instancję pliku wrapper że UIDocument wylicza się w tle. Rzeczywiście, sprawdziłem, że zwracając migawkę modelu danych w contentsForType:error:, zwinięte obwoluty pliku podrzędnego wskazują te same obiekty, które obecnie są rezydowane (i są edytowane) w modelu danych, a nie kopie.
- (id)contentsForType:(NSString *)typeName error:(NSError *__autoreleasing *)outError
{
if (!_fileWrapper) {
[self setupEmptyDocument];
}
return [[NSFileWrapper alloc] initDirectoryWithFileWrappers:[_fileWrapper fileWrappers]];
}
to karane podejściem do realizacji tego sposobu (według WWDC 2012 Session 218 - Using iCloud with UIDocument).
Więc przypuszczam, że pytanie brzmi: Jak to podejście może być bezpieczne dla wątków?
Czy sytuacja wygląda inaczej, gdy opakowanie zbiorcze pliku fileWrappers jest samo w sobie owijką pliku katalogowego? Jeśli usankcjonowane podejście jest błędne, należy je wykonać?
Nie natknąłem się na tę sytuację, ale wygląda na to, że NSFileCoordinator może wykonać to zadanie? –
@MikeM Możesz mieć rację, ponieważ zapobiegnie to awarii, ale obawiam się, że może naprawdę spowolnić działanie. Często aktualizacje w aplikacji są małe i częste, a aktualna treść jest wymagana, aby aplikacja mogła szybko reagować. Będę musiał zbadać to podejście dalej i sprawdzić, czy jest on wykonalny. Pozostaje jednak pytanie - czy sankcjonowane podejście do UIDocumentu nie jest bezpieczne? – Stuart