Najlepsze praktyki w kontekście podstawowych danych

Po pierwsze, kontekst rodzica/dziecka nie służy do przetwarzania w tle. Służą one do atomowych aktualizacji powiązanych danych, które mogą być tworzone w wielu kontrolerach widoku. Więc jeśli ostatni kontroler widoku zostanie anulowany, kontekst potomny może zostać wyrzucony bez niekorzystnego wpływu na rodzica. Jest to w pełni wyjaśnione przez Apple na dole tej odpowiedzi na [^1]. Teraz, że jest z drogi i nie dał się nabrać na wspólny błąd, można skupić się na tym, jak prawidłowo zrobić background Core Data.

Utwórz nowy koordynator trwałego sklepu (nie jest już potrzebny w systemie iOS 10, patrz aktualizacja poniżej) i kontekst kolejki prywatnej. Posłuchaj powiadomienia o zapisaniu i połącz zmiany z głównym kontekstem (w systemie iOS 10 kontekst ma właściwość, która robi to automatycznie)

Dla przykładu Apple zobacz "Earthquakes: wypełnianie podstawowego magazynu danych za pomocą kolejki w tle" https://developer.apple.com/library/mac/samplecode/Earthquakes/Introduction/Intro.html Jak widać z historia zmian w dniu 2014-08-19 dodali "Nowy przykładowy kod, który pokazuje, jak używać drugiego rdzenia stosu danych do pobierania danych z kolejki w tle."

Oto bit z AAPLCoreDataStackManager.m:

// Creates a new Core Data stack and returns a managed object context associated with a private queue.
- (NSManagedObjectContext *)createPrivateQueueContext:(NSError * __autoreleasing *)error {

    // It uses the same store and model, but a new persistent store coordinator and context.
    NSPersistentStoreCoordinator *localCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:[AAPLCoreDataStackManager sharedManager].managedObjectModel];

    if (![localCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil
                                                  URL:[AAPLCoreDataStackManager sharedManager].storeURL
                                              options:nil
                                                error:error]) {
        return nil;
    }

    NSManagedObjectContext *context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType];
    [context performBlockAndWait:^{
        [context setPersistentStoreCoordinator:localCoordinator];

        // Avoid using default merge policy in multi-threading environment:
        // when we delete (and save) a record in one context,
        // and try to save edits on the same record in the other context before merging the changes,
        // an exception will be thrown because Core Data by default uses NSErrorMergePolicy.
        // Setting a reasonable mergePolicy is a good practice to avoid that kind of exception.
        context.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy;

        // In OS X, a context provides an undo manager by default
        // Disable it for performance benefit
        context.undoManager = nil;
    }];
    return context;
}

Oraz w AAPLQuakesViewController.m

- (void)contextDidSaveNotificationHandler:(NSNotification *)notification {

    if (notification.object != self.managedObjectContext) {

        [self.managedObjectContext performBlock:^{
            [self.managedObjectContext mergeChangesFromContextDidSaveNotification:notification];
        }];
    }
}

Oto pełny opis jak zaprojektowana jest próbka:

Earthquakes: Using a "private" persistent store coordinator to fetch data in background

Większość aplikacji wykorzystujących Podstawowe Dane zatrudniaj jednego koordynatora sklepu trwałego, aby pośredniczył w dostępie do danego sklepu trwałego. Earthquakes pokazuje, jak używać dodatkowego" prywatnego " stałego koordynatora sklepu podczas tworzenia zarządzanych obiektów przy użyciu danych pobranych ze zdalnego serwera.

Architektura Aplikacji

Aplikacja wykorzystuje dwa podstawowe "stosy" danych (zdefiniowane przez istnienie stałego koordynatora sklepu). Pierwszy jest typowym stosem "ogólnego przeznaczenia"; drugi jest tworzony przez Widok kontroler specjalnie do pobierania danych ze zdalnego serwera(od iOS 10 drugi koordynator nie jest już potrzebny, patrz aktualizacja na dole odpowiedzi).

