add setters, getters for map's minZoom and maxZoom

[ansis]

fixes #509

• @tobrun can you review the android commit?
• @1ec5 can you review the ios and osx commits?

[1ec5]

“the map can be”

[1ec5]

It’s worth noting here that the minimum zoom level can still be constrained regardless of this property to prevent showing multiple copies of the world at the same time. This is relevant whenever the view is much wider than it is tall.

[ansis]

how would you phrase this in the documentation? I'm having trouble coming up with a clear explanation

[1ec5]

How about:

The minimum zoom level at which the map can be shown.

Depending on the map view’s aspect ratio, the map view may be prevented from reaching the minimum zoom level, in order to keep the map from repeating within the current viewport.

If the value of this property is greater than that of the maximumZoomLevel property, the behavior is undefined.

[ansis]

perfect, thanks

[1ec5]

@friedbunny @boundsj, should these properties be made inspectable in Interface Builder? Or would it be confusing that setting the minimum zoom level to 0 won’t necessarily allow the user to zoom out to z0 if the view is wide enough?

[1ec5]

What happens if the map is already at z0 when the minimum zoom level is set to z2? It seems like the map would suddenly snap to z2 as soon as you touch it. We should look into handling this special case at the SDK level by first animating to the new minimum zoom level then officially setting that minimum. In any case, once the comments above are addressed, this PR will be good to go from my perspective.

[ansis]

What happens if the map is already at z0 when the minimum zoom level is set to z2? It seems like the map would suddenly snap to z2 as soon as you touch it. We should look into handling this special case at the SDK level by first animating to the new minimum zoom level then officially setting that minimum.

It will immediately snap to z2 when the new minimum zoom is set: 196feb9#diff-fd1625168ba48a6fb963e63343c0ac59R308

I think immediately jumping is fine since this isn't something you would usually call during use. With easing you'd have to worry about:

• only actually using the new minimum it after the animation runs
• what happens if the animation is cancelled
• what getMinZoom returns while the animation is running

[1ec5]

only actually using the new minimum it after the animation runs
what getMinZoom returns while the animation is running

When it comes to properties like this, on iOS and OS X, we’ve provided additional setters like -setContentInset:animated:, with the understanding that immediately calling -contentInset afterwards may not yield the final value.

what happens if the animation is cancelled

The minimum or maximum zoom level would be set inside the transitionFinishFn of the animation options passed into easeTo(), which is guaranteed to be called even if the animation is canceled.

It will immediately snap to z2 when the new minimum zoom is set

In that case, I’m fine with the behavior you’ve implemented. 👍

[ansis]

Thanks for the background on animated setters and transitions @1ec5. Good to know!

[friedbunny]

should these properties be made inspectable in Interface Builder

I vote... yes? (Halfheartedly.)

That said, most of the zoom-related requests we've seen are related to bumping the maximum value, but if we continue to default to the effective maximum then that'd be satisfactory there.

[1ec5]

if we continue to set that to the effective maximum by default then that'd be satisfactory there

That’s a good point. Let’s revisit the inspectable idea later if the use cases become clear.

[tobrun]

@ansis
The Android commit looks great!

About this:

this isn't something you would usually call during use.

This will match the 4.0.0 release, where we are probably going to expose this as a configuration in a builder pattern. The developer will not be able to change the behaviour after the map is created.

[1ec5]

should these properties be made inspectable in Interface Builder?

Tracked in #4388.