[TC-1167] Fixed ImageView resizing with Ti.UI.SIZE when image size ratio != 1

[farfromrefug]

jira ticket

[negupta]

Signed CLA is in place.

[mstepanov]

PR REJECTED. See comment in JIRA

[farfromrefug]

You are right. I added a test to do it only when width = Ti.UI.SIZE. In that case it should happen.

[vishalduggal]

contentWidthForWidth is only called when width is SIZE, 'auto' or undefined so the check is not required.

The reason the PR was rejected is that it only breaks the layout precedence for ImageViews on IOS and does nothing on the other platform or other views.

Secondly height.value is only valid if height is of type TiDimensionTypeDip. Does not work for TiDimensionTypePercent or TiDimensionTypeAutoFill.

Thirdly it will not take care of corner cases. When a width is specified to follow SIZE behavior it is limited by the constraining bounds. So say the autoWidth is 100 but the constraining bound is 40, only 40 is allocated to the imageView irrespective of return value. So the calculated autoWidth is incorrect for your case.

[farfromrefug]

@vishalduggal thank you for the exlanations. I didnt know contentWidthForWidth was only called for width = SIZE...

The only thing i dont get is when you say that it "breaks" layout precedence.

Now i can understand that it s not the way to go, and i might not know how to fix it, but something is clearly wrong when
you have something like:
imageview ({width:SIZE, height:40});
and you assign an image let s say 100x200.
You will end up with an imageview 100x40.
This is not what you would expect, you would expect the width to respect the ratio applied to the image.

If someone knows how to correctly fix it, i would love to see it and learn from it about ti size management.

[vishalduggal]

Unfortunately there is no way to fix this right now given that imageView on IOS extends the Ti.UI.View object and has to support the generic autoWidth and autoHeight implementations to calculate sizes not only for its content but also for any children added to it. When the imageView and other similar views are moved to a pure widget class this could possibly be done. For now this is just a platform limitation.

[farfromrefug]

Thanks for explaining. I ll keep that "hack" in my branch for now. Still hope to see this one fix though.