Dispatch Source timer schedule timout - swift

With the following Swift code, I'm trying to create a task that runs every hour:
let queue: DispatchQueue = .main
let timer = DispatchSource.makeTimerSource(queue: queue)
timer.schedule(deadline: .now(), repeating: .seconds(3600), leeway: .milliseconds(100)
timer.setEventHandler { [weak self] in
// run code
}
Now, when I have the repeating set at a lower number, say 10 or event 150 seconds, it triggers as expected both in the foreground and background (or, rather, once the foreground hits it triggers, if the timer went off while in the background).
However, when I let the app timeout to the lock screen, and wait for an hour, it doesn't display.
Is there some timeout that Apple has for DispatchSource schedules? If so, what is it? And is there any way to change or get around it?
Edit
I don't want special functionality when it backgrounds, I want the code to keep running as normal and to trigger the event handler when the timeout happens, even if it's in the background

I ended up taking matt's suggestion and saving the time every time the code gets called, as seen below. Worked well!
let timeOfLastCheck = Date()
let queue: DispatchQueue = .main
let timer = DispatchSource.makeTimerSource(queue: queue)
timer.schedule(deadline: .now(), repeating: .seconds(3600), leeway: .milliseconds(100)
timer.setEventHandler { [weak self] in
timeOfLastCheck = Date()
// run code
}
And elsewhere, where the timer is actually getting created:
let notificationCenter: NotificationCenter = .default
let activeNotificationToken = notificationCenter.addObserver(
forName: UIApplication.didBecomeActiveNotification,
object: nil,
queue: nil
) { [weak self] _ in
let now = Date()
if let `self` = self,
let timeInterval = TimeInterval(dispatchTimeInterval: self.interval), // TimeInterval is extended elsewhere to be able to take in a DispatchTimeInterval in the init
now > timeOfLastCheck.addingTimeInterval(timeInterval) {
self.timeOfLastCheck = Date()
// run code
}
}

Related

Calling stop() on AVAudioPlayerNode after finished playing causes crash

I have an AVAudioPlayerNode object which sends a callback once it is finished playing. That callback triggers many other functions in the app, one of which sends out a courtesy stop() message. For some reason, calling stop() at the moment the AVAudioPlayerNode finishes causes a crash. In the code here, I have abbreviated it so that the AVAudioPlayerNode just calls stop immediately to demonstrate the effect (rather than including my whole application). You can see clearly that it crashes. I don't understand why. Either a) the node is still playing and stop() stops it or b) it is done playing and stop can be ignored.
My guess is that this is some edge case where it is at the very end of the file buffer, and it is in an ambiguous state where has no more buffers remaining, yet is technically still playing. Perhaps calling stop() tries to flush the remaining buffers and they are empty?
func testAVAudioPlayerNode(){
let testBundle = Bundle(for: type(of: self))
let url = URL(fileURLWithPath: testBundle.path(forResource: "19_lyrics_1", ofType: "m4a")!)
let player = AVAudioPlayerNode()
let engine = AVAudioEngine()
let format = engine.mainMixerNode.outputFormat(forBus: 0)
engine.attach(player)
engine.connect(player, to: engine.mainMixerNode, format: format)
let delegate = FakePlayMonitorDelegate()
do {
let audioFile = try AVAudioFile(forReading: url)
let length = audioFile.length
player.scheduleFile(audioFile, at: nil, completionCallbackType: AVAudioPlayerNodeCompletionCallbackType.dataPlayedBack, completionHandler: {(completionType) in
print("playing = \(player.isPlaying)")
player.stop()
})
try engine.start()
let expectation = self.expectation(description: "playback")
delegate.expectation = expectation
player.play()
self.waitForExpectations(timeout: 6.0, handler: nil)
} catch {
}
}
In my case calling the .stop() method from the Main thread (you can use another) has resolved the issue.
DispatchQueue.main.async {
player.stop()
}
It can be the deadlock. I have noticed that the completionHandler is invoked from the background queue which is a serial queue, let's call it a "render queue".
Seems that the .stop() method is trying to do some work on a "render queue" but at the moment a "render queue" is busy with the completionHandler.

Update a progress bar while JSONDecoder is decoding a huge object, in Swift

I'm decoding several gigabytes of JSON encoded data like this
let decoder = JSONDecoder()
let table = try decoder.decode([LogRow].self, from: content!)
where content is plain text. Now, this operation can take several minutes, depending on the size of content, and I'd like to show some kind of progress. This is a command line program, so even a periodic update on the length of table would be enough. The problem is that I don't see anything like a callback or something like that. I tried with a rather awkward Timer like this
var table: [LogRow]? = []
let timer = Timer(fire: Date(), interval: 1.0, repeats: true) { t in
print("\(table?.count ?? 0) rows parsed.")
}
timer.fire()
table = try decoder.decode([LogRow].self, from: content!)
timer.invalidate()
but that only runs once -- is it because the decoder blocks the main thread and I'm running the timer in the same thread? I'm a bit of a noob with the GCD so I'm not sure how to go about using a DispatchQueue for this.
Any ideas?
Then can declare your timer like:
let timer = Timer.scheduledTimer(timeInterval: 1, target: self, selector: #selector(self.updateUI), userInfo: nil, repeats: true)
DispatchQueue.global(qos: .background).async {
self.perform(#selector(self.decode), on: Thread.current, with: nil, waitUntilDone: true)
timer.invalidate()
}
which means you want to trigger the updateUI action every second. Then you start to decode in a background thread and wait until done before invalidate your timer.
var totalDuration: Int = 0
#objc func updateUI () {
self.currentDuration += 1
print("------------> \(self.currentDuration)")
}
#objc func decode () {
table = try decoder?.decode([LogRow].self, from: content!)
}
I added a currentDuration variable which could be used in your progressBar. But you must know the total duration if you need to show a percentage to your user.

GCD `asyncAfter` does not start when app in background/inactive

I'm using AVAudioPlayer for playing records. Between each playback session I have interval from 0 to 10 sec. To make this interval I'm using AVAudioPlayerDelegate and when playing is finished I'm starting new playback after delay:
func audioPlayerDidFinishPlaying(_ player: AVAudioPlayer, successfully flag: Bool) {
guard let session = playbackSessionId,
let audioTrack = audioTrack,
let failureHandler = playingFailure,
let successHandler = playingSuccess else {
playingFinished(flag, error: nil)
return
}
print("audioPlayerDidFinishPlaying fired")
DispatchQueue.global(qos: .utility).asyncAfter(deadline: .now() + LoopInterval.currentInterval) { [weak self] in
print("asyncAfter fired")
guard let strongSelf = self,
let currentSession = strongSelf.playbackSessionId, session == currentSession else { return }
strongSelf.startPlayingRecordInLoop(audioTrack, success: successHandler, failure: failureHandler)
}
}
After app goes to the background (home button), audioPlayerDidFinishPlaying fires, but DispatchQueue.global(qos: .utility).asyncAfter not. So in console I see:
audioPlayerDidFinishPlaying fired
As soon as app become active, asyncAfter fires and I see next log message:
asyncAfter fired
When app is active, all works as expected.
Hope it'll help someone. I found problem: when app goes in background it stops background tasks, and fires them only after becomes active. To avoid need you should keep your app running in background and awaiting for your long-running background task.
backgroundTaskID = UIApplication.shared.beginBackgroundTask(expirationHandler: {
UIApplication.shared.endBackgroundTask(backgroundTaskID)
})
This method lets your app continue to run for a period of time after it transitions to the background. You should call this method at times where leaving a task unfinished might be detrimental to your app’s user experience. For example, your app could call this method to ensure that had enough time to transfer an important file to a remote server or at least attempt to make the transfer and note any errors. You should not use this method simply to keep your app running after it moves to the background.
After task finished you should call endBackgroundTask. If you won't end background task until backgroundTimeRemaining becomes 0, app will be terminated:
UIApplication.shared.endBackgroundTask(backgroundTaskID)
Each call to this method must be balanced by a matching call to the endBackgroundTask(:) method. Apps running background tasks have a finite amount of time in which to run them. (You can find out how much time is available using the backgroundTimeRemaining property.) If you do not call endBackgroundTask(:) for each task before time expires, the system kills the app. If you provide a block object in the handler parameter, the system calls your handler before time expires to give you a chance to end the task.
That's what I did in my case:
func audioPlayerDidFinishPlaying(_ player: AVAudioPlayer, successfully flag: Bool) {
guard let session = playbackSessionId,
let audioTrack = audioTrack,
let failureHandler = playingFailure,
let successHandler = playingSuccess else {
playingFinished(flag, error: nil)
return
}
backgroundTaskID = UIApplication.shared.beginBackgroundTask(expirationHandler: { [weak self] in
guard let taskId = self?.backgroundTaskID else { return }
UIApplication.shared.endBackgroundTask(taskId)
})
DispatchQueue.global(qos: .utility).asyncAfter(deadline: .now() + LoopInterval.currentInterval) { [weak self] in
guard let strongSelf = self,
let currentSession = strongSelf.playbackSessionId, session == currentSession else { return }
strongSelf.startPlayingRecordInLoop(audioTrack, success: successHandler, failure: failureHandler)
if let backgroundTaskID = strongSelf.backgroundTaskID {
UIApplication.shared.endBackgroundTask(backgroundTaskID)
strongSelf.backgroundTaskID = nil
}
}
}

Do I need capture self using thread class?

I have this code:
myThreadTemp = Thread(target: self, selector: #selector(threadMain), object: nil)
#objc func threadMain(data: AnyObject) {
let runloop = RunLoop.current
runloop.add(NSMachPort(), forMode: RunLoopMode.defaultRunLoopMode)
while !Thread.current.isCancelled{
//foreground
DispatchQueue.main.async {[weak self] in
self?.somemethod()
self?.somevar = 1
print("tick")
}
if Thread.current.isCancelled {
}
Thread.sleep(forTimeInterval: 1.0)
}
runloop.run(mode: RunLoopMode.defaultRunLoopMode, before: NSDate.distantFuture)
}
or I can just do this:
DispatchQueue.main.async {
self.somemethod()
self.somevar = 1
print("tick")
}
I saw this:
Shall we always use [unowned self] inside closure in Swift
But was if #objc func is used?
The 1st example looks to spin the runloop indefinitely, waiting 1s between ticks, whereas the 2nd example will execute once, on the very next run loop iteration. There is no memory management issue in terms of capturing self in the 2nd case, indeed because it is only executed once and the block is released after it (breaking the momentary retain loop that does exist between self and the block).
Assuming you are trying to tick every 1s (as I am guessing based on your questions), there is a better way to do what you are trying to do, using a timer:
// Must be executed on main thread, or other NSRunLoop enabled thread,
// or the below code will silently do nothing.
self.timer = Timer(timeInterval: 1.0, repeats: true) { [weak self] _ in
self?.someMethod()
self?.someVar = 1
print("tick")
}
// Somewhere in the future, to stop the timer:
// self.timer.invalidate()
As you can see in the above example, with the timer case you might indeed want to refer to self with either an unowned or weak reference (as the timer block will otherwise make a strong reference to self, and self to the timer). The block should be released on invalidating the timer too, so even in this case the weak reference is not 100% necessary I guess.

DispatchSourceTimer and Swift 3.0

I can't figure out how to make dispatch timer work repeatedly in Swift 3.0. My code:
let queue = DispatchQueue(label: "com.firm.app.timer",
attributes: DispatchQueue.Attributes.concurrent)
let timer = DispatchSource.makeTimerSource(flags: DispatchSource.TimerFlags(rawValue: UInt(0)),
queue: queue)
timer.scheduleRepeating(deadline: DispatchTime.now(),
interval: .seconds(5),
leeway: .seconds(1)
)
timer.setEventHandler(handler: {
//a bunch of code here
})
timer.resume()
Timer just fires one time and doesn't repeat itself like it should be. How can I fix this?
Make sure the timer doesn't fall out of scope. Unlike Timer (where the RunLoop on which you schedule it keeps the strong reference until the Timer is invalidated), you need to maintain your own strong reference to your GCD timers, e.g.:
private var timer: DispatchSourceTimer?
private func startTimer() {
let queue = DispatchQueue(label: "com.firm.app.timer", attributes: .concurrent)
timer = DispatchSource.makeTimerSource(queue: queue)
timer?.setEventHandler { [weak self] in // `[weak self]` only needed if you reference `self` in this closure and you want to prevent strong reference cycle
print(Date())
}
timer?.schedule(deadline: .now(), repeating: .seconds(5), leeway: .milliseconds(100))
timer?.resume()
}
private func stopTimer() {
timer = nil
}