iOS5.1: sincronizzazione delle attività (attendere il completamento)

Question

Ho un problema di base durante la sincronizzazione di openWithCompletionHandler: (UIManagedDocument) con le attività principali.

Situazione: Ho una classe singleton che gestisce un UIManagedDocument condiviso. Questa classe fornisce un metodo che dovrebbe fornire il documento in uno stato normale (ad esempio lo crea o lo apre, qualunque sia necessario). Ma poiché openWithCompletionHandler: esegue il suo lavoro principale in modo asincrono in background, il mio programma dovrebbe attendere con l'impostazione di fetchedResultsController fino a quando il documento non è realmente aperto. Il metodo "viewWillAppear" (al momento) non produce output utili quando il database non è pronto. L'attesa sarebbe ok per me, ma ricevere una notifica probabilmente sarebbe il modo migliore. Forse viewWillAppear risulta non essere il punto giusto per setupFetchedResultsController perché non viene chiamato in un runloop.

Esiste uno schema standard per raggiungere questo obiettivo?

Un po 'più di sfondo (non è così importante presumo) Sto lavorando su una piccola app iOS 5.1 che coinvolge un UDanagedDocument CoreData. Ho assomigliato all'esempio della lezione 14 del corso Stanford dello scorso autunno in iTunes-U. Tutto funzionava bene fino a quando ho provato a spostare la gestione di UIManagedDocument dalla classe UITableViewController in una classe separata che gestiva il mio documento. Nella versione originale il FetchedResultsController è stato impostato nel gestore di completamento.

Answer 1

Suggerisco di seguire l'eccellente post Justin Driscoll su Core Data with a Single Shared UIManagedDocument.

Troverete una completa descrizione su UIManagedDocument singleton e un esempio su performWithDocument. Il tuo codice di setup Recuperato con il controllo del recupero dovrebbe davvero andare nel blocco performWithDocument:^{}.

Si noti inoltre che openWithCompletionHandler non è thread-safe: le chiamate simultanee di performWithDocument durante l'apertura del documento causano un arresto anomalo. La soluzione per me era non banale (e abbastanza specifica per le app), quindi se ti imbatti nello stesso problema, ti suggerisco di esaminare UIDocumentStateChangedNotification che notifica le modifiche allo stato del documento e può essere il tuo punto di sincronizzazione per più apri documenti.

Alcuni frammento, se siete interessati,

Prima in init di MYDocumentHandler, messa a punto una notifica supplementare alla fine:

[[NSNotificationCenter defaultCenter] addObserver:self 
              selector:@selector(documentStateDidChange:) 
               name:UIDocumentStateChangedNotification 
               object:self.document]; 

Poi, nel performWithDocument, @synchronized (self.document) sulla aperta critica/sezioni di creazione per assicurarsi che entri solo un thread alla volta e bloccare ulteriori thread fino a quando l'apertura/creazione non riesce.

aggiungere infine la seguente funzione:

- (void)documentStateDidChange:(NSNotification *)notification 
{ 
    if (self.document.documentState == UIDocumentStateNormal) 
     @synchronized (self.document) { 
      ... unblock other document openers ... 
     } 
} 

Quanto blocco/sblocco fili, YMMV. Ho usato un dispatch_semaphore_t insieme ad alcuni dispatch_queues per soddisfare i requisiti specifici dell'app. Il tuo caso potrebbe essere semplice come aspettare il completamento o far cadere altri thread.