fix(#291): route into the app from the scanner on any transport

The scanner's auto-entry was gated on activeTransport == bluetooth, so the
dead end fixed in the previous commit still applied to USB and TCP: a user
landing on the scanner with a live serial or network connection stayed stuck,
and pressing Connect did nothing, since there was nothing left to connect.

Both are real deployment paths, so the gate is removed and the check is now
transport-agnostic.

The first-connect path for USB and TCP is unaffected. Those screens are pushed
on top of the scanner and navigate themselves with pushReplacement; while they
are connecting they are the current route, so the scanner's isCurrentRoute
guard is false and it does not also push. That guard, not the transport check,
is what prevents a double navigation.

flutter analyze clean, dart format clean, 469 tests pass.
integration/290-306-335
Strycher 2 days ago
parent 4dbceb3366
commit c8b36b056d

@ -45,13 +45,18 @@ class _ScannerScreenState extends State<ScannerScreen> {
if (_connector.state == MeshCoreConnectionState.disconnected) {
_changedNavigation = false;
} else if (_connector.state == MeshCoreConnectionState.connected &&
_connector.activeTransport == MeshCoreTransportType.bluetooth &&
isCurrentRoute &&
!_routingIntoApp) {
// Route in whenever this screen is showing while connected, not just
// on the first connect. Otherwise landing back here with a live
// connection is a dead end: Connect does nothing, because there is
// nothing left to connect.
//
// Deliberately transport-agnostic. This was bluetooth-only, which left
// the same dead end for USB and TCP users, who cannot connect their way
// out of it either. The first-connect path for those transports is not
// affected: their own screen sits on top while connecting, so
// isCurrentRoute is false here and they still navigate themselves.
_changedNavigation = true;
_routingIntoApp = true;
if (mounted) {

Loading…
Cancel
Save

Powered by TurnKey Linux.