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: Joe Keenan <email@hidden>
- Date: Sat, 27 Sep 2008 23:10:13 -0400
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.
joe
_______________________________________________
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