looped timer does not invalidate as instructed - swift

Question

I have built a "metal detector" kind of app that runs the "calculateDistance" function every 2 seconds, which calculates the distance in meters between the user location and a set marker, sets that to var globalDistance. Depending on if that distance, for simplicity, is >=10meters or <10meters, I am playing a scheduled timer that calls the "audioplayer" function, which plays a "beep" sound every 2 seconds (if distance>=10m) or every 0.5seconds (if distance <10m).
Problem is, the timers never invalidate as I instruct them to. So if I move from <10m to >10m with my device, the 0.5sec beeping continues. I do audioTimer.invalidate() to stop the timer running from previous iteration.
Any idea what I am doing wrong with my code? Many thanks
func calculateDistance {
//here there is code that successfully calculates distance, every 2 seconds
var timerSeconds = 0.0
var audioTimer = Timer.scheduledTimer(timeInterval: (timerSeconds), target: self, selector: #selector(googleMaps.audioPlayer), userInfo: nil, repeats: true)
if globalDistance > 10 { // globalDistance is where i set the distance every 2 seconds, with a timer fired on ViewDidLoad
timerSeconds = 2
}
if globalDistance >= 0 && globalDistance <= 10 {
timerSeconds = 0.5
}
audioTimer.invalidate()
audioTimer = Timer.scheduledTimer(timeInterval: (timerSeconds), target: self, selector: #selector(googleMaps.audioPlayer), userInfo: nil, repeats: true)
audioTimer.fire()
}
func audioPlayer(){
AudioServicesPlaySystemSound(1104)
}

Answer 1

The basic idea is to make sure there is no code path by which a Timer is started without stopping any prior one. You current code has a couple of paths by which an existing timer is not invalidated before starting the next one.
Furthermore, I would suggest that you only invalidate the old Timer if the new beep frequency is different than the old beep frequency. (Why invalidate the 2 second repeating beeping and start another timer if the old 2 second timer will do the job fine?)
So, this means that you will:
pull both the Timer and the TimeInterval variables out of the function;
only do the "new timer" process if it decides that the beep interval has changed; and
make sure to always invalidate the old timer before creating a new one.
For example:
private var audioTimer: Timer?
private var beepInterval: TimeInterval?
private func updateBeepIntervalIfNeeded() {
// here there is code that successfully calculates distance, called with whatever frequency you want
let newBeepInterval: TimeInterval
if globalDistance > 10 {
newBeepInterval = 2
} else if globalDistance >= 0 {
newBeepInterval = 0.5
} else {
fatalError("less than 0?!") // I'm inferring from your code that this cannot happen, but by using `let` above, Swift warned me that we had a path of execution we hadn't previously considered
}
if beepInterval != newBeepInterval {
beepInterval = newBeepInterval
audioTimer?.invalidate()
audioTimer = Timer.scheduledTimer(timeInterval: beepInterval!, target: self, selector: #selector(beep(_:)), userInfo: nil, repeats: true)
audioTimer!.fire()
}
}
#objc func beep(_ timer: Timer) {
// perform beep here
}

Answer 2

The problem
There's several issues at hand here.
Firstly, I'd like to emphasis the difference between references and instances. When you call call an initializer, the system allocates a piece of memory for a new object, and gives you a reference to that memory, which is stored in whatever variable you assign it to. You can assign this reference to other variables, which will make copies of the reference. Each of these variable references the same original object. This object will continue to exist in memory until no more variables reference it.
In your case, you're not directly calling an initializer, but you're calling a static method which serves a similar purpose. A new object is allocated on your behalf, and you're given a reference, which you then assign to audioTimer. There's a catch to this, however. When you call Timer.scheduledTimer(timeInterval:target:selector:userInfo:repeats:), the newly constructed timer is scheduled on the current run loop for you. The run loop is what's in charge of firing your timer at the right time. The consequence of this is that now the runloop is referencing your timer, preventing the timer object from being destroyed. Unless you invalidate your timer to unregister it from its runloop, the timer will continue to exist and fire forever, even after you delete your deference to it.
Now let's take a look at your code, with some explanation as to what's going on:
func calculateDistance {
//here there is code that successfully calculates distance, every 2 seconds
var timerSeconds = 0.0
// 1) Initialize timer #1
var audioTimer = Timer.scheduledTimer(timeInterval: (timerSeconds), target: self, selector: #selector(googleMaps.audioPlayer), userInfo: nil, repeats: true)
if globalDistance > 10 { // globalDistance is where i set the distance every 2 seconds, with a timer fired on ViewDidLoad
timerSeconds = 2
}
if globalDistance >= 0 && globalDistance <= 10 {
timerSeconds = 0.5
}
// 2) Invalidate timer #1 (timer #1 is useless)
audioTimer.invalidate()
// 3) Initialize timer #1
audioTimer = Timer.scheduledTimer(timeInterval: (timerSeconds), target: self, selector: #selector(googleMaps.audioPlayer), userInfo: nil, repeats: true)
// 4) Fire timer #2 immediately
audioTimer.fire()
} // At the end of this method body:
// - Timer #2 was never invalidated
// - audioTimer no longer references Timer #2, but:
// - Timer #2's runloop still references it, keeping it alive
// - Timer #2 is leaked
// ... and will continue firing forever.
func audioPlayer(){
AudioServicesPlaySystemSound(1104)
}
We can see that a Timer is made in section one, which should fire off in timerSeconds seconds, 0. At section 2, that timer is invalidated. Even though the Timer was to fire off in 0 seconds, it is almost certain that its run loop hasn't gotten a chance to fire it yet. Thus, this time is created, never fires, and then invalidated. There's no reason for it to exist at all there.
Then, in section 3, Timer #2 is created and scheduled. it is manually fired at section 4, and then it's permanently leaked.
The solution
You need an instance variable that holds reference to the timer. Without this, you have no way of invalidating the timer that has been already scheduled.
Secondly, you need to invalidate the timer at the appropriate time.
I suggest you take a look at Rob's answer for an example.

Answer 3

Youre creating a new, infinitely repeating, timer once, invalidate it immediately (why?), and then create another (why?), which is leaked forever.

Answer 4

You are creating a new timer,invalidating then creating a timer again.
You could try creating the timer,and when calling the audioPlayer function,checking for which sound to play depending on the value of the timerSeconds variable.