Główny koordynator persistent store jest zwracany przez obiekt singleton "stack controller" (instancję CoreDataStackManager). Zadaniem jej klientów jest stworzenie zarządzanego kontekstu obiektu do współpracy z koordynatorem [^1]. Kontroler stosu wysyła również właściwości dla zarządzanego modelu obiektowego używanego przez aplikację oraz miejsce przechowywania. Klienci mogą użyć tych ostatnich właściwości, aby skonfigurować dodatkowych stałych koordynatorów sklepu, aby pracowali równolegle z głównym koordynatorem.

Główny kontroler widoku, instancja kontrolera QuakesViewController, używa koordynatora persistent store kontrolera stosu do pobierania quakes ze sklepu persistent do wyświetlenia w widoku tabeli. Pobieranie danych z serwera może być długotrwałą operacją wymagającą znaczącej interakcji z trwały sklep, aby określić, czy rekordy pobrane z serwera są nowymi wstrząsami lub potencjalnymi aktualizacjami istniejących wstrząsów. Aby zapewnić, że aplikacja będzie reagować podczas tej operacji, kontroler widoku zatrudnia drugiego koordynatora do zarządzania interakcją ze sklepem trwałym. Konfiguruje koordynatora tak, aby korzystał z tego samego managed object model i persistent store, co koordynator główny zarządzany przez kontroler stosu. Tworzy zarządzany kontekst obiektu związany z Kolejka prywatna do pobierania danych ze sklepu i zatwierdzania zmian w sklepie.

[^1]: Obsługuje to podejście "podaj pałeczkę", w którym-szczególnie w aplikacjach iOS-kontekst jest przekazywany z jednego kontrolera widoku do drugiego. Główny kontroler widoku jest odpowiedzialny za tworzenie początkowego kontekstu i przekazywanie go do kontrolerów widoku potomnego w razie potrzeby.

Powodem tego wzorca jest zapewnienie, że zmiany w zarządzanym wykresie obiektów są odpowiednio ograniczone. Rdzeń Dane obsługują" zagnieżdżone " zarządzane konteksty obiektów, które pozwalają na elastyczną architekturę ułatwiającą obsługę niezależnych, anulowalnych zestawów zmian. W kontekście podrzędnym można zezwolić użytkownikowi na wprowadzenie zestawu zmian w zarządzanych obiektach, które następnie mogą zostać przekazane hurtowo rodzicowi (i ostatecznie zapisane w sklepie) jako pojedyncza transakcja lub odrzucone. Jeśli wszystkie części aplikacji po prostu pobierają ten sam kontekst z, powiedzmy, delegata aplikacji, powoduje to zachowanie trudne lub niemożliwe do utrzymania.

Aktualizacja: w iOS 10 Apple przeniosło synchronizację z poziomu pliku SQLITE do stałego koordynatora. Oznacza to, że możesz teraz utworzyć prywatny kontekst kolejki i ponownie użyć istniejącego koordynatora używanego przez główny kontekst bez tych samych problemów z wydajnością, które miałbyś robiąc to w ten sposób wcześniej, cool!

Przy okazji ten dokument firmy Apple wyjaśnia ten problem bardzo wyraźnie. Wersja Swift dla wszystkich zainteresowanych

let jsonArray = … //JSON data to be imported into Core Data
let moc = … //Our primary context on the main queue

let privateMOC = NSManagedObjectContext(concurrencyType: .PrivateQueueConcurrencyType)
privateMOC.parentContext = moc

privateMOC.performBlock {
    for jsonObject in jsonArray {
        let mo = … //Managed object that matches the incoming JSON structure
        //update MO with data from the dictionary
    }
    do {
        try privateMOC.save()
        moc.performBlockAndWait {
            do {
                try moc.save()
            } catch {
                fatalError("Failure to save context: \(error)")
            }
        }
    } catch {
        fatalError("Failure to save context: \(error)")
    }
}

I jeszcze prostsze, jeśli używasz NSPersistentContainer dla iOS 10 i nowszych

let jsonArray = …
let container = self.persistentContainer
container.performBackgroundTask() { (context) in
    for jsonObject in jsonArray {
        let mo = CarMO(context: context)
        mo.populateFromJSON(jsonObject)
    }
    do {
        try context.save()
    } catch {
        fatalError("Failure to save context: \(error)")
    }
}