objcio / issue-4-full-core-data-application Goto Github PK

I am using the model described in this chapter under the Entity Hierarchy vs. Class Hierarchy however i am running into the problem where Core Data is not firing a fault when I access an attribute on a relationship. ie

manager.employee.name

To get the fault to fire i have to use:

[manager valueForKeyPath:@"employee.name]

Any ideas on how to remedy this? I am also a little concerned about what else might not be going on behind the scenes?

I have also gone into a little more details about more data model in this SO post:

http://stackoverflow.com/questions/19718724/core-data-not-firing-fault-when-accessing-relationship-property/19719333?noredirect=1#19719333

I realise the point of the app is to demo core data (and I learned so much from it!), but the pull to create logic is broken in iOS 7 because the default content offset for scroll views in a navigation controller is not 0, it's -64.

Because un-pausing the fetched datasource reloads the table the selection is lost so there is no deselect animation. There are a few options to fix it:

1. Don't pause the FRC but as of iOS 13 we get warnings when updating the table that is not in a window (The NSAssert in didChangeObject also needs removed).
   Warning once only: UITableView was told to layout its visible cells and other contents without being in the view hierarchy (the table view or one of its superviews has not been added to a window).

2. Reselect the row after the reload, after a selection the cells must be forced to update in a call to either visibleCells or cellForRow in an animateAlongsideTransition block before super viewWillAppear.

3. Keep FRC working and store all the table changes in block operations and replay them in a performBatchUpdates call, i.e. defer the updates as Apple suggest in their warning:
   This may cause bugs by forcing views inside the table view to load and perform layout without accurate information (e.g. table view bounds, trait collection, layout margins, safe area insets, etc), and will also cause unnecessary performance overhead due to extra layout passes. Make a symbolic breakpoint at UITableViewAlertForLayoutOutsideViewHierarchy to catch this in the debugger and see what caused this to occur, so you can avoid this action altogether if possible, or defer it until the table view has been added to a window.