Stretchable image regions should default to UIImage cap insets

[1ec5]

#695 added two parameters, stretchX and stretchY, to StyleManager.addImage(_:id:). An iOS developer would find it more intuitive if the method could get the cap insets directly from the UIImage that is already passed in. The expected workflow would be to edit image slicing visually in the asset catalog, load the image by name, and add it to the style without ever specifying the cap insets in code. UIKit frameworks and most third-party frameworks honor these implicitly resizable UIImages the same way. Support for resizable images was originally added to the iOS map SDK in mapbox/mapbox-gl-native-ios#182 (comment), so this is technically a regression.

The stretchX and stretchY parameters should be made optional. When specified, they can override the cap insets in UIImage. The explicit parameters have the benefit of supporting multiple resizable regions, which UIImage doesn’t natively support. However, as it stands, there’s a potential for mismatch if the developer updates the asset catalog but forgets to update the hard-coded stretchX and stretchY arguments. As a workaround, the developer could programmatically convert the cap insets into stretchable regions, but the math is fairly error-prone, so it would be better for the SDK to take care of automatically.

/cc @neelmistry94

[1ec5]

The stretchX and stretchY parameters should be made optional.

This would be sensible even in the absence of cap inset support, because most style images are unlikely to have stretchable regions.

[macdrevx]

We do plan to support cap insets in a future release. We removed the default params recently to avoid ambiguity when we introduce a new method that works based on cap insets.

[evil159]

Fixed in #1269