I have the following layout for my ImageView:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout
xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:orientation="horizontal"
android:descendantFocusability="blocksDescendants">
<ImageView
android:id="@+id/imageview_icon"
android:layout_width="48dp"
android:layout_height="48dp"
android:scaleType="fitCenter" />
(...)
</LinearLayout>
Those 48dp equal to 36px, 48px and 72px in ldpi, mdpi and hdpi respectively. All the images that will be used in this ImageView are basically icons and I’ve found on the web what I want for my app (free license). But unfortunately, it doesn’t come with images bigger than 48px and using different images is out of the question. So I need a new solution…
For now I have 36px and 48px images in the ldpi and mdpi folders, respectively. But I’m having trouble with hdpi. What I want for devices running on hdpi is for them to use the mdpi image (the bigger one available) and use it as it is, without scaling. Basically, the ImageView for hdpi is 72px, so I want the 48px image to be inside the 72px, in the center, without scaling. For that, I simply tried to change scaleType in the ImageView above to just center, but the image gets scaled anyway.
My ultimate question in here is, what’s the proper way to fix the problem described above? How can I have ldpi and mdpi images being used in their respective densities, but have devices running hdpi pick up the biggest image available (which is the mdpi ones) and prevent any scaling, just fitting the image in the center of the ImageView?
EDIT:
I answered this question myself, but it might to be the answer others coming here are looking for. But I do provide some insight on what’s really happening and the underlying problem. Please take a look and provide a workaround/fix if you can. I dare you 🙂
This question turns out to be a non-question and I apologize to anyone that founds it, hoping the accepted answer will be what they are looking for when it won’t be.
To make it clear,
scaleType=centerInsideis working as expected. That is, if you have an image smaller than theImageViewitself, than that image won’t be scaled to the bounds of theImageView, it will remain in the center and unscaled.But for the above to work as expected, the drawable must be placed in the
nodpifolder. I understand that this is not always acceptable. So, when that drawable must be placed into one of the density folders instead of thenodpifolder, thescaleTypeattribute will only work in specific situations.When it will work:
Xdpidensity andthere is a drawable in the
Xdpidensity folder (hereXmeans,l,m,hor evenxh).for instance, with
hdpidensity, but there isn’t a drawable in thehdpifolder and the system picks the alternative drawable from thenodpifolder (it’s not always known which folder it will pickfrom).
When it will not work:
hdpidensity, but there isn’t a drawable in the
hdpifolder and thesystem picks the alternative drawable from any other of the density
folders (not the
nodpifolder), the drawable will be scaled to theImageViewbounds and thescaleTypeattribute will not doanything.
In conclusion, there’s no “right” answer to my question, it really depends on what you are trying to achieve. The answer my question though, I just need to do 2 things: a) Set the
ImageViewscaleTypetocenterInsideand b) Duplicate all drawables from themdpifolder into thehdpifolder (as explained above, thescaleType=centerInsidewill make it work).Of course, duplicating drawables is not optimal, but I can’t find any other solution and so far, no one else could either… So, in the time being, I’ll mark this one as accepted.
What would be the optimal answer/solution then?
In my opinion, if the device/emulator is running in
hdpiand there isn’t a matching drawable in thehdpifolder it should be pick the drawable from themdpifolder without scaling it, allowing thescaleTypeattribute to do it’s thing. Or maybe force the system to go to thenodpifolder if it doesn’t find a matching drawable in the respective density folder, that could a solution too.So, if anyone can ever provide a workaround/fix to this issue, that would be the real correct answer. If it ever comes to that, I’ll change the accepted status.