I've got a NSPredicate on my FRC's fetchRequest. At some point an object is added to CoreData, I create a new predicate, update the fetchRequest and perform a fetch:
self.fetchedAddressesController.fetchRequest.predicate = self.predicate;
BOOL success = [self.fetchedAddressesController performFetch:nil];
This does however not invoke the FRC's delegate methods like controllerWillChangeContent:. And my table view is not updated.
However, when I add the following line:
[self.tableView reloadData];
below the two shown above, I do see the expected update. This shows that the data to be displayed has indeed changed.
I've checked the new predicate and it's fine. I also set FRC's delegate to self, and its methods are invoked in other cases.
Any ideas already what could be wrong?
The behaviour you have described is expected. According to the Apple documentation, if you want to modify a fetch request on a NSFetchedResultsController, you must delete the cache (if you are using one), modify the NSFetchRequest, then invoke performFetch: (which won't call any of the delegate methods).
If you want to know what has changed between the predicates, you need to store the old state and compare. A library that I've used in the past for this is Doppelganger.
The delegate methods are called when the FRC observes changes to the set of fetched objects it has eyes on after you do a fetch. If you go and change the predicate and do a new fetch, the FRC is reset and is now observing a different set of objects. The delegate methods aren't called because nothing changed in the original set of objects.
Careful if you are literally changing the entity...
We had a tricky one, not only the sort changed but the actual entity class changed, so for two different tab buttons,
let r = NSFetchRequest<NSFetchRequestResult>(entityName: "CD_Cats")
but then ..
let r = NSFetchRequest<NSFetchRequestResult>(entityName: "CD_Dogs")
In fact if you're doing that, THIS will NOT work:
func buttonLeft() {
mode = .cats
bringupFetchRequest()
pull.feedForCats() // get fresh info if any at the endpoints
}
func buttonRight() {
mode = .dogs
bringupFetchRequest()
pull.feedForDogs() // get fresh info if any at the endpoints
}
It will eventually crash.
It seems you need this:
func buttonLeft() {
mode = .cats
bringupFetchRequest()
tableView.reloadData()
pull.feedForCats() // get fresh info if any at the endpoints
}
func buttonRight() {
mode = .dogs
bringupFetchRequest()
tableView.reloadData()
pull.feedForDogs() // get fresh info if any at the endpoints
}
That (seems to) reliably work.
Related
I've come across an issue which rarely happens, and (of course) it works perfectly when I test it myself. It has only happened for a few users, and I know I have at least a couple hundred who use the same App daily.
The issue
When updating a list of coredata objects in a tableview, it not only updates the objects (correctly), it also creates duplicates of all these objects.
Coredata setup
It's a NSPersistentCloudKitContainer with these settings:
container.viewContext.automaticallyMergesChangesFromParent = true
container.viewContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
Tableview setup
I have a tableview which displays a list of the 'ActivityType' objects. It's very simple, they have a name (some other basic string/int properties), and an integer called 'index'. This 'index' exists so that users can change the order in which they should be displayed.
Here is some code for how each row is setup:
for activityType in activityTypes {
row = BlazeRow()
row.title = activityType.name
row.cellTapped = {
self.selectedActivityType(activityType)
}
row.object = activityType
row.cellReordered = {
(index) in
self.saveNewOrder()
}
section.addRow(row)
}
As you can see, it has 2 methods. One for selecting the activity which shows its details in a new viewcontroller, and one which is called whenever the order is changed.
Here's the method that is called whenever the order is changed:
func saveNewOrder() {
Thread.printCurrent()
let section = self.tableArray[0] as! BlazeSection
for (index, row) in section.rows.enumerated() {
let blazeRow = row as! BlazeRow
let object = blazeRow.object as! ActivityType
object.index = Int32(index)
}
BDGCoreData.saveContext()
}
And here's the code that saves the context (I use a singleton to easily access the viewcontext):
class func saveContext(context: NSManagedObjectContext = BDGCoreData.viewContext) {
if(context.hasChanges) {
do {
try context.save()
} catch {
let nserror = error as NSError
fatalError("Unresolved error \(nserror), \(nserror.userInfo)")
}
}
}
Now, I swear to god it never calls the method in this viewcontroller to create a new object:
let activity = ActivityType(context: BDGCoreData.viewContext). I know how that works, and it truly is only called in a completely different view controller. I searched for it again in my entire project just in case, and it's really never called/created in any other places.
But somehow, in very rase cases, it saves the correct new order but also duplicates all objects in this list. Since it only happens rarely, I thought it might have something to do with threads? Which is why, as you can see in the code, I printed out the current thread, but at least when testing on my device, it seems to be on the main thread.
I'm truly stumped. I have a pretty good understanding of coredata and the app itself is quite complex with full of objects with different kind of relationships.
But why this happens? I have no clue...
Does anyone have an idea?
My understanding on NSFetchedResultsController is that, it will not load entire all rows from CoreData at once.
Based on the current visible UI table row on screen, NSFetchedResultsController will just load a small amount of rows, just to be good enough to be shown on screen.
But, when I try to read and test the official code from Apple, this is contrast with my perception.
https://github.com/yccheok/earthquakes-WWDC20/blob/master/LoadingAndDisplayingALargeDataFeed/Earthquakes_iOS/QuakesViewController.swift#L123
There are around 10,000++ items in the CoreData database.
When the app is started for the 1st time, UITableView is not being scrolled yet, and the following function being executed for the 1st time
override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
var count = dataProvider.fetchedResultsController.fetchedObjects?.count ?? 0
print(">>> SIZE \(count)")
// Try to inspect the content...
var quake = dataProvider.fetchedResultsController.fetchedObjects?[count-1]
print("----> \(quake?.place)")
return count
}
When setting up NSFetchedResultController, I also try to change the batch size explicitly to 1, just to see what is the outcome - https://github.com/yccheok/earthquakes-WWDC20/blob/master/LoadingAndDisplayingALargeDataFeed/Shared/QuakesProvider.swift#L284
/**
A fetched results controller to fetch Quake records sorted by time.
*/
lazy var fetchedResultsController: NSFetchedResultsController<Quake> = {
// Create a fetch request for the Quake entity sorted by time.
let fetchRequest = NSFetchRequest<Quake>(entityName: "Quake")
fetchRequest.sortDescriptors = [NSSortDescriptor(key: "time", ascending: false)]
fetchRequest.propertiesToFetch = ["magnitude", "place", "time"]
// Just for testing purpose to avoid NSFetchedResultsController
// load all data at once into memory.
fetchRequest.fetchBatchSize = 1
// Create a fetched results controller and set its fetch request, context, and delegate.
let controller = NSFetchedResultsController(fetchRequest: fetchRequest,
managedObjectContext: persistentContainer.viewContext,
sectionNameKeyPath: nil, cacheName: nil)
controller.delegate = fetchedResultsControllerDelegate
// Perform the fetch.
do {
try controller.performFetch()
} catch {
fatalError("Unresolved error \(error)")
}
return controller
}()
When app launched for first time, the following outcome is printed
>>> SIZE 10902
----> Optional("43 km E of Teller, Alaska")
My questions are
Currently, there are only less than 20 visible UI table row shown on screen. But, it seems like CoreData has already load all 10,000++ rows at once? Is this an expected behaviour for NSFetchedResultsController. As, my understanding is having NSFetchedResultsController, is to avoid having to load all unnecessary data into memory in 1 time.
I do not see a way, on how UITableView communicate back to NSFetchedResultsController regarding the visible UI row range. Isn't UITableView suppose to tell NSFetchedResultsController that "Currently, UI row 0th till 14th are visible on screen. Please only load data in range 0th till 14th from CoreData database"?
Thanks.
You are mistaken in your understanding of NSFetchedResultsController and its purpose. It makes it easier to use Core Data with table views, particularly where objects are inserted, deleted or updated; You can use delegate methods to efficiently handle these actions without needing to reload the entire table view.
That said, there is a default behaviour of Core Data that means, in effect, only visible rows are loaded into memory regardless of whether you use an NSFetchedResultsController or not.
The default behaviour of Core Data is to only provide fault objects at first; A fault is a lightweight representation of an object. When a property of the object is accessed Core Data fetches the full object from the persistent store and loads it into memory.
This may have the effect of only loading full objects for on-screen rows since cellForRow(at:) is only called for visible rows (plus a few extra to allow for scrolling). If the only access to your fetched objects is in that function, then the faults will only fire for those rows.
As more rows become visible, cells will be required and more faults will fire, loading more data.
You can disable this faulting behaviour but it will increase memory use.
You can use UItableViewDataSourcePrefetching to fire faults ahead of display, but in many cases you won't see a difference in the UI.
I have written code like this to listen for changes in Post object.
notification = Post.allObjects(in: RLMRealm.encryptedRealm()! as! RLMRealm).addNotificationBlock({ (results, changes, error) in
let pred = NSPredicate(format: "tag == %#", self.postTag)
self.posts = CommonResult.objects(with: pred).sortedResults(usingKeyPath: "id", ascending: true)
if let _ = changes {
if (changes!.insertions.count > 0 || changes!.deletions.count > 0 || changes!.modifications.count > 0) {
self.tblListing.reloadData()
}
}
})
In my Post object, there are 2 property. One is 'rowHeight' and another is 'isLikeByMyself'.
I want to reload tableview only if 'isLikeByMyself' is changed. How shall I do? Is it possible?
You have at least two options.
If you don't have many Post objects, you may want to consider registering object notifications on each of them. Object notifications tell you which properties were changed and how, so you can use that information to reload the table view. However, you will need to register a separate notification on each Post object, which may not be practical if you have a large number of them.
Here is an alternate idea. Add an ignored boolean property to Post called something like isLikeWasChanged, and add a Swift didSet block that will set isLikeWasChanged to true any time you modify isLikeByMyself. Then, in your existing collection observation block, reload the table view only if at least one isLikeWasChanged is true, remembering to set them all back to false before you leave the block.
Before getting into my issue, please have a look at this image.
Here is the actual data model:
I retrieve a set of Records from a web API, create objects out of them, save them in core data and display them in the Today view. By default these records are returned for the current date.
The user can tap on Past button to go to a separate view where he can choose a past or future date from a date picker view and view Records for that selected date. This means I have to call the API again passing the selected date, retrieve the data and save that data in core data and display them. When the user leaves this view, this data should be discarded.
This is the important part. Even though I get a new set of data, the old original data for the current date in the Today view must not go away. So if/when the user returns to the Today view, that data should be readily available as he left it without the app having to call the API and get the data for the current date again.
I thought of creating a separate NSManagedObjectContext to hold these temporary data.
I have a separate class called DatabaseManager to handle core data related tasks. This class initializes with an instance of `NSManagedObjectContext. It creates the managed object classes in the given context.
import CoreData
import Foundation
import MagicalRecord
import SwiftyJSON
public class DatabaseManager {
private let context: NSManagedObjectContext!
init(context: NSManagedObjectContext) {
self.context = context
}
public func insertRecords(data: AnyObject, success: () -> Void, failure: (error: NSError?) -> Void) {
let json = JSON(data)
if let records = json.array {
for recordObj in records {
let record = Record.MR_createInContext(context) as Record
record.id = recordObj["Id"].int
record.name = recordObj["Name"].string!
record.date = NSDate(string: recordObj["Date"].string!)
}
context.MR_saveToPersistentStoreAndWait()
success()
}
}
}
So in the Today view I pass NSManagedObjectContext.MR_defaultContext() to insertRecords() method. I also have a method to fetch Records from the given context.
func fetchRecords(context: NSManagedObjectContext) -> [Record]? {
return Record.MR_findAllSortedBy("name", ascending: true, inContext: context) as? [Record]
}
The data is retrieved from the API, saved in core data and gets displayed successfully. All good so far.
In the Past View, I have to do basically the same thing. But since I don't want the original data to change. I tried to do this a few ways which MagicalRecord provides.
Attempt #1 - NSManagedObjectContext.MR_context()
I create a new context with NSManagedObjectContext.MR_context(). I change the date in Past view, the data for that selected date gets retrieved and saved in the database successfully. But here's the issue. When I fetch the objects from core data, I get that old data as well. For example, each day has only 10 records. In Today view I display 10 records. When the fetch objects in the Past view, I get 20 objects! I assume it's the old 10 objects plus the new ones. Also when I try to display them in the tableview, it crashes with a EXC_BAD_ACCESS error in the cellForRowAtIndexPath method.
override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) as UITableViewCell
let record = records[indexPath.row]
cell.textLabel?.text = record.name // EXC_BAD_ACCESS
cell.detailTextLabel?.text = record.date.toString()
return cell
}
Attempt #2 - NSManagedObjectContext.MR_newMainQueueContext()
The app crashes when I change the date with the following error.
'+entityForName: nil is not a legal NSPersistentStoreCoordinator for searching for entity name 'Record''
Attempt #3 - NSManagedObjectContext.MR_contextWithParent(NSManagedObjectContext.MR_defaultContext())
Same result as Attempt #1.
Attempt #4 - From Hal's Answer I learned that even though I create two MOCs, they both refer to the same NSPersistentStore. So I created another new store to hold the temporary data in my AppDelegate.
MagicalRecord.setupCoreDataStackWithStoreNamed("Records")
MagicalRecord.setupCoreDataStackWithStoreNamed("Records-Temp")
Then when I change the date to get the new data, I set that temporary store as the default store like this.
func getDate(date: NSDate) {
let url = NSPersistentStore.MR_urlForStoreName("Records-Temp")
let store = NSPersistentStore(persistentStoreCoordinator: NSPersistentStoreCoordinator.MR_defaultStoreCoordinator(), configurationName: nil, URL: url, options: nil)
NSPersistentStore.MR_setDefaultPersistentStore(store)
let context = NSManagedObjectContext.MR_defaultContext()
viewModel.populateDatabase(date, context: context)
}
Note that I'm using the default context. I get the data but it's the same result as Attempt 1 and 3. I get 20 records. They include data from both the old date and the new date. If I use NSManagedObjectContext.MR_context(), it would simply crash like in Attempt 1.
I also discovered something else. After creating the stores in App Delegate, I printed out the default store name println(MagicalRecord.defaultStoreName()) in the Today's view. Strangely it didn't print the name I gave the store which is Records. Instead it showed Reports.sqlite. Reports being the project's name. Weird.
Why do I get the old data as well? Am I doing something with when initializing a new context?
Sorry if my question is a little confusing so I uploaded a demo project to my Dropbox. Hopefully that will help.
Any help is appreciated.
Thank you.
Thread Safety
First of all I want to mention the Golden Rule of Core Data. NSManagedObject's are not thread safe, hence, "Thou shalt not cross the streams" (WWDC). What this means is that you should always access a Managed Object in its context and never pass it outside of its context. This is why your importer class worries me, you are inserting a bunch of objects into a context without guaranteeing that you are running the insert inside the Context.
One simple code change would fix this:
public func insertRecords(data: AnyObject, success: () -> Void, failure: (error: NSError?) -> Void) {
let json = JSON(data)
context.performBlock { () -> Void in
//now we are thread safe :)
if let records = json.array {
for recordObj in records {
let record = Record.MR_createInContext(context) as Record
record.id = recordObj["Id"].int
record.name = recordObj["Name"].string!
record.date = NSDate(string: recordObj["Date"].string!)
}
context.MR_saveToPersistentStoreAndWait()
success()
}
}
}
The only time you don't need to worry about this is when you are using the Main Queue Context and accessing objects on the main thread, like in tableview's etc.
Don't forget that MagicalRecord also has convenient save utilities that create context's ripe for saving :
MagicalRecord.saveWithBlock { (context) -> Void in
//save me baby
}
Displaying Old Records
Now to your problem, the following paragraph in your post concerns me:
The user can tap on Past button to go to a separate view where he can
choose a past or future date from a date picker view and view Records
for that selected date. This means I have to call the API again
passing the selected date, retrieve the data and save that data in
core data and display them. When the user leaves this view, this data
should be discarded.
I don't like the idea that you are discarding the information the user has requested once they leave that view. As a user I would expect to be able to navigate back to the old list and see the results I just queried without another unecessary network request. It might make more sense to maybe have a deletion utility that prunes your old objects on startup rather than while the user is accessing them.
Anyways, I cannot illustrate how important it is that you familiarize yourself with NSFetchedResultsController
This class is intended to efficiently manage the results returned from
a Core Data fetch request.
You configure an instance of this class using a fetch request that
specifies the entity, optionally a filter predicate, and an array
containing at least one sort ordering. When you execute the fetch, the
instance efficiently collects information about the results without
the need to bring all the result objects into memory at the same time.
As you access the results, objects are automatically faulted into
memory in batches to match likely access patterns, and objects from
previous accessed disposed of. This behavior further serves to keep
memory requirements low, so even if you traverse a collection
containing tens of thousands of objects, you should never have more
than tens of them in memory at the same time.
Taken from Apple
It literally does everything for you and should be your go-to for any list that shows objects from Core Data.
When I fetch the objects from core data, I get that old data as well
Thats to be expected, you haven't specified anywhere that your fetch should include the reports in a certain date range. Here's a sample fetch:
let fetch = Record.MR_createFetchRequest()
let maxDateForThisController = NSDate()//get your date
fetch.predicate = NSPredicate(format: "date < %#", argumentArray: [maxDateForThisController])
fetch.fetchBatchSize = 10// or an arbitrary number
let dateSortDescriptor = NSSortDescriptor(key: "date", ascending: false)
let nameSortDescriptor = NSSortDescriptor(key: "name", ascending: true)
fetch.sortDescriptors = [dateSortDescriptor,nameSortDescriptor]//the order in which they are placed in the array matters
let controller = NSFetchedResultsController(fetchRequest: fetch,
managedObjectContext: NSManagedObjectContext.MR_defaultContext(),
sectionNameKeyPath: nil, cacheName: nil)
Importing Discardable Records
Finally, you say that you want to see old reports and use a separate context that won't save to the persistent store. Thats also simple, your importer takes a context so all you would need to do is make sure that your importer can support imports without saving to the persistent store. That way you can discard the context and the objects will go with it. So your method signature could look like this:
public func insertRecords(data: AnyObject, canSaveToPersistentStore: Bool = true,success: () -> Void, failure: (error: NSError?) -> Void) {
/**
Import some stuff
*/
if canSaveToPersistentStore {
context.MR_saveToPersistentStoreWithCompletion({ (complete, error) -> Void in
if complete {
success()
} else {
error
}
})
} else {
success()
}
}
The old data that was in your persistent store, and addressed with the original MOC, is still there, and will be retrieved when the second MOC does a fetch. They're both looking at the same persistent store. It's just that the second MOC also has new data fetched from your API.
A synchronous network operation saving to Core Data will hang your app, and (for a large enough set of records) cause the system to kill your app, appearing to the user as a crash. Your client is wrong on that point, and needs to be educated.
Break apart your logic for fetching, saving, and viewing. Your view that shows a particular date's records should just do that--which it can do, if it accepts a date and uses a predicate.
Your 'cellForRowAtIndexPath' crash smells like a problem with a missing or misspelled identifier. What happens if you hard code a string instead of using 'record.name'?
I got a NSFetchedResultsController that I set up using a NSManagedObjectContext. I perform a fetch using this context.
I have as well a NSBatchUpdateRequest that I set up using the same NSManagedObjectContext. I execute the request using the same NSManagedObjectContext.
When I perform the request with the NSBatchUpdateRequest, I can see that all my data have been updated.
If I restart the app, any fetch using NSFetchedResultsController is working as well.
THe problem is when I'm not restarting the app and that I do both operations one after one, I got a NSMergeConflict (0x17427a900) for NSManagedObject (0x1740d8d40) with objectID '0xd000000001b40000... error when I call the method save from my context.
I know that the problem comes from concurrent change on the same data but I don't know what is the solution? One might be to go through the NSMergePolicy class, but I doubt that's a clean way to solve my problem.
What should I do? Have two different contexts ? (how?)
Well it seems I might have found how to do it, but if you see anything wrong, please let me know.
When you do a batch update, you have the possibility to get as a result, whether nothing, the number of rows that were updated or a list of object IDs that were updated. You have to choose the last one.
Once you perform executeRequest from the context, you need to get the list of object IDs, loop through all of them to get every NSManagedObject into Faults thanks to the method objectWithID of the context object. If you don't know what Faults object are in Core Data, here is the explanation.
With every NSManagedObject you get, you need to refresh the context using its method refreshObject.
Once you've done that, you need to perform again the performFetch of your fetchedResultsController to come back to where you were before the batch update.
Tell me if I'm wrong somewhere.
Here is the code:
let batchUpdate = NSBatchUpdateRequest(entityName: "myEntity")
batchUpdate.propertiesToUpdate = ["myPropertieToUpdate" : currency.amountToCompute]
batchUpdate.affectedStores = managedContext.persistentStoreCoordinator?.persistentStores
batchUpdate.resultType = .UpdatedObjectIDsResultType
var batchError: NSError?
let batchResult = managedContext.executeRequest(batchUpdate, error: &batchError) as NSBatchUpdateResult?
if let result = batchResult {
println("Records updated \((result.result as [NSManagedObjectID]).count)")
// Extract Object IDs
let objectIDs = result.result as [NSManagedObjectID]
for objectID in objectIDs {
// Turn Managed Objects into Faults
let nsManagedObject: NSManagedObject = managedContext.objectWithID(objectID)
if let managedObject = nsManagedObject as NSManagedObject? {
managedContext.refreshObject(managedObject, mergeChanges: false)
}
}
// Perform Fetch
var error: NSError? = nil
if !fetchedResultsController.performFetch(&error) {
println("error: + \(error?.localizedDescription), \(error!.userInfo)")
}
} else {
println("Could not update \(batchError), \(batchError!.userInfo)")
}
EDIT:
Here are two links for more explanations:
http://code.tutsplus.com/tutorials/ios-8-core-data-and-batch-updates--cms-22164
http://www.bignerdranch.com/blog/new-in-core-data-and-ios-8-batch-updating/