Thoughts while looking into upgrading from SCNetworkReachabilityGetFlags to NWPathMonitor

Question

Created 10h

Replies 1

Boosts 0

Participants 2

I have been using the SCNetworkReachabilityGetFlags for 10+ years to inform users that their request won't work. In my experience this works pretty well although i am aware of the limitations.

Now, i am looking into the NWPathMonitor, and i have one situation that i'm trying to. get my head around - it's asynchronous.

Specifically, i am wondering what to do when my geofences trigger and i want to check network connectivity - i want to tell the user why the operation i'll perform because of the trigger couldn't be done.

SO. say i start a NWPathMonitor in didFinishLaunchingWithOptions. When the app is booted up because of a geofence trigger, might i not end up in a case where my didEnterRegion / didExitRegion gets called before the NWPathMonitor has gotten its first status?

The advantage here with SCNetworkReachabilityGetFlags, as i understand it, would be that it's synchronous?

If i want to upgrade to nwpathmonitor, i guess i have to do a method that creates a nwpathmonitor, uses a semaphore to wait for the first callback, then contunues?

Thoughts appreciated

Boost

Answer 1

Scott OP

7h

Check out this thread (and the tech talk video it links to) for more general guidance on how best to use reachability checks in your app. You can also find similar threads with a search term such as user:eskimo preflight.

Basically, don't rely on preflighting network operations. Either of the reachability APIs is still asynchronous to your actual network request and can't possibly guarantee that any given request either will or won't succeed. So first make the app solid around network requests that fail for any reason. Then use reachability to add user-facing polish where you can.

0