How to start timer with open ViewController? - ios

Question

I want to create a timer, which goes on while i switch to an another ViewController and come back later. My solution is this way:
I start the timer with an button
then i hand over the integer to the next ViewController
I start the timer with the new integer
So my problem results in step three: I want to start the timer in the function viewDidLoad(). But the timer doesn't starts in the next ViewController.
i hope anybody can help me. Tell me, if there is a better way to do the things i want.
Here is my Code:
var timer = Timer()
var eighthours: Int = 8
var activejob: Bool = false
override func viewDidLoad() {
super.viewDidLoad()
identify_activejob()
timer = Timer.scheduledTimer(timeInterval: 1, target: self, selector: #selector(Jobs.jobtime), userInfo: nil, repeats: true)
}
//functions
#objc func jobtime() {
eighthours -= 1
}

Answer 1

I can show you one way. But may as suggested, it has native design flaw and use it depends on the accuracy.
let timer = Timer.init(timeInterval: 1, repeats: true) { (timer) in
let string = ISO8601DateFormatter().string(from: Date())
print("running" + string)
}
}
class TimerViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
RunLoop.main.add(timer, forMode: RunLoop.Mode.default)
// Do any additional setup after loading the view.
}
}
It will keep running until invalidate.

Answer 2

A couple of thoughts:
The eighthours -= 1 in the timer handler is slightly problematic, because it’s presuming that the Timer will fire, without interruption, at the desired timeInterval. But you should accommodate for interruptions in the Timer (e.g. the UI is blocked momentarily for some reason, the user completely leaves the app and returns, etc.).
We often shift from “decrement some counter with every call of the timer handler” to “figure out at what time we want the timer to expire”. This decouples the “model” (the stop time) from the “view” (the frequency with which the UI is updated). By doing this, if you later decide to update your UI with greater frequency (e.g showing milliseconds rather than seconds, probably using CADisplayLink instead of Timer), it doesn’t change the model driving the app. And it makes your app invulnerable to momentary interruptions that might affect the timer.
If you adopt this pattern, then you can pass around this “stop time”, your model, from view controller to view controller, and each view controller can start and stop its own timer as required by the desired UX for that scene.
So, to start a timer that will stop in 8 seconds:
var stopTime: Date? // set this when you start the timer
func startTimer() {
stopTime = Date().addingTimeInterval(8)
timer = Timer.scheduledTimer(timeInterval: 1, target: self, selector: #selector(jobtime(_:)), userInfo: nil, repeats: true)
}
And the timer handler can determine how much time is left with timeIntervalSince to calculate the floating point difference, in seconds, between two dates.
#objc func jobtime(_ timer: Timer) {
let now = Date()
guard let stopTime = stopTime, now < stopTime else {
timer.invalidate()
return
}
let timeRemaining = stopTime.timeIntervalSince(now)
...
}
I also updated jobtime with a timer parameter so that you can see at a glance that it’s a Timer handler.
FYI, your code introduces a strong reference to the view controller that will prevent it from ever being released. This selector-based Timer keeps a strong reference to its target and the run loop keeps a reference to the Timer, so your view controller won’t be released until you invalidate the Timer.
There are a couple of solutions to this:
Start and stop timers as views appear and disappear:
weak var timer: Timer?
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
timer = Timer.scheduledTimer(timeInterval: 1, target: self, selector: #selector(jobtime(_:)), userInfo: nil, repeats: true)
}
override func viewDidDisappear(_ animated: Bool) {
super.viewDidDisappear(animated)
timer?.invalidate()
}
#objc func jobtime(_ timer: Timer) { ... }
Note, we’re doing this in viewDidAppear and viewDidDisappear (rather than viewDidLoad) to ensure that the starting and stopping of timers is always balanced.
The other pattern is to use block-based Timer, use [weak self] reference to avoid having timer keeping strong reference to the view controller, and then you can invalidate it in the deinit method:
weak var timer: Timer?
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
self.timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { [weak self] timer in
self?.jobtime(timer)
}
}
deinit {
timer?.invalidate()
}
Finally, if you want to update the UI with the greatest possible frequency (e.g. to show milliseconds), you’d probably use a CADisplayLink which is a special timer, perfectly timed for UI updates:
private weak var displayLink: CADisplayLink?
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
let displayLink = CADisplayLink(target: self, selector: #selector(jobtime(_:)))
displayLink.add(to: .main, forMode: .common)
self.displayLink = displayLink
}
override func viewDidDisappear(_ animated: Bool) {
super.viewDidDisappear(animated)
displayLink?.invalidate()
}
#objc func jobtime(_ displayLink: CADisplayLink) { ... }
But the common feature in all of these approaches is that (a) we eliminate strong references from persisting that will interfere with the view controller from getting deallocated when appropriate; and (b) we let every view controller update its UI with whatever frequency it wants.