This would also break while Little Snitch waits for the user’s input, though.
As long as the user hasn’t allowed the connection, I bet you should consider your app is offline. The user may allow the connection, say, one hour later, or deny the connection. As far as your app is concerned, it “is” offline.
What you could do is have a command to retry when the app can’t connect.
I’m only interacting with imap servers. I’m trying to improve error handling and speed. The user enters email address and password. My app tries to guess the imap server from the email address. If a server doesn’t talk to 993 then the server reacts with a timeout. I don’t want to talk to those servers again. But in this case I need to be sure that the computer is really connected to the internet.
I can’t ask Little Snitch if the connection is allowed or not. If Little Snitch blocks the connection it’s similar to switching off your Wifi.
But you can ask the user, if Little Snitch or a similar app is installed and actively blocking. So they may allow the connection before your app retries…
Yup. I’m also going to add an entry in the plist for Little Snitch. But the above code doesn’t work at all when Little Snitch is installed. It immediately gives back “not connected”.
My advice is to not bother with any of this. I get that you’re trying to help your user, but there are too many variables. You can either connect, or you cannot. Trying to figure out why is problematic. The address could be wrong, the port could be wrong, the internet could be down, a local firewall could block it, an external firewall could block it, there could be a downed route, (on Windows) TLS could be disabled, and more.
I’m trying to improve error handling. If I disable wifi I get the same error message as when the server doesn’t exist. In case I don’t have internet connection I want to try the server again. When the server doesn’t exist then I add the server to a list which isn’t tried again:
For my part, I think it is preferable to use CloudFlare’s DNS (1.1.1.1) which does not exploit data unlike that of Google. But the best solution is to use the Apple NWPathMonitor API. If someone wants to implement it under Xojo, I think there are people who would be interested, me first of all…