Re: KVO on Distributed Objects with exception handling.
Re: KVO on Distributed Objects with exception handling.
- Subject: Re: KVO on Distributed Objects with exception handling.
- From: Scott Anguish <email@hidden>
- Date: Tue, 8 Sep 2009 13:29:57 -0400
On Sep 8, 2009, at 10:38 AM, Edward Chan wrote:
I've just tested it on Snow Leopard (10a380), and it works as
expected.
Perhaps. But as I said, unsupported, untested internally, and could
break at any time.
Do you happen to remember the technical reasons why KVO on DOs would
fail?
None given, other than the above.
Ed
On Mon, Sep 7, 2009 at 11:55 PM, Scott Anguish<email@hidden>
wrote:
In spite of the fact that it might be working, it isn't supported.
When I talked to engineering about this, this is what I was told.
He was a
bit shocked it worked at all, and it isn't tested as part of
releases.
On Sep 7, 2009, at 3:02 PM, Edward Chan wrote:
Hello,
I'm using KVO on a Distributed Object, and I am binding my UI
controls
based on the observer.
For example:
MonkeyViewController.isEatingABanana -> Binded to a UI checkbox.
MonkeyViewController.m:
@propery (readwrite, assign) BOOL isEatingABanana;
-(id)init {
...
[MonkeyBrainDOObject addObserver:self
forKeyPath:@"banana"
options:(NSKeyValueObservingOptionNew |
NSKeyValueObservingOptionOld)
context:NULL];
...
}
- (void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(id)object
change:(NSDictionary *)change
context:(void *)context
{
if ([keyPath isEqualToString:@"banana]") {
[self willChangeValueForKey:@"isEatingABanana"];
isEatingABanana = [change objectForKey:NSKeyValueChangeNewKey]
boolValue];
[self didChangeValueForKey:@"isEatingABanana"];
}
}
- (void)setIsEatingABanana:(BOOL)flag
{
[MonkeyBrainDOObject setBanana:flag];
isEatingABanana = flag;
}
This indeed works, and we save some hassles of sending
NSNotifications and
such.
So, what I'm wondering is if the following code is sufficient enough
for the IPC exception handling?
Instead of having to manually write @try/@catch wherever I doing
some
IPC, I create a wrapper object around the DO to handle the
exceptions.
This wrapper class is simply an NSObject, and will call the methods
methodSignatureForSelector, and forwardInvocation when I try to use
MonkeyBrainDOObject methods (since the wrapper does not understand
them). I can then insert a @try/@catch when I forward the
invokations
to the actual DO object.
MonkeyBrainWrapper.m : NSObject
- (NSMethodSignature *)methodSignatureForSelector:(SEL)selector
{
return [MonkeyBrainDOObject methodSignatureForSelector:selector];
// maybe I can use extra code to make sure MonkeyBrainDOObject
responds to the selector.
}
- (void)forwardInvocation:(NSInvocation *)invocation
{
@try {
[invocation invokeWithTarget:MonkeyBrainDOObject];
} @catch (NSException *e) {
// Oh no! some went wrong with the IPC. But it's ok, I caught
you..
:P
}
}
So, instead of calling directly on the MonkeyBrainDOObject in my
MonkeyViewController, I would now call my MonkeyBrainWrapper object,
which has explicit exception handling rather than the one handle by
the NSApplication.
Should that be enough for exception handling on both ends of the
IPC?
Or do I need some explicit exception handling on the other end? It
seems when I tested it out, my other end never threw anything when
the
connection broke.
Also, is there maybe a better approach to all of this? My old code
had
a bunch of NSNotifications being sent/received whenever something
needed updating on the UI, and I found this approach to be a lot
cleaner.
Edward
_______________________________________________
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:
@cocoadoc.com
This email sent to email@hidden
_______________________________________________
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