fix: Fehlerbehandlung beim Laden und Meldungen überarbeiten

Reklamationen der Fahrer: Meldungen verdeckten Buttons, und nach dem
Abschluss stand „Lieferung nicht in der Tour gefunden" ohne Ausweg da.

Meldungen:
- Erfolgs-SnackBars entfernt, bei Erfolg bleibt der Spinner
- einheitliche, schwebende Meldungen statt Stau über den Buttons
- Server-Rohtexte durch verständliche Texte ersetzt (api_failure_text)

Laden:
- fehlt eine geöffnete Lieferung, wird die Tour einmal neu geholt; die
  Meldung kommt nur nach erfolgreichem Abruf ohne die Lieferung
- Endlos-Spinner auf Lieferdetail, Filial-Abholung und Beladen ersetzt
  durch Kopfzeile, Fehlergrund und „Erneut versuchen"
- Tour wird nach einem Tageswechsel nachgeladen, offene Seiten bleiben
  dabei unberührt
- Abschluss und Zuweisung überschreiben kein zwischenzeitliches Neuladen,
  alte Antworten drehen einen Abschluss nicht mehr zurück
- leere Server-Antworten gelten als Fehler statt als „keine Daten"

Anmeldung:
- Token-Erneuerung wartet höchstens 12 s, der native Aufruf läuft weiter
- App-Start ohne Netz zeigt einen Hinweis mit „Erneut versuchen"
- Fehlerseite der Fahrzeugauswahl bietet „Abmelden"

Außerdem Podfile.lock an die Plugins angeglichen. Tests für die neuen
Fehlerpfade ergänzt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Dennis Nemec
2026-10-30 20:28:24 +01:00
parent 2ff331294e
commit bc95fe9577
40 changed files with 2063 additions and 365 deletions

View File

@ -10,6 +10,7 @@ import 'package:hl_lieferservice/feature/delivery/bloc/tour_date_cubit.dart';
import 'package:hl_lieferservice/feature/delivery/bloc/tour_event.dart';
import 'package:hl_lieferservice/feature/delivery/bloc/tour_state.dart';
import 'package:hl_lieferservice/feature/delivery/model/delivery_phase.dart';
import 'package:hl_lieferservice/widget/app_message.dart';
/// Horizontaler Phasen-Stepper für die drei bzw. vier Schritte
/// (Auswählen) → Sortieren → Beladen → Ausliefern.
@ -85,13 +86,9 @@ class PhaseStepper extends StatelessWidget {
// Vergleich über die natürliche Enum-Reihenfolge, weil "höchste erreichte
// Phase" cross-Team konsistent ist (1- vs. Mehr-Auto-Teams).
if (target.index > maxReached.index) {
ScaffoldMessenger.of(context).showSnackBar(
SnackBar(
content: Text(
"Schritt \"${target.displayName}\" ist noch nicht erreicht.",
),
duration: const Duration(seconds: 2),
),
context.showAppMessage(
"Schritt \"${target.displayName}\" ist noch nicht erreicht.",
duration: const Duration(seconds: 2),
);
return;
}
@ -499,17 +496,16 @@ class _ReloadButton extends StatelessWidget {
listener: (context, state) {
if (state is! TourLoaded || state.refreshError == null) return;
final bloc = context.read<TourBloc>();
ScaffoldMessenger.of(context)
..hideCurrentSnackBar()
..showSnackBar(
SnackBar(
content: Text(state.refreshError!),
action: SnackBarAction(
label: 'Erneut versuchen',
onPressed: () => bloc.add(const RefreshTour()),
),
),
);
context.showAppMessage(
state.refreshError!,
// Länger als üblich, damit die Aktion erreichbar bleibt. Danach ist
// der Reload-Button im Header weiterhin da.
duration: const Duration(seconds: 6),
action: SnackBarAction(
label: 'Erneut versuchen',
onPressed: () => bloc.add(const RefreshTour()),
),
);
},
// Nur neu rendern, wenn sich der Refresh-Status ändert — sonst
// läuft der Builder bei jedem Scan-Tick mit.