The addLocationListener method didn't check if the LocationListener was
already in the list.
From MapView, if we call setMyLocationEnabled(true), it adds a
LocationListener and onResume adds the same LocationListener again, but
is just removed by onPause.
So LocationListener is added twice but removed just once, so
LocationServices singleton keeps an instance of the the LocationListener
that is never released.
There is no such thing as a cancelled response, only cancelled requests. A request that is cancelled does not have its callback called with a Response.
Turn the Shows User Location inspectable into a no-op when running in the designables agent. Otherwise, we complain that the agent lacks Location Services permissions.
* Use "named constructors": empty, world, hull
* Make the two-argument constructor lenient (i.e., it is a hull operation)
* Add various accessors
* Enforce a single empty representation
[android] #3754 - Working version using the underlying VisibleCoorindateBounds
[android] #3754 - refactor Camera api inside maps package, correctly use factory pattern, LatLngBounds hooks into camera API
[android] #3754 - cleanup old API
Renamed -showAnnotations:withEdgeInsets:animated: to -showAnnotations:edgePadding:animated: for consistency with other methods. Reworded documentation comments to avoid hard-coding too many specifics that are prone to getting outdated.
This just removes some whitespace that made the implementation of
`pushTurnstileEvent` in `MGLMapboxEvents` look a little strange.
The indentation was right below an early return conditional
(with no braces) so it felt like the right thing to do (for
readability) to clean it up. Choosing and enforcing a consistent style
for conditionals with one line might be a good idea, too, but this
small change does not go there.
The tilt gesture on both iOS and OS X now respects the content insets. On iOS, in user tracking mode, it additionally respects the user dot’s position if it’s aligned to the top or bottom of the view.
Entering user tracking mode at launch now zooms in and shows the user dot or user puck. The user dot’s heading indicator now points in the correct direction during the animation to the initial location. Course changes are reflected immediately even in the absence of location changes.
Fixes#1145.
Broke out -locationManager:didUpdateLocations:animated: into multiple self-contained methods, simplifying the logic considerably.
Eliminated a jump after device rotation in non-centered tracking mode.
When a targetCoordinate is specified in course tracking mode, the map automatically resizes the viewport to show both the user puck and the target, one at the top and the other at the bottom. The user puck now rotates its arrow in the course direction, no longer assuming that the viewport is facing the same way as the course.
Account for the user dot’s alignment when flying to the initial user location. Previously, during incremental location updates, we relied on a hack in which the edge insets resulted in a 0×0 viewport, forcing the center upward or downward. But flyTo() relies on the viewport’s size to control the trajectory. So instead, all location updates now use a correctly-sized viewport centered on the offset user dot.
Pushed the user dot farther away from the view edges.
Programmatic rotation and compass rotation are now centered on the user dot even if it’s aligned at the top or bottom. Previously, pressing the compass would trigger a rotation centered on the center of the view.
Setting the user tracking mode without animation now works. Previously, it kept the user dot from ever updating.
Just as a zoom gesture no longer kicks the user out of user tracking mode, programmatically zooming shouldn’t either.
Setting a camera with an invalid center coordinate no longer attempts to change the center coordinate but still changes any other valid properties.
Made animation to new user dot vertical alignment optional.
