Re: Best pattern to follow for scheduling an event
Re: Best pattern to follow for scheduling an event
- Subject: Re: Best pattern to follow for scheduling an event
- From: David Spooner <email@hidden>
- Date: Thu, 8 Nov 2007 11:57:25 -0700
On 8-Nov-07, at 11:43 AM, John Stiles wrote:
I think I'm not explaining myself well enough.
The typical pattern is that my method will get spammed a hundred
times in quick succession. After the burst of calls has completed, I
want to do fix-up. Technically, I could do my fix-ups after every
single call, but that would probably be slow so I want to avoid it.
This doesn't mean that the method will never get called again—much
later on in app execution, it's quite possible that my method will
suddenly get spammed again with hundreds of calls, and then I will
want to do fix-ups again.
The goal here is to avoid performing fix-up after every single
method call because I know they come in bursts, but there's no easy
way to know when the burst ends. It's pretty likely that if the
event loop is running, though, the burst of changes has run its
course.
I see. Perhaps the following would be cleaner ...
- (void) registerForCleanup
{
if (cleanupTimer != nil)
cleanupTimer = [NSTimer scheduledTimerWithTimeInterval:0 ...
}
- (void) performCleanUp:(NSTimer *)sender
{
...
cleanupTimer = nil;
}
where cleanupTimer an instance variable.
Consider something like text layout. An NSTextView doesn't reflow
its entire contents every time you make a trivial change—it defers
the big reflowing until "sometime later," again usually when the
event loop gets a chance to run.
_______________________________________________
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