NSOutlineView (or NSTableView) and threaded, live data display
NSOutlineView (or NSTableView) and threaded, live data display
- Subject: NSOutlineView (or NSTableView) and threaded, live data display
- From: "John C. Daub" <email@hidden>
- Date: Wed, 31 May 2006 21:48:24 -0500
- Thread-topic: NSOutlineView (or NSTableView) and threaded, live data display
Hello.
I'm looking for input regarding NSOutlineView (or NSTableView) doing a live
display of data as it comes in from worker threads. What I'm looking for
here is input towards ensuring I'm playing nice with Cocoa. If you've been
down this road before, any insights you are willing to share are
appreciated.
My application has a producer-consumer thread architecture. The producer
thread is searching for stuff, when it finds it it passes it over a
thread-safe queue to the consumer thread, which puts the stuff into the
final data store. The data store is then what the table data source uses to
display the data in the table, with an NSTimer firing every 1.0 seconds to
do a -reloadData.
The data store is a tree structure. I have an Item object which holds a
reference to a found "stuff", and the Item also contains an NSMutableArray
for the "children", which are other Item objects; thus the tree structure. I
have a ResultsCollection class which acts as the bottleneck through which
all transactions about the data go through: adding Item's, etc.. The
ResultsCollection has an NSMutableArray which holds the top-level Item's. A
reference to the ResultsCollection is held by the NSOutlineViewDataSource,
and again I go through the ResultsCollection's methods to get at whatever
information the data source protocol methods need. The granularity of the
thread-safety happens in the ResultsCollection since I have to protect the
entire tree at once; I use an NSRecursiveLock for this.
I am wondering if perhaps there should be some greater lock/check in place,
especially when dealing with drawing the table.
When the table draws it will invoke the data source methods to do things
like get the number of rows, then iterate down the rows to draw each cell. I
figure I actually need to subclass NSOutlineView and override -drawRect:.
The override would obtain the lock on the ResultsCollection, call super's
-drawRect:, then unlock and return. I figure this is needed because tho I do
lock within the data source methods, I reason the thread execution could
interrupt drawing... like it asks how many rows to draw, then as it goes to
draw those rows the ResultsCollection changes and so the redraw is thrown
off... thus locking the collection while the whole drawing happens sounds
like a good idea.
1. is this a good idea? :-)
2. Is there a more appropriate place to do it than -drawRect:? e.g.
-drawRow:clipRect:? I don't think so... I think -drawRect: would be the
right place as I want to make the entire (re)draw of the table be atomic
with regards to the ResultsCollection's state.
3. Are there any other places I should be mindful of in doing this "live
data" table drawing stuff? The table won't support drag and drop, nor does
the table support "setting" data (e.g. can't in-place edit table items). I
can't think of any other place I might need to consider support.
4. From anyone that has past experience with such a setup, any other advice
or words of warning for what I'm about to undertake? :-)
Thank you.
--
John C. Daub }:-)>=
<mailto:email@hidden> <http://www.hsoi.com/>
"Give evil nothing to oppose and it will disappear by itself." -- Tao Te
Ching #60
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden