Re: design pattern for data acquisition in background thread?
Re: design pattern for data acquisition in background thread?
- Subject: Re: design pattern for data acquisition in background thread?
- From: "John C. Randolph" <email@hidden>
- Date: Sun, 28 Sep 2008 05:29:25 -0700
On Sep 27, 2008, at 8:10 PM, Joe Keenan wrote:
On Sep 27, 2008, at 4:25 PM, Chris Hanson wrote:
On Sep 26, 2008, at 3:37 PM, Joe Keenan wrote:
Right now, the app controller object sends a message to the
device controller, requesting the value of a specified variable.
The device controller does the telnet command to get it, returns
it to the app controller, and the app controller sends it to the
text field. Repeat 25 times for a full update. Slow, and there's
no return to the run loop in there to allow for keyboard or UI
events.
I'm looking for suggestions on how to deconstruct this to get the
object talking to the device into another thread so the main
window can take UI events. I'm thinking I can package up the
variable requests into a dictionary so that the device controller
can do a bunch at once. Then the main thread can do all the
updates from the dictionary, which should be quick.
It doesn't even need to be that complicated.
You can follow a delegate model in your device controller's design
to make it asynchronous, rather than have it provide a synchronous
API.
Thanks for that pseudo-code. I think you're right about doing it
that way. I was also thinking I could add a request queue and a
response queue so that there can always be a request in the works,
instead of waiting to start the next one after the UI is updated.
The problem with any async method is that I haven't figured an
elegant way to know which update code to use for each return value.
They're not all the same. Different data elements need different
processing to update the UI. When I get a response back
asynchronously, I have the variable name and the value, and I have
to figure out which UI element it belongs to. The brute force
method is a long if/else chain that tests the name of the variable
to do it, like:
if ([key isEqualToString: @"lnbcolor"])
{
[lnbLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
else if ([key isEqualToString: @"lancolor"])
{
[lanLight setTextColor:[NSColor colorFromHexidecimalValue:
keyValue]];
}
With lots (25 or so) more possible key values, and a half-dozen or
more different ways to update the UI element.
This sounds like you're reinventing bindings and key-value observing.
Bind the controls in question to the relevant keys, and whenever you
get a callback that changes one of the values, send out a -
willChangeValueForKey: and a -didChangeValueForKey: message.
-jcr
_______________________________________________
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