Jak zsynchronizować CoreData i usługę REST web service asynchronicznie i w tym samym czasie poprawnie propagować wszelkie błędy REST do interfejsu użytkownika

Istnieją trzy podstawowe składniki:

1. akcja UI i utrzymanie zmiany na CoreData
2. utrzymanie tej zmiany na serwerze
3. Odświeżanie interfejsu użytkownika z odpowiedzią serwera

Nsoperation + NSOperationQueue pomoże uporządkować żądania sieci. Protokół delegata pomoże klasom interfejsu zrozumieć, w jakim stanie są żądania sieciowe, coś w stylu:

@protocol NetworkOperationDelegate
  - (void)operation:(NSOperation *)op willSendRequest:(NSURLRequest *)request forChangedEntityWithId:(NSManagedObjectID *)entity;
  - (void)operation:(NSOperation *)op didSuccessfullySendRequest:(NSURLRequest *)request forChangedEntityWithId:(NSManagedObjectID *)entity;
  - (void)operation:(NSOperation *)op encounteredAnError:(NSError *)error afterSendingRequest:(NSURLRequest *)request forChangedEntityWithId:(NSManagedObjectID *)entity;
@end

Format protokołu będzie oczywiście zależał od Twojego konkretny przypadek użycia, ale zasadniczo to, co tworzysz, to mechanizm, za pomocą którego zmiany mogą być "popychane" na twój serwer.

Następnie należy wziąć pod uwagę pętlę interfejsu użytkownika, aby zachować czystość kodu, dobrze byłoby wywołać save: i automatycznie przenieść zmiany na serwer. W tym celu możesz użyć powiadomień NSManagedObjectContextDidSave.

- (void)managedObjectContextDidSave:(NSNotification *)saveNotification {
  NSArray *inserted = [[saveNotification userInfo] valueForKey:NSInsertedObjects];
  for (NSManagedObject *obj in inserted) {
    //create a new NSOperation for this entity which will invoke the appropraite rest api
    //add to operation queue
  }

  //do the same thing for deleted and updated objects
}

Obciążenia obliczeniowe do wprowadzania operacji sieciowych powinny być raczej niskie, jednak jeśli tworzy to zauważalne opóźnienie na interfejs użytkownika można po prostu pobrać identyfikatory elementów z powiadomienia Zapisz i utworzyć operacje w wątku w tle.

Jeśli Twoje API REST obsługuje grupowanie, możesz nawet wysłać całą tablicę naraz, a następnie powiadomić interfejs użytkownika, że wiele jednostek zostało zsynchronizowanych.

Jedynym problemem, który przewiduję, a dla którego nie ma "prawdziwego" rozwiązania jest to, że użytkownik nie będzie chciał czekać, aż jego zmiany zostaną wypchnięte na serwer, aby móc wprowadzić więcej zmian. Jedyny dobrym paradygmatem, na który się natknąłem jest to, że pozwalasz użytkownikowi na zachowanie edycji obiektów i wsadowanie ich edycji razem, gdy jest to właściwe, tzn. nie naciskasz na każde powiadomienie o zapisie.

Staje się to problemem synchronizacji, a nie łatwym do rozwiązania. Oto, co bym zrobił: w interfejsie użytkownika iPhone ' a użyj jednego kontekstu, a następnie za pomocą innego kontekstu (i innego wątku) Pobierz dane z usługi internetowej. Po tym wszystkim przejdź przez procesy synchronizacji / importowania zalecane poniżej, a następnie Odśwież swój interfejs po tym, jak wszystko zostało poprawnie zaimportowane. Jeśli coś pójdzie źle podczas uzyskiwania dostępu do sieci, po prostu Cofnij zmiany w kontekście spoza interfejsu użytkownika. To sporo pracy, ale myślę, że to najlepsze jak można się do tego zbliżyć.

Dane Podstawowe: Efektywny Import Danych

Podstawowe Dane: Zarządzanie Zmianami

Dane rdzeniowe: wielowątkowe z danymi rdzeniowymi

Potrzebujesz funkcji wywołania zwrotnego, która będzie działać w drugim wątku (tym, w którym dzieje się rzeczywista interakcja z serwerem), a następnie umieścić kod wyniku / informacje o błędzie pół-globalne dane, które będą okresowo sprawdzane przez wątek interfejsu. Upewnij się, że wirting liczby, która służy jako flaga jest atomowa lub masz zamiar mieć warunek wyścigu-powiedzmy, jeśli odpowiedź na błąd jest 32 bajtów potrzebujesz int (whihc powinien mieć atomic acces), a następnie zachować, że int w off / false / not-ready stan, aż twój większy blok danych zostanie napisany i dopiero wtedy napisz "true", aby odwrócić przełącznik, że tak powiem.

Dla skorelowanego zapisywania po stronie klienta musisz albo zachować te dane, a nie zapisać je, dopóki nie otrzymasz OK z serwera upewnij się, że masz kinnf opcji rollback-powiedzmy, że sposób na usunięcie jest server failed.

Uważaj, że nigdy nie będzie w 100% bezpieczny, chyba że wykonasz PEŁNĄ 2-fazową procedurę commit (Client save lub delete może zawieść po sygnale z serwera), ale to będzie kosztować 2 wycieczki na serwer co najmniej (może kosztować 4, Jeśli jedyną opcją rollback jest Usuń).

Najlepiej zrobić całą blokującą wersję operacji na osobnym wątku, ale do tego potrzebujesz 4.0.