Re: Making an NSMethodInvocation from the current method
Re: Making an NSMethodInvocation from the current method
- Subject: Re: Making an NSMethodInvocation from the current method
- From: Roland King <email@hidden>
- Date: Mon, 23 Aug 2010 18:57:44 +0800
d) doesn't work - I tried that one, in this case it's a UIView and invalidating it, or a tool bar on it, doesn't get the tool bar buttons to redraw properly, hence the need to move the actual set of those things over to the main thread. Whether it works for other UI elements I don't know but it definitely doesn't work for those so
b) is exactly what I was trying to do when I asked the question. That would be trivial if the methods took none, one or two object parameters but they don't, they take primitives and lots of arguments etc so you can't use performSelectorOnMain .. you have to create an NSMethodInvocation to then redispatch to the main thread. If the thing I was asking about existed, a way to get the current method invocation as an NSMethodInvocation, it would be easy. That's why I ended up in forwardInvocation: which makes them for me.
That blocks syntax is disgusting but is actually exactly what I really want to do, just invoke the same method but on the main thread, except I can't do it because this is for iOS 3.2 which doesn't have them.
I'll stick with the forward approach for now, it won't be hard to recode it if as and when the iPad supports blocks.
Thanks
On 23-Aug-2010, at 12:31 AM, Graham Cox wrote:
>
> On 22/08/2010, at 7:03 AM, Roland King wrote:
>
>> if( ![ NSThread isMainThread ] )
>> [ NSMagicFunctionReturningAnInvocationForThisCurrentFunction() performSelectorOnMainThread:@selector( invoke ) withObject:nil waitUntilDone:NO ];
>> else
>> {
>> // method performing code here
>> }
>>
>> but there is of course no such function I'm aware of nor can I easily think how I'd write such a thing.
>
>
> I can think of any number of alternatives to this sort of construction. The GCD/Blocks solution being a "nice" way to achieve what you've outlined, but which in itself is a truly horrible thing to behold.
>
> Some ideas:
>
> a). have a thread-safe receiver object that dispatches to another object on the main thread that does the display work (or another instance of the same class?)
>
> b). split the object into sets of external and internal methods where the external methods can be called on any thread but redispatch to the internal methods on the main thread.
>
> c). Bottleneck all updates through a single method that can be invoked on the main thread.
>
> d). If the class can be constructed as a view (you mentioned it was a "display" class, whatever that means) then it's fine to update internal state and call -setNeedsDisplay: on any thread and have it handle the subsequent drawing on the main thread.
>
> If you are determined to use an NSInvocation, bear in mind that it incurs a heavy performance penalty, but that the hidden parameter -cmd to any method is its own selector.
>
> --Graham
>
>
_______________________________________________
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