[connectivity_plus][iOS] checkConnectivity returns None unexpectedly occasionally

[amantoux]

Since 2.3.0, connectivity_plus sometimes returns ConnectivityResult.none inappropriately.

I suspect it is related to the introduction of PathMonitorConnectivityProvider for iOS version >= 12

Comparing with ReachabilityConnectivityProvider, that latter uses by default the .default QoS queue whereas PathMonitorConnectivityProvider uses .background QoS queue.

Maybe the use of .default would be better

https://github.com/fluttercommunity/plus_plugins/blob/89993a6339cf74594e88bc48f861d0c95e8b21ea/packages/connectivity_plus/connectivity_plus/ios/Classes/PathMonitorConnectivityProvider.swift#L7

[AliRezaBeitari]

Might be related: https://github.com/fluttercommunity/plus_plugins/issues/852

[jfahrenkrug]

I'm also seeing this sometimes, but it seems to only happen in the Simulator. I've tested on the device and it seems to work fine. On the Simulator it's almost like it's flipped: When I turn wifi ON it returns "none", when I turn wifi OFF, it returns "wifi".

[elyssaDev]

I'm seeing it now on an iOS 15.5 physical device, not just in the Simulator, so idk.

[adminant]

I also have the problem in iOS 15.4 with connectivity sometimes returns 'none' when in fact wifi internet is always on. I call checkConnectivity() in my routing navigator class, and for some page routes it returns 'none' for no reason.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days

[FlutterWiz]

the same issue is here in the last days of 2022.

[anchals333]

I'm facing the same issue in android & iOS physical devices. This issue usually comes when we move the app from background to foreground then even the internet is connected the connectivity status returns none.

[poojadev]

I'm still facing the same issue on Ios "checkConnectivity returns None unexpectedly occasionally" is there any solution ?

[elyssaDev]

If you need a solution in the meantime, check out internet_connection_checker. They even have this code block in their README, for easy migration:

var isDeviceConnected = false;

var subscription = Connectivity().onConnectivityChanged.listen((ConnectivityResult result) async {
  if(result != ConnectivityResult.none) {
    isDeviceConnected = await InternetConnectionChecker().hasConnection;
  }
});

Personally, I still had issue on the first check on iOS, so I added in a delayed second check before showing the user an error. It's not the cleanest code I've written, but it's better than not having the feature at all.

Hope that helps while we wait!

[adminant]

Still, in 2023 the problem persists on iOS 15.1. I switch off wifi on iPhone, the listener comes with ConnectivityResult.none, it's ok. Then, I switch on wifi, and during a couple of seconds the ConnectivityResult.wifi arrives, then ConnectivityResult.none, then again ConnectivityResult.wifi. So all my app logic is ruined. What should I do?

[gmjgh]

To workaround the issue, you can add an empty onConnectivityChanged listener somewhere in your code - after this, the method Connectivity().checkConnectivity() will return a correct value.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days

[Saurabh-Detharia]

Any update on this? When I check the status first time on iOS, it's always giving none and then the next time, it works fine. I think this issue took long, see #198.

[praxder]

This is still an issue

[LeonardoRosaa]

I'm seeing it now on an iOS 15.5 physical device, not just in the Simulator, so idk.

Same here. Some users have this on physical devices as well.

[prabakaranios]

// if #available(iOS 12, *) { // connectivityProvider = PathMonitorConnectivityProvider() // } else { connectivityProvider = ReachabilityConnectivityProvider() // }

It will work when you use the ReachabilityConnectivityProvider provider. because it's having a bug in the PathMonitorConnectivityProvider class.

below are steps, you can take to reproduce the bug.

1. place the breakpoint.
2. Initially you will get unsatisfied. so you will get none
3. after that it's getting satisfied and you will get a valid status.

Team, please fix the bug.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 15 days

[miquelbeltran]

There is a PR that is doing some changes on iOS connectivity code. Anyone would like to help to review it? https://github.com/fluttercommunity/plus_plugins/pull/2599 I'd like to know if this issue could be resolved there too.

[iamsharad98]

I have used this as temporary fix,

`

if(_connectionStatus == ConnectivityResult.none && result == ConnectivityResult.none){ return; } _connectionStatus = result; try { final result = await InternetAddress.lookup('google.com'); if (result.isNotEmpty && result[0].rawAddress.isNotEmpty) { print('connected'); connectionStatus = ConnectivityResult.wifi; } } on SocketException catch () { print('not connected'); }`

[miquelbeltran]

I've been reading through the thread, and it's hard to follow what the actual issue is and how to reproduce it. Anyone facing this issue still, I'd recommend creating a new ticket providing up-to-date information on how to reproduce the issue.

---

Regarding the suggestion on changing the DispatchQueue priority: This is something that I am open to explore, at the moment the plugin uses .background.

Looking at the available ones: https://developer.apple.com/documentation/dispatch/dispatchqos what I have seen if some examples link using .utility, which seems a better option, and I agree that probably .background is too low.

static let default: DispatchQoS The default quality-of-service class. static let utility: DispatchQoS The quality-of-service class for tasks that the user does not track actively. static let background: DispatchQoS The quality-of-service class for maintenance or cleanup tasks that you create

I'll probably do a PR with that.

[miquelbeltran]

After doing some tests with QoS .utility and .userInitiated I cannot see any differences with .background.

What can be observed is that NWPathMonitor is just unreliable. I'd be getting NWPath saying it is "satisfied" even when having no network, and then getting "unsatisfied" when reconnecting, then immediately getting a new callback with a "satisfied" one. That's why some users report getting "none" and then "wifi" immediately, and I could observe this both with .background and .userInitiated.

This, to me, doesn't look like a problem with the plugin, but rather a problem of how NWPathMonitor is not very reliable.

The documentation already mentions:

You should not be using the current network status for deciding whether you can reliably make a network connection.

I will add some comments about the unreliability of the iOS API to the README, there is not much more we can do IMO.

Edit: I will also provide some extra refactor, and increase the DispachQueue QoS to utility as seems the right choice here.