Background
This is the same background as my previous question, except the Outline view doesn't have a fetch predicate.
I've got an
NSOutlineView
that shows TrainingGroup entities.The
NSOutlineView
is bound to anNSTreeController
In the NSTreeController, I've got "Preserve Selection" ticked and "Select inserted objects" unticked.
Each TrainingGroup represents a folder on the local machine.
Each TrainingGroup can be assigned to a project. The project should propagate to all descendants of that group.
The project column is bound to the project property of each training group.
There's a lot of data in this view. Because each time entry has an entry, there can be a total of ~15000 descendants under one training view.
Outline View
The tree looks like this:
Name Project
Users nil
John nil
Documents nil
Acme Project Acme Project
Proposal.doc Acme Project
12:32-12:33 Acme Project
13:11-13:33 Acme Project
... thousands more here!
Budget.xls Acme Project
Big Co Project Big Co Project
Deadlines.txt Big Co Project
Spec.doc Big Co Project
开发者_运维百科 New Project nil
StartingUp.doc nil
Personal Stuff Personal
MyTreehouse.doc Personal
Movies nil
Aliens.mov nil
StepMom.mov nil
On Project Assign
When a project is edited, the assignment to all children happens on an
NSOperation
subclass on a background thread so the user is free to make other selections and move around whilst all descendants are processed.When the operation has finished, I run the
mergeChangesFromContextDidSaveNotification:
method on the main managed object context:mainContext = [[NSApp delegate] managedObjectContext];
[mainContext performSelectorOnMainThread:@selector(mergeChangesFromContextDidSaveNotification:) withObject:notification waitUntilDone:YES];
Functionally, this works fine - all descendants are assigned to the project when the context is merged back into main.
The Problem
On merge, the
NSOutlineView
that's bound to the main context freezes and the merge can take several seconds to complete.To reduce this freeze, I've batched up the groups to assign into several smaller operations.
There are three problems with this batched background operation approach:
The interface becomes unresponsive for a fraction of a second. This isn't such a big deal, but it does mean small unpredictable pauses in the interface.
The outline view updates each batch that's merged back in. When it does this, the selection can be glitchy.
Some projects under assigned groups remain blank. The object has been assigned the project, but the outline view hasn't refreshed the project properly. Presumably because the main thread is interrupted by the merges.
You can see these issues in the screencast I recorded:
http://screenr.com/Fk4
The Alternative
I could merge the changes from each operation into a managed object context running on a background thread. Them maybe I could send a message to the main thread to refresh all objects within the top level group that was changed.
That might get rid of problems 1 and 3 above, but I think 2 would still be an issue.
My Question
Is there a better way of doing this?
Before I start reworking how I do this (I've already changed how this works once) I want to know if there's a better way or there are any drawbacks to this approach I don't know about.
Thanks in advance for any suggestions on alternatives.
I'm currently living with the freeze. But I think the answer is to parallel up my NSOperations and just reduce the time taken to make the merge to the minimum possible. There are doubtless lots of improvements I can make to the data model to make the operations much easier to merge in too.
I tried to implement a merge on background thread recently, but struggled to make it work. It'll be something I revisit, I think.
精彩评论