How do you restart a query using NSFetchedResultsController - iphone

I'm finishing up the Core Data tutorial, and it suggests trying to convert to using a NSFetchedResultsController. So I've got it so that I can query the existing data, but when I add a row at the beginning, tableView:cellForRowAtIndexPath calls NSFetchedResultsController.objectAtIndexPath, but that still returns the old zeroth object instead of the new one. Is there something I need to do to flush that data?

Have you set your view controller as the fetched results controller's delegate and implemented the NSFetchedResultsControllerDelegate protocol? If so, you should not have to perform the fetch again, the fetched results controller will invoke the delegate methods in response to changes.
(Note, though, the caution in NSFetchedResultsController documentation regarding the implementation of the table view data source methods.)

Nobody has answered yet, so I'll add my guess. It looks like this link might be relevant. The suggestion there is that calling either of these two methods should get an update for you:
-[NSManagedObjectContext processPendingChanges]
-[NSManagedObjectContext save]
Perhaps the documentation for NSManagedObjectContext will be useful.

There was a clue in the link that Naaf provided. Turns out that after doing the save, I needed to call -[NSFetchedResultsController performFetch] again.

Related

Refreshing CoreData Table?

I can refresh any non-CoreData loaded tableView by calling [nameoftableView reloadData];
But when I call this on my CoreData loaded TVC it does not reload the table. Does this work differently?
It does update it contents if I stop and start the app again - so that it reloads the database, so I know it has the updated content in it.
Cheers Jeff
Without details is difficult to know what is going on, but if you use a simple NSFetchRequest I think you need to execute the query and call reloadData again.
A simple note
I suggest you to use NSFetchedResultsController when dealing with Core Data and UITableViews. raywenderlich has a tutorial on how to use that class in Core Data.
First of all it allows you to deal with a lot of data displayed in a UITableView. In particular, if for the NSFetchRequest you use with, you set a batch size, data will be retrieved in "batches". For example, the first 10. Then if you scroll the other 10 and so on...
In addition you can deal with data changes (update, insertion or deletion) for free using NSFetchedResultsControllerDelegate class (Reference NSFetchedResultsControllerDelegate).
Hope it helps.

What could cause mergeChangesFromContextDidSaveNotification not to merge/invalidate objects that have been updated?

[EDIT: simplified version of the question]
mainMOC is the primary managed object context
editorMOC is a managed object context created in editorViewController with an undo manager so the user can edit a single managed object
after editorMOC saves, mainMOC refreshes the updated managed object in the notification handler for NSManagedObjectContextDidSaveNotification
In the save handler, if I use [mainMOC refreshObject:obj mergeChanges:YES] the updates to the object are not reflected in mainMOC post-refresh. If I use [mainMOC refreshObject:obj mergeChanges:NO] the object is invalidated and at the next fault the changes are reflected in the data loaded from the store.
QUESTION: Why would the object not reflect the update when mergeChanges:YES is specified?
[ORIGINAL QUESTION]
I have a core data based app with multiple managed object contexts. The app is complicated and proprietary so I cannot simply share code directly from the app. I have created a simple test app in an attempt to reproduce my issue but the test app doesn't exhibit the problem. I have not been able to find a logical difference between the implementations. I apologize for not posting sample code, I believe I explained the implementation well below. If something is not clear, please ask in the comments and I will do my best to clarify.
Here's my situation. Everything described below is running on the main thread.
The app has a primary managed object context called mainMOC that is accessed on the main thread and used with NSFetchedResultsControllers to display data in various table views.
I have a view controller called EditorViewController that allows editing of an existing object of a particular entity. This view controller creates it's own managed object context called editorMOC using the same persistent store coordinator with an undo manager so changes can be rolled back or saved when dismissing the editor.
EditorViewController is observing the NSManagedObjectContextDidSaveNotification. When this notification occurs, the notification handler calls [_mainMOC mergeChangesFromContextDidSaveNotification:notification] to merge the changes from editorMOC into mainMOC.
The table view controller that uses an NSFetchedResultsController is handling the controller delegate messages.
I have added NSLog output to look at look at what happens in all of the above steps and I have verified the following:
I can see that the object is modified and saved in the editor.
I can see that the NSManagedObjectContextDidSaveNotification is called and that the updated object is included.
I can see that the fetched results controller is receiving the controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: protocol message.
I can see that mainMOC is not reflecting the updates and that the updated object has not been invalidated by mergeChangesFromContextDidSaveNotification:.
If I quit and relaunch the app, the updates were committed
For reference, both my main app and test app implement the above functionality but the test app shows the updates merged correctly and the main app does not.
I am looking for suggestions on what would cause mergeChangesFromContextDidSaveNotification: not to successfully merge and/or invalidate the updated object.
Thanks!
The fetched results controller does not receive the controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: delegate message. Instead it sends it to the delegate in response to a change in the context. If that delegate message is being sent and does contain the proper object, then the main context is aware of the changes.
If so, then your error is most likely in the the code interfacing the fetched results controller and the tableview. Something is preventing the object from appearing correctly.
The issue I had that caused mergeChangesFromContextDidSaveNotification not to work was I created a new NSPersistentStoreCoordinator for each new NSManagedObjectContext. When I shared NSPersistentStoreCoordinator between all MOCs, mergeChangesFromContextDidSaveNotification works perfectly. Also, make sure mergeChangesFromContextDidSaveNotification is called on the thread that owns the MOC.
From the research I did, it is safe to share NSPersistentStoreCoordinator between threads for use with NSManagedObjectContext. NSManagedObjectContext will lock the persistent store as necessary.
One possible answer: you have a third MOC you didn't know was there / forgot about. (This happened to me.)
I had
mainMOC
editorMOC
viewerMOC which came about by accidentally misguided subclassing - it was supposed to be looking at the main MOC, but instead was creating its own and looking at a frozen state. The "checking for edits" relationship was going the other direction, because it was expected to be the "editor" in this scenario.
the notification is correctly invoking the callback, and the data is being merged correctly into the main MOC (which i could tell because the data was correct on relaunch)
note: refreshObject:mergeChanges: is not needed. it's something i tried, too, when it wasn't working, but the merge of the notification should take care of all the objects for you.
- (void)twinStackUpdated:(NSNotification *)notification {
[[self managedObjectContext] mergeChangesFromContextDidSaveNotification:notification];
}
not sure that this was your problem, but it might be someones, so there it is.
In an effort to accept something even though I don't have a definitive solution, here's what I've done to address this and the problem seems to be resolved.
I believe this was a cache issue with NSFetchedResultsController. I've since simplified this code and made sure that each NSFetchedResultsController uses it's own cache. I've been able to remove the call to 'refreshObject' and things seem to be working correctly.

