[WISH] Additional ImageView Gravity Options

[pixelpop]

It would be very useful if the gravity options for ImageViews included the following:

FIT_VERTICAL_LEFT
FIT_VERTICAL_CENTER
FIT_VERTICAL_RIGHT
FIT_HORIZONTAL_TOP
FIT_HORIZONTAL_CENTER
FIT_HORIZONTAL_BOTTOM

For instance, an ImageView is sized at 320 x 240. A bitmap loaded to that view is 220 x 520. In this case, I would use a FIT_VERTICAL option so that image filled the ImageView in height, with the LEFT, CENTER or RIGHT option determining its horizontal position within the ImageView.

By the same token, that same ImageView gets a bitmap with dimensions of 620 x 340. I would use one of the FIT_HORIZONTAL options so that image filled the ImageView in width, with the TOP, CENTER or BOTTOM option determining its vertical position within the ImageView.

 

[Erel]

Where did you see these constants?

 

[qsrtech]

+1

 

[Informatix]

You should never rely upon the gravity of your ImageViews and do instead your own rescaling/processing, because the gravity, in some circumstances, is not applied immediately (you have to wait that some events are processed). I have a few examples in my latest work that can prove easily this is a real issue.
Erel cannot do anything against this.

 

[pixelpop]

Good info, Informatix. I actually do my own scaling currently in code but thought it would be nice if these additional options were available. In some instances (such as your examples) they might have the same issues that using any of the current gravity options might have, but most of the ImageViews used in the examples I have looked at use the gravity option quite liberally.

 

[Informatix]

To be complete, here are the reasons why I try to never use Gravity with ImageViews:
- as I said above, it is not reliable at all in a few special cases where I do not want to wait for a redraw;
- there's no rescaling (FILL and its variants do only a resizing);
- it encourages bad habits. If you want to display only a part of an image, you should crop it and display the cropped part, otherwise you're just going to waste memory for something that noone will never see. The worst option is FILL. Who never used it to display a thumbnail with a very big image?

 

[pixelpop]

I agree with each of your points. Specifically about your issue with redraws. However, to your other points, my request was to address exactly what you described...there is currently no rescaling, only resizing. My request addresses this lack of any scaling options. And as for promoting bad practices, I agree that cropping an image does save memory when only a portion of that image is going to be displayed. But my request was to provide a method for displaying all of the image, especially when I have no control over the size of the original...the original might get scaled down but it also might get scaled up. And I also agree that FILL is usually pretty useless as it destroys the original aspect of the image. However, it is used quite often in the library samples that use ImageViews, by some very expert users (for example the FlickrViewer demo by Erel), so perhaps that is why its use is so prevalent. Not bad habits on our part, but being provided bad habits by the experts. I don't mean that as a flame, just something to be aware of when thousands of newbies like me are following those examples.

 

[Informatix]

However, it is used quite often in the library samples that use ImageViews, by some very expert users (for example the FlickrViewer demo by Erel), so perhaps that is why its use is so prevalent. Not bad habits on our part, but being provided bad habits by the experts. I don't mean that as a flame, just something to be aware of when thousands of newbies like me are following those examples.

I'm not sure that these experts, and especially Erel, will really do that in their own app. It's just a bit of laziness. I know that well.

Among the options listed in your first post, none is supposed to rescale an image (if I understand them well, because they have another name in the Android API).

 

[pixelpop]

I think we all know the scourge of laziness when it comes to relying on libraries. But the fact remains that the way we learn to do something the first time is generally the way we continue to do them, assuming that the method works.

And in my first post, the options listed are just option names that I came up with that I hoped would imply the fuction's result. Each of those options scales the image into the ImageView. If the image is taller than it is wide, the entire image height is scaled into the vertical size of the view. Conversly, if the source image is wider than it is tall, then the image is scaled to fit the view's width. The positional components describe how the sides of the image not scaled to the ImageView's sides (left/right or top/bottom) are positioned within the view.

Of course, some logic needs to be used when defining the view's size. An ImageView that is 320x20 or 20x320 would render all of this moot.

 

[Erel]

Gravity.Fill works reliably. I never encountered any issue with it. It is true that if the image ratio is different than the ImageView ratio then the image will be distorted.

The purpose of FlickrViewer is to show how to download multiple images. I'm not sure that there is a much better option than using Gravity.Fill in that case.