3 ms·
It's bizarre to me that an app would just say it's offline and refuse to function because some system API said it had no connection. Why not ditch the connecti
by Saris 3y ago
It's bizarre to me that an app would just say it's offline and refuse to function because some system API said it had no connection.
Why not ditch the connectivity check and just try connecting and time out like a browser does?
- Zetobal 3y agoYou don't want your clients to hammer your API if you have problems with your API.
- pornel 3y agoSuch API allows showing an offline state immediately, instead of after some timeout. Online-checking request timeout unfortunately needs to be multiple seconds long, because bad cases of packet loss can add seconds of delay, and there's DNS, TCP, and HTTP handshake to perform. There are also some horribly broken networks that get connections stuck and never time out (in browsers too), e.g. TCP-accelerating middleboxes will speculatively accept a TCP connection, and then may blackhole everything else due to a failure upstream. That will look like waiting for a response from the server, forever.
- Saris 3y agoThe API would have the same delay and issues though, wouldn't it?
- pornel 3y agoIt performs the check when the network changes, which may happen long before your app launches.
- robertofrenna 3y agoNot necessarily! `SCNetworkReachability` is deeply integrated within macOS, and is able to tell you very quickly whether e.g. the user has just roamed from one type of network to another: https://developer.apple.com/documentation/systemconfiguration/scnetworkreachabilityflags?language=objc https://developer.apple.com/documentation/systemconfiguratio... Even if you just went and turned off the Wi-Fi interface on your device, `SCNetworkReachability` would know straight away - and from the flags you can deduce exactly what happened and react accordingly. (I do agree though that it's a dangerous approach if it misbehaves, as it happened to me!)