search

flutter-mapbox-gl / maps

A Mapbox GL flutter package for creating custom maps
Other
1.04k stars 503 forks source link

Zoom gesture works only on half screen on orientation change #195

Open SergioOrellanaR opened 4 years ago

SergioOrellanaR commented 4 years ago

When phone orientation changes (From portrait to landscape and vice versa) zoom gestures work only on half screen (where the original orientation pixels are equals to new orientation).

This was tested into a mapBoxMap builded with a lot of widgets and on a page with only a Scaffold and a instance of mapboxmap (Android).

m0nac0 commented 4 years ago

I was able to reproduce this. If I tilt my phone from vertical to horizontal (counter-clockwise), for example, about the right half of the screen doesn't react to drag or zoom gestures. Double tapping works and drag gestures started in the "unresponsive area" that continue to the "responsive area" work for the part in the "reponsive area".

SebastianSmolorz commented 4 years ago

I'm also experiencing this. Originally noticed the same issue in portrait mode so I started to cut away parent comonents to isolate the issue but I was not able to reproduce it reliably. It makes me think that it's something to do with redrawing the map rather than tilting itself.

tobrun commented 4 years ago

Thank you all for chiming in, I'm having trouble reproducing this. Could someone :eyes: #201 and check how that setup differs from yours? Do you have a specific setup for handling orientation changes? Atm I'm guessing that the resize isn't correctly handled, having a minimal reproducible test case would be great!

m0nac0 commented 4 years ago

@tobrun I just checked out #201 and I can still reproduce this bug on my physical Android 8.0 device with that new example.

mindthefish commented 3 years ago

Still having this issue with the latest version. My map is on fullscreen within a Stack. Tapping works fine, pinching only in the "old" area before the orientation change. I will check the example project to find an easy to reproduce setup.

mindthefish commented 3 years ago

The issue is actually pretty easy to reproduce. Simply run the "Full screen map" example and change the orientation. When changed from landscape to portrait, the pinch or drag gesture in the lower area does not work. When changing from initially portrait mode to landscape, the pinch or drag gesture in the right area does not work. Wrapping the MapboxMap into an OrientationBuilder does not fix it either. Although the build function is called, the map is not getting reinitialised (the onMapCreated function is not called).

mindthefish commented 3 years ago

As a dirty workaround it is possible to rebuild the widget tree two times. First time returning an empty Container and add a post frame callback, second time the entire tree including map. This reinitializes the map and updates the gesture active area. This adds a lot of lag and 0,5 seconds empty screen so definitely not recommended. This should be fixed within Mapbox.

mindthefish commented 3 years ago

Is there any update on this issue? The problem still persists. Reinitialising the map causes other issues, because Flutter Mapbox seems to loose track of some channel methods after the rebuild, so after orientation change I get "MissingPluginException". I really appreciate a clean solution for this issue.

raphaelvigee commented 3 years ago

This is also happening when opening/closing the keyboard...

teddichiiwa commented 3 years ago

Same here...

teddichiiwa commented 2 years ago

Found a hacky way to fix this issue after 1 month struggling with it:

  1. Wrap FlutterMapWidget inside SizedBox:
  2. Use the code below to set width & height of the SizedBox, flag flutterMapInitialized to false 
    width: flutterMapInitialized
     ? MediaQuery.of(context).size.width
     : max(MediaQuery.of(context).size.width, MediaQuery.of(context).size.height),
height: flutterMapInitialized
      ? MediaQuery.of(context).size.height
      : max(MediaQuery.of(context).size.width, MediaQuery.of(context).size.height)
  3. Then listen when camera move started call back, set flutterMapInitialized to true.

Sum up: Make a square SizedBox with side = max(screenWidth, screenHeight), then set the SizedBox's side back to equals the screen size after first camera move started callback called.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

maxammann commented 2 years ago

@teddichiiwa Somehow I'm failing at applying your fix to flutter-maplibre-gl. Can you maybe elaborate what the idea behind the fix is and what "when camera move started call back" means? Which callback are you referring to?

maxammann commented 2 years ago

I managed to fix this with the following helper: https://github.com/digitalfabrik/ehrenamtskarte/blob/b8363ca82f9db2c6e06ab2ea4d616a7293e21dd8/frontend/lib/map/map/screen_parent_resizer.dart

felix-ht commented 2 years ago

@maxammann would you mind creating a pr adding this to this package or creating a separate package with your helper?

maxammann commented 2 years ago

@felix-ht I just got response that it does not yet work in release mode :) I'll try to fix it again later this week. After that a PR would be possible.

teddichiiwa commented 2 years ago

@maxammann Sorry for late response, our team rewrite the PlatformView using Hybrid Composition and this bug will be gone (see: https://docs.flutter.dev/development/platform-integration/platform-views).

maxammann commented 2 years ago

Alright so this whacky and hacky workaround works now for us: https://github.com/digitalfabrik/ehrenamtskarte/blob/7675f039be5b914ad9c1331cc39e615ff802b5f8/frontend/lib/map/map/screen_parent_resizer.dart

It required quite some fine-tuning to cover edge cases. Make sure that when the initial render of the map happens that it is already visible. This means it should not be covered by a route which hides the map.

maxammann commented 2 years ago

@maxammann would you mind creating a pr adding this to this package or creating a separate package with your helper?

I'm not sure whether this should be included in the respository. I think the root cause of this should be fixed. For the time being we should maybe create a separate pub package which provides this helper. Or: Let's expect everyone to copy&paste this helper into their repository.