Re: Re: Is there another way to do performSelectorOnMainThread?
Re: Re: Is there another way to do performSelectorOnMainThread?
- Subject: Re: Re: Is there another way to do performSelectorOnMainThread?
- From: "Michael Ash" <email@hidden>
- Date: Fri, 30 Jun 2006 14:46:22 -0400
On 6/30/06, Jerry Krinock <email@hidden> wrote:
on 06/06/29 8:17, Finlay Dobbie at email@hidden wrote:
> NSInvocation is probably even more heavyweight, tbh.
And a real pain! After using NSInvocation a few times, I realized "Why am I
putting myself through this torture?"
So, I don't use it NSInvocation or its side-kick NSMethodSignature anymore.
If I need to invoke a method with non-object arguments, I either rewrite the
method so it has object wrappers around its arguments, or else wrap it in
another method that takes only object arguments, then use a
performSelector:.
My rate of hair loss has decreased, without drugs!
It is almost trivial to write an invocation builder that uses
forwardInvocation: in clever ways, so you could just write:
InvocationBuilder *b = [InvocationBuilder builderWithTarget: target];
[b thisMethod: arg1 goesOn: arg2 theMainThread: arg3];
[[b invocation] performSelectorOnMainThread: @selector( invoke )
withObject: nil];
Of course, once you've done that, it's not much more work to extend it
into a full-blow HOM which would just look like:
[[target performOnMainThread] thisMethod: arg1 goesOn: arg2
theMainThread: arg3];
CHOMP has a performAfterDelay: method which is conceptually very
similar. (Full disclosure: I wrote CHOMP.) Adding a
performOnMainThread method to CHOMP (or indeed another HOM framework)
would be straightforward. Or you can just do it yourself; HOM
implementations are only tricky if you have iteration support.
It's a bit of infrastructure up front to save work later on. Whether
it's better than just writing methods that take dictionaries or
whatever depends on your frame of mind and how often you're doing this
sort of thing.
Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden