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: Edward Chan <email@hidden>
- Date: Tue, 8 Sep 2009 10:38:16 -0400
I've just tested it on Snow Leopard (10a380), and it works as expected.
Do you happen to remember the technical reasons why KVO on DOs would fail?
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:
>>
>> 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