Can NSTimer be used to fire a series of events. For instance for effect:
Its kick off Click start to toss
create random number
wait 5 seconds show result
wait 3 seconds start the match?
You can use it to repeat at a given interval, but not a variable one. If you really wanted to wait 5 seconds and then then wait another 3 seconds you'd probably want to chain timers. So, when the first timer fires and calls a message, that message creates a second timer with a different time interval.
This is actually a case where the Prototype Pattern would apply: make an NSTimer and set it up with all the properties you want, and then clone that object each time you need to make another. Or you could just make a factory. Objective C does not have a clone, but the NSCoding protocol is actually a workable and proper way of doing cloning (unlike Java's broken (and abandoned) clone interface).
Related
i read about flink`s window assigners over here: https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/operators/windows.html#window-assigners , but i cant find any solution for my problem.
as part of my project i need a windowing that the timer will start given the first element of the key and will be closed and set ready for processing after X minutes. for example:
first keyA comes at (hh:mm:ss) 00:00:02, i want all keyA will be windowing until 00:01:02, and then the timer of 1 minutes will start again only when keyA will be given as input.
Is it possible to do something like that in flink? is there a workaround?
hope i made it clear enough.
Implementing keyed windows that are aligned with the first event, rather than with the epoch, is quite difficult, in general, which I believe is why this isn't supported by Flink's window API. The problem is that with an out-of-order stream using event time processing, as earlier events arrive you may need to revise your notion of when the window began, and when it should end. For example, if the first keyA arrives at 00:00:02, but then some time later an event with keyA arrives with a timestamp of 00:00:01, now suddenly the window should end at 00:01:01, rather than 00:01:02. And if the out-of-orderness is large compared to the window length, handling this becomes quite complex -- imagine, for example, that the event from 00:00:01 arrives 2 minutes after the event from 00:00:02.
Rather than trying to implement this with the window API, I would use a KeyedProcessFunction. If you only need to support processing time windows, then these concerns about out-of-orderness do not apply, and the solution can be fairly simple. It suffices to keep one object in keyed state, which might be a list holding all of the events in the window, or a counter or other aggregator, depending on what you're trying to accomplish.
When an event arrives, if the state (for this key) is null, then there is no open window for this key. Initialize the state (i.e., create a new, empty list, or set the counter to zero), and create a Timer to fire at the appropriate time. Then regardless of whether the state had been null, add the incoming event to the state (i.e., append it to the list, or increment the counter).
When the timer fires, emit the window's result and reset the state to null.
If, on the other hand, you want to do this with event time windows, first sort the stream and then use the same approach. Note that you won't be able to handle late events, so plan your watermarking accordingly (reducing the likelihood of late events to a manageable level), or go for a more complex implementation.
I read a code, it checks data and update UI every second. It sounds like what we usually do using NSTimer scheduledtimerwithtimeinterval. But this code is implemented with recursively calling dispatch_after like this:
- (void) retriggerMethod {
... do stuff here, assuming you want to do it on first invocation ...
dispatch_after( ..., ^{
[self retriggerMethod];
});
}
What's the difference between dispatch_after recursion and NSTimer scheduledtimerwithtimeinterval ? Is there potential risk when using the former? Cos I thought when you use it, the call stack would grow as long as not end this recursion.
NSTimer:
1. Need a NSRunloop.
2. Can repeat.
3. Can be invalid anytime if u want to cancel.
4. Can only run with delegate.
5. High level API.
dispatch_after:
1. Can be run everywhere that u want with dispatch_queue.
2. Can't repeat by itself.
3. Can't be cancel.
4. It run as block.
5. GCD.
You actually don't have any recursion in your code. Using dispatch_after in your case behaves similar to using a NSTimer.
With dispatch_after, the next call to your retriggerMethod originates from GCD which executes the enqueued block. So you don't have a call within a call - no recursion here.
So in terms of recursion, there's no risk. Though in this case it seems more reasonable to use a NSTimer which would be easier to cancel if necessary.
This is really late, but a couple additional considerations now:
cancelling difference is not a huge deal
dispatch_after does accepts workItems which can be cancelled about as easily as a timer can.
time slipping
For a high number of repetitions dispach_after recursion could slip in accuracy by a lot. Each slip is compounded into the next recursion, since the next recursion is set only after executing the previous recursion. Say for example dispatch_after may slip up to 10ms. That means after 100 recursions, it may have slipped up to 1 second.
In comparison, while each tick of the NSTimer may also be up to 10ms off (for example), later ticks won't ever slip more than 10ms that since each tick time is relative to the original scheduled time.
I have a NSTimer (running on main thread) that is supposed to go off every 0.02s. However, I notice that as memory usage start going up (the app captures a frame every tick and stores in an array) subsequent ticks begin to take more then 0.02s.
How can I solve this issue? I'm starting to think NSTimer is not suited for high-frequency tasks like this.
As the docs state,
A timer is not a real-time mechanism; it fires only when one of the
run loop modes to which the timer has been added is running and able
to check if the timer’s firing time has passed. Because of the various
input sources a typical run loop manages, the effective resolution of
the time interval for a timer is limited to on the order of 50-100
milliseconds.
Since 100 milliseconds = .1 seconds and your timer is supposed to run every 0.02 seconds, your timer schedule is far shorter than the timer's effective resolution and so you timer can easily get out of sync.
I'm trying to create a label that shows the time on a NSTimer, however my problem is that the interval on the timer isn't 1.0 and so there is no way to update the label every second like I would like to be able to. I have tried to synchronize two timers, however that is proving to be a challenge. So, Is there a way to get secondary updates or synchronize two timers of different interval?
I'm reading your question as follows:
I have a timer that needs to fire once per 5 seconds, but I would like to tell the user how many seconds remain until the timer fires.
The simplest way that I can think of is to make an intermediary method that the first timer will call. You would change:
timer -> METHOD_A
to
timer -> METHOD_B -> METHOD_A
the timer could then be set to update every .1 seconds, and METHOD_B could keep track of the time and just call METHOD_A when 5 seconds have passed since the previous call.
For what it's worth though I don't think that NSTimer will slip, so when you are updating the time you are probably doing something like time=time+interval, where it might make more sense to do (currentTime-startingTime)%interval, and then the synchronization shouldn't be a problem
I'm trying to execute a function(or procedure) every x seconds.
I've been looking everywhere but never seemed to find something that suits my needs.
My application basically gets data from the web and I want to make an auto-refresh checkbox.
So let's say the user checks the box, I want the app to call that function every 5 seconds.
Thanks!
Use a TTimer (from the System tab in the component palette). Set the interval to the number of seconds * 1000 (converting from milliseconds to seconds), and write a handler for the OnTimer event.
The simplest way it to use the TTimer component, part of Delphi's standard VCL. Put one on the form, make sure Enabled is set to True, set Interval to 5000 (the value is in milliseconds), and assign its OnTimer event, where you'll put the code that needs to run every 5 seconds.
Sometimes it is a good idea to start with the timer disabled, then set its Enabled property to true in code, so that the timer starts to fire after everything else in your application has been properly set up.
The timer may not be firing in exact 5-second intervals, since timer messages have low priority in Windows and may not be received if the CPU is doing a lot of other work. Since your interval is relatively long, you might set the timer to fire every second (Interval := 1000) or even a few times per second, and check current time every time it fires. Perform the update if current time is later by 5 seconds or more from the time of the last update. (Use the SecondsBetween function in DateUtils unit to make that determination).
I don't have Delphi at the moment, but I'm pretty sure there was a TTimer component in the control palette, and according to this, I think I'm right.