Amras
Member
Hi friends!
What is the best way to make a SPImage, or SPSprite SPButton appear on the screen at one time? I know I would have to use the "sprite.visible = true;" but I want that to happen after a certain time. You would use the SPTween calling another function that changes the value of the visible?
Thanks!
You can use the delayed invocation mechanism of a juggler (the stage juggler is the easiest option).
so if you create a method that shows your image, called 'showImage' then call it like this:
[[self.stage.juggler delayInvocationAtTarget:self byTime:2] showImage];
That would delay the action by 2 seconds
Here's the documentation:
http://doc.sparrow-framework.org/core/Classes/SPJuggler.html#instance_methods
SPTween is not the greatest for generally scheduling events. It's meant for interpolating a property over time, not for calling general methods after some time has elapsed.
For this, you could use an NSTimer. Look up [NSTimer scheduledTimerWithTimeInterval:target:selector:userInfo:repeats:], which will allow you to call a general selector after an elapsed number of seconds.
I'm surprised no one has suggested this method yet: NSObject's performSelector:withObject:afterDelay:
That is the method I prefer when I don't need to sync the delay with Sparrow content and so forth.
Darnit Shilo!! You are saying all of my ideas first xD! Though I will point out that performSelector is not the best way if you want the delay to be pausable. You must use the delayed invocation in that case. For example, I use this method in Pandemic to schedule various actions for the bad guys, but if the user pauses the game I don't want them to replicate, move, etc.
Also beware repeating NSTimers, they are a sneaky cause of memory leaks since they are maintained internally and hold a reference to the object they send messages to, preventing it from being deallocated. I call this semantic memory leaking, since it is not quite the true definition of a leak.
You can also cancel performSelector:withObject:afterDelay: invocations with NSObject's cancelPreviousPerformRequestsWithTarget: and cancelPreviousPerformRequestsWithTarget:selector:object: methods.
I've found there are some situations in which the performSelector:withObject:afterDelay: method is preferable. If I have a screen in which I want to set a short delay immediately upon loading, then I have found that if I use the delayedInvocation technique then I get problems which seem to be due to the time it tackes for the screen assets to load. Presumably the delay time gets set before the asset loading begins, and then once everything catches back up with itself the juggler finds that the new time stamp is later than the delay was set for, and jumps to the end of any processes that were stalled.
If I switch to use the performSelector:withObject:afterDelay: technique then I don't get this problem - it seems that performSelector will happily freeze for however long it takes for my screen to initialize before then carrying out it's delay.
Both variations of behaviour can be useful in different circumstances!
You must log in to post.