Disable animation of UITableView with NSFetchedResultsController when many rows are being changed

In my UIView I've got a UITableView (UITV) which is controlled by an NSFetchedResultsController (NSFRC). The UIView is inside a UINavigationController.
When the view is about to be loaded/displayed I start some background activities which fetch data from a remote server (JSON) and parse into Core Data.
The NSFRC is being called when the parsing is done and the threaded NSManagedObjectContext have been merged into the main context.
The problem is that sometimes many rows are being inserted to Core Data at once, a lot of table cells are being added and there is quite a delay from that the actual fetching and parsing is done, until the rows are being displayed.
Now I wonder if anyone knows of any solution to, for example:
hook up a spinner to some "fetched results controller inserted all its rows for this time" (or something) notification/delegate call to at least tell the user that "something is going to show up soon"?
Or might the best solution simply be to not initialize the NSFRC until the background fetching and processing is completed?
Thanks!
If I understand your question correctly, you may want to look into the NSFetchedResultsControllerDelegate methods, with documentation available here: http://developer.apple.com/library/ios/#documentation/CoreData/Reference/NSFetchedResultsControllerDelegate_Protocol/Reference/Reference.html
There are delegate methods available for pre changes with controllerWillChangeContent:, post changes with controllerDidChangeContent and during changes with didChangeSection: and didChangeObject.
I hope it helps!
Rog

NSFetchedResultsControllerDelegate in a second view controller (not firing?)

I am running into an issue similar to the one described here: NSFetchedResultsControllerDelegate not firing
(the delegate for my NSFetchedResultsControllerDelegate are not being called on my second view controller)
I can't seem to get the proposed solutions to work. I have a main view that loads information from Core Data just fine, but when it pushes a separate controller (and passes the managed object to it), the delegate methods won't fire. I've read about 'mergeChangesFromContextDidSaveNotification' but I don't understand how to synchronize the two manage objects and/or get the delegate methods to be called.
Any help would be greatly appreciated. Thank you,
Mike
Note sure I understand your problem exactly but a NSFetchedResultsController only calls its delegate when something changes in the part of the Core Data object graph that the controller monitors. Simply passing a managed object between two view controllers doesn't change the Core Data graph itself and therefore does not fire the the delegate methods.
To fire the delegate you have to make a change to the data that the fetchedResults controller monitors. This means changing one of entities that the fetchedResults controller fetches. You either have to add or remove an instance of an entity or you have to change an attribute or relationship of an existing entity.
...but I don't understand how to
synchronize the two manage objects
and/or get the delegate methods to be
called.
From your description, you don't have two managed objects but just one that is passed from the first view controller to the next. Perhaps you meant managed object context?
mergeChangesFromContextDidSaveNotification:
... is a method of NSManagedObjectContext and is only used when you have need to combine the data from two separate context. That is an advanced operation that you only use when you are trying to integrate the data of two independent context. For example, when you are updating a database to a new version.

Do I need to update the table view manually after calling performFetch in a Core Data app?

I'm new to this Core Data business.
I got a UITableViewController hooked up with a NSFetchedResultsController. In viewDidLoad, I fire a request to get necessary data from the server, then use [self.fetchedResultsController performFetch:&error] to update the table view. All works fine until that point.
Now I want to move the data fetching stuff to another thread, so after the app received a NSArray object from the server, it performs the didFinishFetchingItems selector on the main thread. In that selector, I save the NSArray to the Core Data store and have the fetchedResultsController perform a fetch. No data show up, although a NSLog reveals that the data is still there (e.g. [[fetchedResultsController fetchedObjects] count] returns 100). I have to put a [self.tableView reloadData] at the end of the method to refresh the table view manually.
My question is: What have I done wrong? Why did I need to do the table view refreshing manually?
You should not touch your NSFetchedResultsController in a non-main thread, that is not a thread-safe operation.
If you are having a long delay on fetching then you need to do a background fetch using a separate NSManagedObjectContext. If you perform a separate fetch in the background it will load the data into cache and then the NSFetchedResultsController will hit the cache instead of disk, speeding up retrieval on the main thread.
You do not need to refresh anything manually; fetchedResultsController does that for you.
What you need to do is to implement NSFetchedResultsControllerDelegate for some object, and set that object as the delegate for your fetchedresultscontroller.
See this about what you need to implement. If your model is simple, you can pretty much copy-paste that code into your delegate and everything works.
The important thing is to keep both the resultscontroller and other pieces of code working against the same managed object context. This is how the resultscontroller can pick up the changes. But, in Core Data guide, there are some caveats about multithreading, so make sure you have your threading bases covered and then all works.