그래서 내가 직면 한 문제가 있습니다. NSFetchedResultsController에 의해 뒷받침되는 UITableView가 있습니다. 이제 응용 프로그램을 시작할 때 여러 네트워크 호출을 만들고 들어오는 데이터를 처리하는 데이터 소스를 업데이트합니다. 데이터 소스가 업데이트되는 동안 사용자가 행 중 하나를 삭제하면 비동기 네트워크 콜백에서 삭제 된 데이터에 액세스하면 앱이 충돌합니다. 이 시나리오를 정상적으로 처리하려면 어떻게합니까?삭제 후 CoreData 객체 액세스에 액세스하지 못하도록
개체에 액세스하기 전에 개체에 isDeleted (으)로 전화 해보세요.
NSFetchedResultsController의 메모리 추적을 사용하는 경우 레코드가 영구 저장소에서 제거되기 전에 인터페이스에서 레코드를 제거 할 수 있습니다. NSFetchedResultsController 대리자의 NSFetchedResultsChangeType을 읽고 개체가 삭제되는 백그라운드 스레드의 NSManagedObjectContext와 레코드를 읽는 NSManagedObjectContext를 병합했는지 확인하십시오.
개체가 삭제되었는지 확인하는 좋은 방법은 existingObjectWithID : error :를 사용하여 현재 개체 ID로 기존 개체를 확인하는 것입니다. 이것은 NSFetchedResultsController없이 NSManagedObjects를 사용할 때 매우 유용합니다.
백그라운드 스레드에서 업데이트가 진행되는 동안 주 스레드에서 삭제가 발생합니다. 비록 내가 existingObjectWithID : error :를 체크하더라도, 백그라운드 스레드에서, 체크가 끝난 후에 그 객체가 삭제된다는 것이 아주 잘 일어납니다. 어떻게 처리할까요? 기본적으로 삭제를 위해 삭제 업데이트 충돌을 해결하려면 어떻게해야합니까? –
핵심적인 데이터 문제보다 더 많은 아키텍처 문제가 있습니다. 이것은 멀티 스레딩 작업의 까다로운 부분입니다. 핵심 데이터의 경우 컨텍스트가 동기화되어 있는지 확인해야합니다. 개체가 메인 스레드에서 삭제되는 장소는 조작중인 개체/개체에 대한 변경 사항을 모니터링해야합니다. 객체를 업데이트하는 백그라운드 스레드와 동일한 작업. 이 방법은 개체가 주 스레드에서 삭제 된 경우 업데이트가 허용되지 않습니다. 하지만 먼저 디자인을 자세히 살펴보십시오. 이러한 유형의 조작을 처리하려면 직렬 대기열이 필요할 수 있습니다. – J2theC