FB21298709

When we made this, like back in 2013, we (thought we) had situations where the system killed the geofence trigger before it had a chance to complete its network request. The thought was that if we checked the network status before we do the actual http request, we reduced the risk of the trigger being killed before we had a chance to put up a notification explaining to the user that we failed and why. We do the whole UIBackgroundTaskIdentifier but back then the documentation (we thought at the time) made it a bit uncertain if we could be sure that we'd always get a chance to finish and clean up properly.

Yeah, my process is basically when i get a trigger: check network status (the old, lame way :) ) if network down or other issue, create local notification failure user explanation and exit if all good, get a background task id and start working It was a long time since we initially evaluated this, but back then we had issues with being killed off mid-flight sometimes. As you can perhaps guess, i didn't document everything, and it's totally possible that we did something wrong or that whatever wasn't working 100% right now. So, what you are saying is that i should not bother with NWPathMonitor (or the one i'm using right now) at all? just fire off the request blindly and wait to see what happens?

It would have been nice with an acknowledgment from someone, anywhere, that "Yes your eyes do not deceive you, we also can see the issue."

I am not sure what that has to do with anything? I am reporting a bug in UIKit, a pretty popular framework that you support, while noting that i've found several apps, being sold on the app store, that show similar behavior. I have taken time off a busy schedule to report a bug, discuss and even put together a full project to display the issue. It would then be useful to hear someone say "yes it does look like something is off here, we'll look at it." To Instead being rewarded with critique on the quality of my app, of which you've basically only seen one line of code does not encourage further bug reporting. FURTHERMORE, while the code line above is Objc, my entire test project that i submitted is Swift, showing the same behavior. But i guess that confirms that you didn't look at it. I am aware that parts of my app is objective C and that Swift exists, but thank you for reminding me.

Mr. Eskimo, huge thanks for a great response. Not 100% about "mode to the networking layer", do you mean basically add Thread.sleep on the server when testing? I will take your suggestions to heart. It's great since i'm also rewriting my objc networkhandler in Swift. Just a final belt/suspenders-question: If i understand you correctly, most applications should just perform the request regardless, wait for the API response/timeout and not bother at all with NWPathMonitor ?