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: Michael Gardner <email@hidden>
- Date: Sat, 27 Sep 2008 23:23:11 -0500
On Sep 27, 2008, at 10:10 PM, Joe Keenan wrote:
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.
If I understand you correctly, then I had a similar problem in a Perl
web application: there were dozens of different run modes, each
corresponding to a different handler method (with the method names
themselves having essentially no relation to the run mode strings...
sigh). I eliminated the cascade of if-statements by mapping the run
modes to the methods directly with a hash map. You might be able to do
the same thing by e.g. using selectors as values in an NSDictionary.
Of course, it all depends on how your app's behavior needs to vary
with the responses you get from the networked device.
-Michael
_______________________________________________
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