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: Chris Hanson <email@hidden>
- Date: Sat, 27 Sep 2008 13:25:11 -0700
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.
Instead of an API like this, which is synchronous:
@interface DeviceController : NSObject
- (NSString *)valueForVariable:(NSString *)variable;
@end
You might instead implement this, which is asynchronous:
@protocol DeviceControllerDelegate; // forward declaration
@interface DeviceControlelr : NSObject
@property (readwrite, assign) id <DeviceControllerDelegate> delegate;
- (void)requestValueForVariable:(NSString *)name;
@end
@protocol DeviceControllerDelegate <NSObject>
- (void)deviceController:(DeviceController *)controller
receivedValue:(NSString *)value
forVariable:(NSString *)variable;
@end
If you want to use a thread to actually do the request, you can use -
performSelectorOnMainThread:withObject:waitUntilDone: to pass the
value back to the main thread for sending through the delegate message.
You don't have to use a thread though. You could also use NSStream
and its delegate messages to run the state machine that manages your
protocol straight from the main run loop. Your API would look the
same, but you wouldn't have to manage a thread yourself. (NSStream
can use one if it wants to.)
-- Chris
_______________________________________________
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