ICloud: handiling of NSPersistentStoreDidImportUbiquitousContentChangesNotification done on main thread, locks up UI #398

Closed
firemuzzy opened this Issue Jan 26, 2013 · 4 comments

Comments

Projects
None yet
2 participants
@firemuzzy

The MR_mergeChangesFromiCloud in NSManagedObjectContext+MagicalObserving.m preforms the merging on the main thread. A large update from iCloud locks up UI.

@firemuzzy

This comment has been minimized.

Show comment Hide comment
@firemuzzy

firemuzzy Jan 30, 2013

I did not understand Core Data and MagicalRecord enough, and after looking at it again my culprit is NSFetchedResultsController. Large updates to my NSFetchedResultsController sitting over an iCloud store keeps locking up the UI, so I am doing stupid.

I did not understand Core Data and MagicalRecord enough, and after looking at it again my culprit is NSFetchedResultsController. Large updates to my NSFetchedResultsController sitting over an iCloud store keeps locking up the UI, so I am doing stupid.

@firemuzzy firemuzzy closed this Jan 30, 2013

@casademora

This comment has been minimized.

Show comment Hide comment
@casademora

casademora Jan 30, 2013

Member

So, while you might have made an error in your code, would you mind explaining your scenario a bit more? I feel that though this isn't a bug per se, but in fact is more like an API bug. That is, it seems that the MagicalRecord API isn't as clear as it should be in order to achieve the intended results (ie. not running a merge on the main thread)

Member

casademora commented Jan 30, 2013

So, while you might have made an error in your code, would you mind explaining your scenario a bit more? I feel that though this isn't a bug per se, but in fact is more like an API bug. That is, it seems that the MagicalRecord API isn't as clear as it should be in order to achieve the intended results (ie. not running a merge on the main thread)

@firemuzzy

This comment has been minimized.

Show comment Hide comment
@firemuzzy

firemuzzy Jan 30, 2013

Sure.

Set up:

  • 2 separate controllers, 1 that doing the adding and 1 doing the displaying.
  • The 'adding' controller gets modally (but full screen) displayed over the 'displaying' controller.
  • The 'displaying' controller has an NSFetchedResultsController that observes the changes to a CoreData table that is synced with iCloud

Problem causing:

  • 'Adding' controller adds a lot of things to the context and saves it
  • The 'displaying' controller is still alive under the 'adding' controller
  • its NSFetchedResultsController notices the changes to the context
  • starts updating the table view (although the table view is really not visible because its covered up)
  • This big update of that table view locks up the UI (happens right after the NSPersistentStoreDidImportUbiquitousContentChangesNotification gets processed hence my confusion)

Have done so far to deal with it (but seems hackish):

  • On viewWillDisappear in the 'displaying' controller set the NSFetchedResultsController delegate to nil so it does not update
  • On viewDidAppear in the 'displaying' set the NSFetchedResultsController delegate back to what it was and reload the table view

Sure.

Set up:

  • 2 separate controllers, 1 that doing the adding and 1 doing the displaying.
  • The 'adding' controller gets modally (but full screen) displayed over the 'displaying' controller.
  • The 'displaying' controller has an NSFetchedResultsController that observes the changes to a CoreData table that is synced with iCloud

Problem causing:

  • 'Adding' controller adds a lot of things to the context and saves it
  • The 'displaying' controller is still alive under the 'adding' controller
  • its NSFetchedResultsController notices the changes to the context
  • starts updating the table view (although the table view is really not visible because its covered up)
  • This big update of that table view locks up the UI (happens right after the NSPersistentStoreDidImportUbiquitousContentChangesNotification gets processed hence my confusion)

Have done so far to deal with it (but seems hackish):

  • On viewWillDisappear in the 'displaying' controller set the NSFetchedResultsController delegate to nil so it does not update
  • On viewDidAppear in the 'displaying' set the NSFetchedResultsController delegate back to what it was and reload the table view
@casademora

This comment has been minimized.

Show comment Hide comment
@casademora

casademora Jan 30, 2013

Member

Thanks, I'll go over this scenario a bit with the team to see if we can't make the API more intuitive or correct...

Saul Mora
saul@casademora.com (mailto:saul@casademora.com)
http://about.me/saulmora

On Tuesday, January 29, 2013 at 5:51 PM, firemuzzy wrote:

Sure.
Set up:
2 separate controllers, 1 that doing the adding and 1 doing the displaying.
The 'adding' controller gets modally (but full screen) displayed over the 'displaying' controller.
The 'displaying' controller has an NSFetchedResultsController that observes the changes to a CoreData table that is synced with iCloud

Problem causing:
'Adding' controller adds a lot of things to the context and save it
The 'displaying' controller is still alive under the 'adding' controller -> its NSFetchedResultsController notices the changes to the context -> starts updating the table view (although the table view is really not visible because its covered up)
This big update of that table view locks up the UI (happens right after the NSPersistentStoreDidImportUbiquitousContentChangesNotification gets processed hence my confusion)

Have done so far to deal with it (but seems hackish):
On viewWillDisappear in the 'displaying' controller set the NSFetchedResultsController delegate to nil so it does not update
On viewDidAppear in the 'displaying' set the NSFetchedResultsController delegate back to what it was and reload the table view


Reply to this email directly or view it on GitHub (#398 (comment)).

Member

casademora commented Jan 30, 2013

Thanks, I'll go over this scenario a bit with the team to see if we can't make the API more intuitive or correct...

Saul Mora
saul@casademora.com (mailto:saul@casademora.com)
http://about.me/saulmora

On Tuesday, January 29, 2013 at 5:51 PM, firemuzzy wrote:

Sure.
Set up:
2 separate controllers, 1 that doing the adding and 1 doing the displaying.
The 'adding' controller gets modally (but full screen) displayed over the 'displaying' controller.
The 'displaying' controller has an NSFetchedResultsController that observes the changes to a CoreData table that is synced with iCloud

Problem causing:
'Adding' controller adds a lot of things to the context and save it
The 'displaying' controller is still alive under the 'adding' controller -> its NSFetchedResultsController notices the changes to the context -> starts updating the table view (although the table view is really not visible because its covered up)
This big update of that table view locks up the UI (happens right after the NSPersistentStoreDidImportUbiquitousContentChangesNotification gets processed hence my confusion)

Have done so far to deal with it (but seems hackish):
On viewWillDisappear in the 'displaying' controller set the NSFetchedResultsController delegate to nil so it does not update
On viewDidAppear in the 'displaying' set the NSFetchedResultsController delegate back to what it was and reload the table view


Reply to this email directly or view it on GitHub (#398 (comment)).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment