Network connectivity (headless capability crate)
Status: implemented as
day-part-network(inparts/, the headless counterpart ofpieces/), a headless day-ecosystem crate with no UI Piece: a shared cross-platform API for reading a snapshot of the device’s network connectivity through each platform’s native API. Any Rust code can depend on it and callday_part_network::status(). Verified on macOS (real online reading); iOS-sim/Android clippy-clean and HarmonyOS cross-compiles + links against the nativelibnet_connection.so.
Authoring
if let Some(n) = day_part_network::status() {
println!("online: {}, kind: {:?}, expensive: {:?}", n.online, n.kind, n.expensive);
}
status() -> Option<NetworkStatus> returns None where there’s no connectivity API (or the reading
failed), which is distinct from a successful reading that says offline (Some with online: false).
NetworkStatus { online: bool, kind: NetworkKind, expensive: Option<bool> }; NetworkKind is
Wifi | Cellular | Ethernet | Other | None.
There are no crate features; platform selection is purely #[cfg(target_os)], because connectivity is
an OS concern rather than a widget-toolkit one. parts/day-part-network/examples/network.rs is a plain
main that uses it with no Day framework at all.
Per-platform native realization
| OS | API | dependency |
|---|---|---|
| macOS | SCNetworkReachability (SystemConfiguration) | raw C FFI, shared apple.rs |
| iOS | SCNetworkReachability (IsWWAN ⇒ cellular) | raw C FFI, shared apple.rs |
| Windows | GetNetworkConnectivityHint (iphlpapi, resolved dynamically) | raw FFI (kernel32 + runtime lookup) |
| Linux | /sys/class/net interface scan | std only |
| HarmonyOS | OH_NetConn_HasDefaultNet / GetNetCapabilities (libnet_connection.so) | raw FFI (NetworkKit) |
| Android | ConnectivityManager + NetworkCapabilities via a Java shim | day-android + [package.metadata.day.android] |
What each platform can report
Every field is best-effort; the platforms report different amounts of detail:
- macOS/iOS: reachability answers “could traffic to the default route flow right now?” from the
routing table. It sends no packets, so it cannot detect a captive portal or a dead upstream:
onlinemeans routable, not verified internet. The only transport bit isIsWWAN(iOS-only): cellular reportsCellular+expensive: Some(true); any other reachable iOS connection reportsWifi(the classic “ReachableViaWiFi” reading; it could in fact be wired or a tether). macOS gets no transport info at all, so an online Mac reportsOther,expensive: None. - Android: the richest reading.
onlineis the system’sINTERNET+VALIDATEDverdict for the active network,kindcomes fromTRANSPORT_WIFI/CELLULAR/ETHERNET, andexpensiveis the inverse ofNET_CAPABILITY_NOT_METERED. Requiresandroid.permission.ACCESS_NETWORK_STATE, a normal install-time permission the crate contributes to the manifest itself (see below). - HarmonyOS:
online= a default network is activated;kindfrom the bearer type,expensivefromNETCONN_NET_CAPABILITY_NOT_METERED. The app must declareohos.permission.GET_NETWORK_INFOin itsmodule.json5(requestPermissions; normal permission, no prompt) or the calls fail with 201 andstatus()returnsNone. - Linux: no daemon-independent connectivity API is guaranteed (NetworkManager is optional), so
the crate scans
/sys/class/net:online= a non-loopback interface has operstateup(link-level, not validated internet);kindfrom the kernel’s predictable name prefixes (wl*wireless,en*/eth*wired,ww*wwan), preferring wired > wifi > cellular when several are up;expensiveis alwaysNone(meteredness is a desktop-session concept). - Windows:
GetNetworkConnectivityHint(Windows 10 2004+, blind like the rest of the xaml backend) gives a connectivity level (online= internet or constrained-internet access) and a cost (expensive) but no transport, sokindisOtherwhen online. The symbol is resolved at runtime viaLoadLibrary/GetProcAddress, so apps still start on older Windows;status()just returnsNonethere.
A snapshot is a point-in-time poll; a change-notification rail (SCNetworkReachability callbacks,
Android NetworkCallback, OH_NetConn_RegisterNetConnCallback, NotifyNetworkConnectivityHintChange)
is a v2 follow-up.
Connectivity says whether traffic could flow; to actually move bytes through the platform’s HTTP
stack (proxies, VPN, platform TLS), see its sibling part day-part-http.
What it shows about the extension system
Like day-part-battery, this is a headless external crate: it has no UI Piece and registers nothing
into any backend’s RENDERERS slice. It additionally exercises the manifest-permission overlay
(from the webview work, docs/extending.md): [package.metadata.day.android] stages its own Java shim
and contributes android.permission.ACCESS_NETWORK_STATE, which day build merges into the app
manifest with no changes to any core Day crate. On Android the crate rides on the Day runtime
(day-android’s cached JVM + DayBridge.ctx); on every other platform it is fully day-independent.