(Android) onRegionChangeComplete Fires Multiple Times and Resets User Location to (0,0)

[WarrenBuffering]

Only on Android, iOS is working fine, but onRegionChangeComplete typically fires 3 or 4 times after a user has finished panning or manipulating the map. Of these four fires, typically the second doesn't seem to pull the new map center for the reload and it returns (0,0) for the latitude/longitude, or just off the coast of Africa. I've read through almost every thread and nobody's solutions or workarounds seem to work.

Essentially all we are trying to do is get the map center (latitude and longitude) and latitude delta when a user is finished zooming/panning so we can set up our query.

Update:

After doing some more digging, it's about a 50/50 chance it jumps the map to (0,0) when refreshing.We're using the onRegionChangeComplete prop, and we see it's returning an incorrect lat/long/latDelta/lngDelta like so when it breaks....

latitude: 0
longitude: 0
latDelta: 102.73569069743314
lngDelta: 72.32139609754086

When it works properly, the coordinates it's bringing back are more like...

latitude: 35.78307468033585
longitude: 99.8066698028755
latDelta: .072463719198538
lngDelta: .051887668669237996

The person working on it with me is having the same issue with the same dev, with incorrect results being...

latitude: 0
longitude: 0
latDelta: 148.03909769956485
lngDelta: 126.56251475214958

when the coordinates they should be getting are something like...

latitude: 45.06256685043254
longitude: -103.290462680161
latDelta: .0724636120368487
lngDelta: .056723691523089315

I've heard react-native-maps can be quite buggy, but we can't possibly be the only ones to come across this issue. I've pored over every thread I can find but had no luck. I'm hoping someone out there has had a similar problem and a has found a fix?! Thanks!!!

Extra Thoughts:

Every time onRegionChangeComplete 'breaks', no matter where we've panned or zoomed to, latDelta & lngDelta are returning the same two numbers. The (102.7356..., 72.3213...) for me, and (148.039..., 126.5625...) for my partner. At first I thought it was because we're in different locations, but no matter how we manipulate the map, those two numbers don't change (only when onRegionChangeComplete 'breaks', otherwise they update correctly). I feel like there's some reasoning behind the two different sets of numbers that might give us an answer, but I can't find any correlation. The only thing that I could think is that it's creating those numbers based upon our differing screen dimensions. Any and all help is appreciated! Thanks!!

[victorbadila]

Does this issue happen on the emulators or on the actual devices? I have the same problem, but only on the ios emulator, the android emulator works fine. On ios when the user goes too far from the original location the mapview snaps to the original region, the region doesn't seem to get updated as the user drags around.

My workaround so far is that whenever onRegionChangeComplete executes I forcefully update the map's region by updating the state, since the map region is stored in the state in my example. I still see the event being called multiple times, which sometimes leads to glitch like behaviors where the map doesn't always center on the last position, but sometimes goes back a little bit.
A workaround for your solution might be to check the new coordinates and only update the map if they are different than 0, 0 or whatever you center is.

[ngandhy]

@victorbadila - I'm seeing this on iOS as well.
@telkandrew are you using Google Maps on iOS? It might be a Google Maps specific issue.

When I revert to 0.15.2, 0.15.3 I no longer see the problem. Seems like 0.16.0 broke it.

According to the CHANGELOG looks like it's one of these commits:

Android: #1481 Handle Android RN 0.47 breaking change
iOS: #1357 add MKTileOverlayRenderer
iOS: #1369 Add onMapReady callback
Android/iOS/JS: #1360 Add minZoom and maxZoom properties for android and ios
JS: #1479 Fix timing function used in AnimatedRegion.spring

Haven't had a chance to look into it deeply, but I'm leaning towards it being something in #1360 . @foyarash - anything you can think of? Thanks!

[foyarash]

Hello,

If such a problem occurs due to my min/max zoom implementation, it would be on iOS using MapKit, because Gmaps already implements a system to provide those zoom limitations. On iOS I had to implement this on the regionDidChangeAnimated in AIRMapManager.m, using a condition which will check the current zoom level and change the mapview coordinates if the zoom is too low/high. I guess this would need to be changed but I currently do not have time for this so that would be great if someone can send a PR for this.

That’s the best I can tell.

[ngandhy]

@foyarash - I was wrong, it wasn't 0.16.0 that broke it or #1360 (I didn't notice the build wasn't compiling correctly). Sorry about that.

However, I tracked it down to and fixed it by reverting the changes in MapView.js in (4376c97). Why that causes an issue, I have no clue at all. But if I switch back to the "const region = this.props.region || this.props.initialRegion;" line my 0,0 issue disappears.

[IjzerenHein]

Try PR #1710, it replaces the old (kinda hacky) Android region change detection algorithm by newer APIs that have been added to Google Maps.

[WarrenBuffering]

Evidently we should try #1710, but if anyone else is looking, we ended up getting it to work by using onRegionChange for Android, and onRegionChangeComplete for iOS. For our specific situation onRegionChange was buggy on iOS and onRegionChangeComplete was buggy on Android.