Suche, Home- und Fit-Button sassen bisher in einer eigenen Leiste unter der Plan/Fly-Kopfleiste - ein reiner UI-Kompromiss, weil die Karte (inkl. MapController) in PlanScreen lebte und von der aeusseren Kopfleiste aus nicht erreichbar war. Der HTML-Demonstrator zeigt Suche/Home/Fit dagegen als Mittelteil derselben Leiste wie die Modus-Buttons (#searchWrap/#homeBtn/#fitBtn in #topBarMiddle) - das war also keine Stilfrage, sondern eine Datenfluss-Frage. Loesung: MapController aus einem PlanScreen-privaten Feld in einen app-lebenslangen mapControllerProvider (Riverpod) gehoben. Damit kann die neue MapSearchControls (ersetzt TopNavBar) direkt in TopModeBar eingebettet werden und lebt architektonisch dort, wo sie hingehoert: bei der Kartensteuerung, nicht als Kind von PlanScreen. Als Nebeneffekt - tatsaechlich der wichtigere Punkt - bleibt die Kamera-Position/Zoom jetzt auch beim Wechsel Plan -> Fly -> Plan erhalten. Verifiziert per flutter_map-Quellcode (FlutterMap haengt einen extern uebergebenen Controller beim Neu-Mounten nicht an und disposed ihn nicht) sowie per neuem Widget-Test, der den Cubit direkt durch das Ready-to-Fly-Gate schickt (der Fly-Modus ist ueber die UI aktuell nicht erreichbar, da Upload/Verify noch nicht implementiert ist) und die Kamera vor/nach dem Wechsel vergleicht. Zusaetzlich: _onMapEvent unterscheidet jetzt per MapEventMove.source, ob eine Kartenbewegung programmatisch (mapController, z.B. durch Suche/ Home/Fit) oder per Geste ausgeloest wurde, und triggert den Snap-to-Edit-Handler entsprechend nur bei Gesten bzw. sofort bei programmatischen Moves - das ersetzt den bisherigen Ansatz, an jeder Aufrufstelle manuell _handleMoveEnd() zu rufen, der nicht mehr skaliert sobald diese Aufrufstellen (wie jetzt) in einem anderen Widget liegen. Verifiziert: flutter analyze (0 issues), flutter test (22/22, inkl. neuem Kamera-Persistenz-Test), manuell auf Pixel_10a-Emulator (Release- Build) - Suche/Home/Fit erscheinen fusioniert in der gruenen Pille, Kartenverschiebung bleibt nach Wechsel in den (durch das Gate weiterhin blockierten) Fly-Modus sichtbar unveraendert. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
23 lines
1.1 KiB
Dart
23 lines
1.1 KiB
Dart
import 'package:flutter_map/flutter_map.dart';
|
|
import 'package:flutter_riverpod/flutter_riverpod.dart';
|
|
|
|
/// Ein einziger, app-lebenslanger MapController statt einer pro
|
|
/// PlanScreen-Mount neu erzeugten Instanz.
|
|
///
|
|
/// Grund: Die Kopfleiste (AppShell/TopModeBar) liegt eine Ebene ueber
|
|
/// PlanScreen und braucht fuer Suche/Home/Fit denselben Controller wie die
|
|
/// Karte - ein PlanScreen-privates Feld waere von dort nicht erreichbar.
|
|
/// Als Nebeneffekt (und in Wahrheit der wichtigere Punkt) bleibt die
|
|
/// Kamera-Position/Zoom jetzt auch ueber einen Wechsel nach Fly und
|
|
/// zurueck erhalten: flutter_map tastet einen extern uebergebenen
|
|
/// MapController beim erneuten Mounten nicht an (siehe
|
|
/// FlutterMap._setMapController()), anders als der bisherige Zustand, wo
|
|
/// PlanScreens eigener Controller beim Verlassen des Plan-Modus komplett
|
|
/// verworfen wurde. Entspricht damit auch besser dem HTML-Demonstrator,
|
|
/// der nur eine einzige Leaflet-Instanz fuer die gesamte App kennt.
|
|
final mapControllerProvider = Provider<MapController>((ref) {
|
|
final controller = MapController();
|
|
ref.onDispose(controller.dispose);
|
|
return controller;
|
|
});
|