BGProcessingTask and completionHandler behavior

Question

jpsoward OP

Created May ’20

Replies 2

Boosts 0

Views 1.6k

Participants 2

I think I'm missing something conceputually with the BGProcessingTask.

I've worked through the demo and built a couple of my own examples in both Swift and Obj-C.

They "work" in that I can schedule tasks and they get fired and execute for some amount of time, but the completion handler is never called, instead the background task is just suspended, and of course, there is no notification that your process is about to be suspended ( other that what appears in the system log. ) In fact, just adding a couple of nested loops and some mathematicall calculations to

What I _thought_ you could do with a BGProcessingTask was to do some computationally intensive work periodically in the background, for some number of seconds to minutes, then get told to wrap it up. Were this true, one could work along until your were told to stop, check-point your work and resume it the next time you are scheduled. Instead your process runs briefly then gets suspsended, and will resume when the user foregrounds the app, continuing to run and slow down the rest of the device -- sure you can detect when your app was returned to the FG, and message the running background asking it to checkpoint and stop, but that's considerably less usefull.

Likewise, I've yet to see a BGProcessingTask that, once suspended, was reactivated ( i.e. sent a SIGCONT ) after being suspended, except when the Application was foregrounded -- though it is possible I have just not been patient enough to catch that.

Can anyone verify if this is the intended ( or at least known ) behaviour?

Thanx,

JpS

Boost

Answer 1

hhtouch OP

Jul ’20

We are seeing the same behavior on recent iOS versions. More details here: https://developer.apple.com/forums/thread/654355

I don't think that this is intended behavior as for a background task only two conditions should be possible by definition/documentation:

If the background work is done, you mark the task yourself as completed using:

Code Block func setTaskCompleted(success: Bool)

If the task is not marked for completion, the system will eventually kill the app according to the documentation.

2. In case that the background work takes longer than the system allows under current conditions, the task will run into the expiration handler set by

Code Block var expirationHandler: (() -> Void)? { get set }

If no expiration handler is set, the system will mark the task itself as completed according to the documentation.

This is also the behavior we saw at least up to iOS 13.3 or even iOS 13.4.
That a background tasks goes into suspended state itself makes no logical sense from my perspective.

@jpsoward Could you ever resolve the issue or do yo have more information on it?

0

Answer 2

jpsoward OP

Aug ’20

@hhtouch No changes from my perspective. I tried a short test with an 'even newer' version of iOS ( XIV ) and the behavior seemed the same. Might give it another try this week and see if anything has changed with any dot releases.

I agree that suspended the background task makes no sense, at least not indefinitely -- maybe briefly in response to some transient condition or something, but even that seems like an far corner case.

0