Re: Handling List of Hardware Devices in NSTableView w/ Asynchronous Updates
Re: Handling List of Hardware Devices in NSTableView w/ Asynchronous Updates
- Subject: Re: Handling List of Hardware Devices in NSTableView w/ Asynchronous Updates
- From: Steve Christensen <email@hidden>
- Date: Wed, 01 Apr 2009 10:19:02 -0700
On Apr 1, 2009, at 7:51 AM, Grant Erickson wrote:
I've a list of hardware devices in an NSTableView. The contents of
the table
view are updated accordingly using the device model (C++) getters in
objectValueForTableColumn and using the device model setters in
setObjectValue.
However, the device model can also asynchronously create (sometimes
rapidly-order of tens to hundreds of milliseconds) updates for one
of the
model values independently of the getter. To handle this, I
currently have
the controller implement a delegate method for these asynchronous
updates
and then do:
[mDeviceTable reloadData];
Unfortunately, this then causes the table to hit all the device
getters for
all the devices and update all the columns even though only a
single column
(and possibly row) has changed thereby creating needless bus
traffic and
activity.
One approach would be to use a NSMutableIndex to keep track of which
device/table row is in need of an update. As each device finishes an
update it would set its index in the set. The benefit is that if your
hardware updates more often than your chosen UI update rate, only the
most recent values will be used. If device updates are happening in
another thread, you'll need to protect read/write accesses to the
index set with a lock so you don't access it when it's in an
inconsistent state.
Then have a timer run periodically to check if any devices have
updated information. For each index, just mark the corresponding
table row as needing an update, then remove that index from the index
set. When the table view is asked to update stale rows, it will just
call tableView:objectValueForTableColumn:row: as for any other update.
My first inclination is to create an array of dictionaries that act
as a
cache for the device attributes, have the asynchronous delegate
update the
appropriate key/value and then have reloadData update from there.
Caching information would be a good idea, whether it happens in your C
++ device class(es) or by copying information into a NSArray. It
allows you to repeatedly access current device information without
further touching the hardware, particularly if device access times
are on the slow side. Getting that information synchronously would
lock up the UI while the data is being fetched.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden