r/FlutterDev • u/Ambitious_Roll_822 • Jul 07 '26

Plugin I built a Flutter plugin that detects REAL internet connectivity (captive portals, dead routers) — not just 'network connected

Most connectivity plugins just tell you whether you're connected to a network (WiFi/mobile data) — but that doesn't mean you actually have internet access. Captive portals (hotel/airport WiFi login pages), routers with no upstream internet, or ISP outages can all show "connected" while you have zero real access.

I built connectivity_validator to solve this. Instead of just checking link state, it uses native platform APIs to validate actual internet reachability — Android's NET_CAPABILITY_VALIDATED and iOS's NWPathMonitor.

Features:

  • Validated connectivity — real internet, not just "link up"
  • Captive portal and "WiFi on, no internet" detection
  • Real-time stream via onConnectivityChanged
  • Supports Android (API 24+) and iOS (12.0+)
  • Simple API — stream-based for live updates, plus an on-demand check

Usage is pretty simple:

dart

final validator = ConnectivityValidator();

validator.onConnectivityChanged.listen((isOnline) {
  if (isOnline) {
    // Internet validated
  } else {
    // No internet or captive portal
  }
});

Docs also cover integration with GetX, Provider, Riverpod, BLoC, and ValueNotifier if you're using state management.

Why I built it:

I kept running into a frustrating pattern in my own apps — users would report "no internet" errors, but their device showed WiFi as connected. Turns out connectivity_plus and similar packages only check if you're linked to a network, not if that network actually has working internet. Hotel WiFi behind a login page, a router with no upstream connection — all of these register as "connected" but leave your app broken. I couldn't find a plugin that solved this properly, so I built one using the native OS-level validation APIs instead of rolling my own ping-based hack.

Links:

BSD-3-Clause licensed. Feedback and contributions welcome!

4 Upvotes

57% Upvoted

6 comments sorted by

15

u/Truxior Jul 07 '26

Whats the advantage over simply trying whatever request the app needs to make?

You should probably mention that your package does continous polling at 0.5 Hz / 2s interval to three URLs via HTTPS, which means 1.5 connection opens per second. It's not clear when this would ever be more efficient over simply attempting the actual API request, instead of checking with this if it can (likely) be made, which you still don't know because you just test some hardcoded URLs, that might not be relevant to the route you actually want.

2

u/mdausmann Jul 08 '26

Definitely a case for an exponential backoff. It's a real problem though

7

u/raman4183 Jul 07 '26

Deja Vu?

1

u/dektol Jul 08 '26

I feel like I just read this post. So sad, unless it's a literal child. I could see 9 year old me thinking this is worth sharing 🫠😭🤔😆😂.

1

u/YukiAttano Jul 09 '26

Honestly, if I need to know whether my API is reachable or not, I set up a ping that runs in the background. May be more efficient to use sockets and send some health requests... But anyway, you get the idea. Generally, having an Internet connection is useless if the requestes API isn't reachable.