This repository has been archived by the owner on Aug 8, 2023. It is now read-only.
Fix OnMapReady delivery when a new style is requested before the map is initialized #13203
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes a small regression introduced by the #13133 - when requesting a new style before the drawing surface is initialized, before, we were relying on
NativeMapView
being created after the view hierarchy is established, which means, that calls likemapView#setStyleUrl
done in the#onCreate
would add the style to theMapboxMapOptions
, becauseNativeMapView
was stillnull
. Now, we are initializing theNativeMapView
immediately, which means that callingmapView#setStyleUrl
would start loading the style instantly introducing a race condition - we would either create the drawing surface before the style is loaded, then the execution continued as expected, or the style would've loaded first, resulting in not deliveringOnMapReady
at all.The other part of this PR removes the usage of the deprecated
OnMapChange
listener across the project.