App Crashes After Updating Coredata Model That Is Being Displayed in a UItableview

App crashes after updating CoreData model that is being displayed in a UITableView

indexPath is the index BEFORE the deletes and inserts are applied; newIndexPath is the index AFTER the deletes and inserts are applied.

For updates you don't care where it was BEFORE the inserts and delete - only after - so use newIndexPath not indexPath. This will fix crashes that can happen when you an update and insert (or update and delete) at the same time.

For move the delegate is saying where it moved from BEFORE the inserts and where it should be inserted AFTER the inserts and deletes. This can be challenging when you have a move and insert (or move and delete). I fixed this by saving all the changes from controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: into three different indexPath arrays: insert, delete and update. When you get a move add an entry for it in both the insert array and in the delete array. In controllerDidChangeContent: sort the delete array descending and the insert array ascending. Then apply the changes - first delete, then insert, then update. This will fix crashes that can happens when you have a move and insert (or move and delete) at the same time.

It is the same principle for sections. Save the sections changes in arrays, and then apply the changes in order: deletes (descending), sectionDelete (descending), sectionInserts (ascending), inserts(ascending), updates (any order). Sections can't move or be updated.

swift crash when altering UITableViewCells during update

The problem is that your datasource must be consistent with your TableView.

When you scroll your TableView, each row will be pulled from your datasource every time they are about to appear on screen.

When you call stocks.removeAll(keepCapacity: false), you should also reload your TableView to keep them synced.

EDIT:
If you want to keep a good user experience while it loads:

• Clear the table view and display an UIActivityIndicator that will show that the app is busy
  
  or
• Use a temporary array to fetch your data and then switch your datasource to it when you are done. That way, the user will still be able to see the "old" data while the app is working on fetching the new data.

UITableView - Table view in core data app crashing because number of rows not valid after deletion

The problem was, I think, that I did not need to manually delete the row using:

if (editingStyle == UITableViewCellEditingStyleDelete) {
        [tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath] withRowAnimation:UITableViewRowAnimationFade];
    }

I think the FetchResultsController takes care of that. Anyway I removed the line and it works.

What's the possible cause of this Core Data crash

Finally, I think I've fixed the crash though I'm not sure whether it is my bug or Core Data's bug.

First of all, it has nothing to do with the sync among MOCs.

Secondly, yes, initWithEntity:insertIntoManagedObjectContext: is called when objects are first instantiated in moc, whether they are newly created or fetched with a request. So it seem the doc is misleading:

If context is not nil, this method invokes [context insertObject:self]
(which causes awakeFromInsert to be invoked).

If it is called for fetching, awakeFromFetch is invoked.

As you can see in the backtrace, the crash happened in my overridden initWithEntity:insertIntoManagedObjectContext:. Reasonable enough, initWithEntity:insertIntoManagedObjectContext: turned out to be the cause of the crash. But I don't think I did anything bad in it. I just used some persistent attributes to initialize some non-persistent attributes:

- (id)initWithEntity:(NSEntityDescription *)entity insertIntoManagedObjectContext:(NSManagedObjectContext *)context {
    self = [super initWithEntity:entity insertIntoManagedObjectContext:context];
    if (self) {
        // xxx_ is a persistent attribute while _xxx is the corresponding non-persistent attribute as its cache in memory only to reduce reading cost.
        _xxx = self.xxx_.unsignedIntegerValue;
    }
    return self;
}

Sometimes when I read the first persistent attribute the unfulfillable exception was thrown up.

I always know that

You are discouraged from overriding this method—you should instead
override awakeFromInsert and/or awakeFromFetch (if there is logic
common to these methods, it should be factored into a third method
which is invoked from both). If you do perform custom initialization
in this method, you may cause problems with undo and redo operations.

But I don't know it would cause unfulfillable exceptions. Is it a Core Data bug? Otherwise, what's wrong with my code?

UITableView Crashes if Data Source Is Updated During Scrolling

The short answer is that you need to buffer the data in your data model and only update the table with the new data when the table is not being scrolled. That needs to be done in the data model because the datasource delegate has no idea what is inside the data model or what has changed.

However, from a UI design perspective, having a table actively updating while the user is scrolling will disorient the user. The user will think they are in the top/middle/bottom of the table then suddenly find themselves in the bottom/top/middle. The user will think that they have viewed all the data in one section of the table but in reality the table will have added something they needed to see. For example, if the table is a list of alphabetized names, the user checks all names staring with "U", sees that there are none and then goes to check somewhere else in the table. Meanwhile, the table invisibly updates the "U" section with fresh names while the user is looking elsewhere. Even if the user understands that the table is dynamically updated (which most are not) they will have to continually scroll around checking virtually the entire table to see what has changed.

A better UI design is to give the user the ability to update. Put an "Update" or "New Data Available" button in the bar and then set it to appear when new data arrives. Upon clicking the button, freeze the table, update and only then let the user resume interaction. It would also be good design to visually flag the rows added.

This will make the UI more understandable for the user and solve your crashing problem at the same time.

Edit01:

If you don't use Core Data, in order to implement live and invisible updating of the table. you will need to freeze the in the calls – tableView:numberOfRowsInSection or – numberOfSectionsInTableView: before – tableView:cellForRowAtIndexPath: is called.

Since – tableView:numberOfRowsInSection is called first, I would put a call there to first update and then freeze your data model. That way the data model will return the proper number of sections and rows.

I presume you will have to divide you data model into two sections, one of which will buffer incoming data and another that will order the data for display. Your update method should move all the finalized buffered data into the display data section.

In addition, you will probably need to set a timer for when the user is not moving the table. The timer should call the update method if the table is not being actively manipulated and then it should force an update.

If you use Core Data, you can use NSFetchedResultController and it's delegate methods will inform you when the data model changes. It should return the proper section and row information updated live. It's pretty easy to drive an updating table this way. However, it will not overcome the problem of data entering the model so quickly that the model changes between method calls. You will still have to freeze and/or slow down the model. You will however, not need the timer.

Core Data is your best option but even so it's going to be difficult to implement because you're trying to do something against the grain of the UI and therefore the API does not easily support it.

Update:

Looking back over this answer, I see that I neglected to mention [UITableView beginUpdates] which will freeze the table's configuration while rows are added or deleted. It is paired with [UITableView endUpdates] to include the changes in the UI.

Application crashes after first launch

From http://www.raywenderlich.com/23704/demystifying-ios-application-crash-logs

Here are some of the more common exception codes:
0x8badf00d: Reads as “ate bad food”! (If you squint your eyes and replace the digits with alphabetic characters. :p) This code indicates that an application was terminated by iOS because a watchdog timeout occurred. Basically, the application took too long to launch, terminate, or respond to system events.

The crash is because of a long wait, what's causing it is in 1 of 321 task items listed in the log.

I am really curious about your send event / handle event items in the log. Is there any chance that you are waiting for something before launching the rootViewController? ... it could be core data but if there is something very wrong I sort of expected another error to happen instead of along wait.

---

Related Topics