I'm currently looking into getting my android app to work on Kindle Fire. I've got artwork for both MDPI and HDPI screens, but I noticed that when I load the app up on the Kindle, it displays the MDPI artwork and stretches some of my artwork that I'm filling parent with a little more than I want.
I was wondering if there's any way on Android to under certain circumstances (like if I'm on a Kindle), force it to load from the HDPI artwork, instead of defaulting to MDPI.
I do realize that I could just save my HDPI artwork in the MDPI folder with a slightly different name and do a check for every resource, but that's a lot of overhead, not to mention an increase in the size of my app, which I'd also like to avoid.
Thanks
Update: Still looking at this one. I guess what I'm really getting at, is there a way for an android device to chose HDPI artwork instead of MDPI, even though the MDPI artwork exists?
The Kindle Fire is 1024x600 with 160 dpi, right?
You can try new resourses with that resolution. And place them in the MDPI folder.
Add layout-large at /res directory and copy your layout file there.
That way, with the Kindle Fire, you use the layout at layout-large pointing to bigger resources in the MDPI folder.
And make sure you always use nine-patch drawables for resources.
Hope this helps you.
Ended up using a hack solution in the meantime, but I came across this:
I don't want Android to resize my bitmap Automatically
Pretty much just needed to move my hdpi images into the nodpi folder (in order to avoid the scaling issues) and changed the names slightly (I added a _hd to the name). After that I made an image loader that takes in the name of the image I want and returns _hd images if device is hdpi or if it's kindle fire:
id = ctx.getResources().getIdentifier(string + "_hd", "drawable", context.getPackageName());
Note: The docs do discourage the use of getIdentifier(), as it is less efficient than just using the resource address, but I took a look at the load times and loading 1000 images with getIdentifier takes .25 seconds, which is fine with me especially since I'm not loading anywhere close to that many images.
You can try new resources with that resolution and place them in the MDPI folder. Add layout-large at /res directory and copy your layout file there. That way, with the Kindle Fire, you use the layout at layout-large pointing to bigger resources in the MDPI folder.
Related
hi I'm new in android developing and it's my first app.
I have made these folders in address : app\src\main\res for supporting multiple phone and tablet screens and put proper dimens.xml files in them.
values-ldpi
values-mdpi
values-hdpi
values-xhdpi
values-xxhdpi
values-xxxhdpi
values-sw600dp
values-sw768dp
values-sw800dp
first of all, are they complete or am I missing some screen sizes?
second, I've tested the app on several devices and it's working fine and has proper user interface in all phones but on the Galaxy Grand Prime which has a 5 inch 540 x 960 pixels display that means 220 dpi. this phone using hdpi dimens but UI is a bit messy.
The following pictures may make my point better :
Proper UI , as it is shown in other devices
VS
UI in galaxy grand prime 220 dpi display
as UI is completely OK in other devices, I thought I should make a specific dimens.xml file for that kind of dpi, so I made values-sw220dp. but after that other phones used this dimens instead of hdpi dimens and problem got worse because UI was fine in the galaxy phone and was not proper in other hdpi displays. and now I don't know what should I do.
can anyone help me in this issue?
at last sorry because of flaws in my english , as you can guess I'm not a native.
are they complete or i'm missing some screen sizes?
If you read the guides which I mentioned at the end of my answer you will find that there are very many possibilities of defining resources folders. I think nobody will want to implement all of them.
Usually you look at your app and then decide on maybe three or four screen sizes you want to support. I think "sw220dp" is important, if only to show a message that your app needs more space :-).
So there could well be three to five layout folders (sw220dp, sw320dp, maybe sw480dp, sw600dp, maybe sw820dp). If you need orientation-dependent layouts, then the number will be twice that much. (Why ? That's explained very well in the guides linked below)
You already know that there are different types of resources. Some of them do not depend on the screen resolution (e.g. layout files), some do (drawable resources).
So first of all you decide which screen sizes you want to support. Let's say they are "phone", "tablet" and "220dp". You create three layout files by the same name "my_activity.xml" and put them in three folders
for the really small window: res/layout-sw220dp
for the mobile phone: res/layout-sw320dp
for the tablet: res/layout-sw600dp
By the way, "sw" stands for smallest width which is the minimum length of the screen, no matter what the orientation is currently.
Now let's assume you have created three different layout files and all of them contain an ImageView like this:
<ImageView
android:layout_width="24dp"
android:layout_height="24dp"
android:src="#drawable/my_picture" />
This is where the screen resolution comes into play: 24dp is a size value in "density-independent pixels". It will be resolved depending on the screen resolution of the device. So you need different versions of my_picture.png, and for this you need different folders for drawables. They are named after the different categories for screen resolution so the runtime knows which png file to pick:
res/drawable/ldpi (although I read somewhere you can skip that because the pictures will be scaled down from hdpi nicely)
res/drawable (here go the resources for res/drawable-mdpi as well as every drawable resource for which resolution does not matter, e.g. drawables defined via xml files)
res/drawable-hdpi
res/drawable-xhdpi
res/drawable-xxhdpi
res/drawable-xxxhdpi
Helpful links:
Providing Resources
Supporting Multiple Screens
If you put drawables in /drawables directory they will be scaled and if you want specific drawables for different densities you need to put them in specific directory (/drawables-hdpi, /drawables-mdpi etc.)
But if I have drawables only in /drawable-tvdpi will they scale down/up automaticly for ither densities?
Yes they'll scale, so if you put a 133 x 133px drawable in the tvdpi folder, it'll be 100px on mdpi, 150px for hdpi, and so on.
There's more information on the Android Developers - Screen Support page, but in general you can get away with just putting drawables in the tvdpi folder.
I believe they will, Android always picks the best available image inside your directories, i.e. if you have an mdpi phone, and two resource types, hdpi and xhdpi, it will try to pick the one immediately above the requested density (hdpi) instead of the bigger one, because it correctly assumes it' going to be enough. Take a look here.
However why not try it for yourself using Bluestacks? It's an Android simulator that runs pretty well. It's still in beta, but has served me well.
Last two questions stayed unanswered, I hope "third one's the charm" works :)
I want application that is HDPI use those drawables in folder "drawable-xhdpi" and LDPI devices those in "drawable-mdpi". So I don't have to duplicate same images. Is this possible?
Yes, Android scales drawables, selecting the drawable that will produce the best result. But not all scaling combinations work that well. Downscaling to MDPI can produce noticeably poor results. XHDPI to HDPI generally produces pretty good results. But given that the overwhelming majority of devices these days are HDPI, it's probably worthwhile to have HDPI resources. HDPI to XHDPI scaling is not terrible. Some 1280x720 devices uses XHDPI resource. These generally look ok. Google TV uses XHDPI as well. On a huge screen, scaling errors are visible.
LDPI devices are -- for all practical purposes -- non-existent now.
True that generating scaled resources is an enormous PITA. But, in my opinion, you really need to do MDPI and HDPI. And once you've got that unpleasant workflow down, it doesn't require a lot of extra work to generate XHDPI. For what it's worth, if your artwork is in vector format, the vast majority of resources don't need tweaking for specific resolutions. There doesn't seem to be any compelling need to pixel-align edges of square objects, for example. Usually it's only interior features in complex icons and artwork that benefit from some amount of pixel-pushing.
It's pretty clear that XHDPI is going to be come more and more common. Trust me, you don't want to go back and re-do all your artwork in XHDPI after the fact. My advice: if you intend to still be shipping your app a year from now, suck it up, and do the nasty as you go, while it's still relatively easy.
In my experience, if you place an image in just some of the drawable folders, but not all, the OS will choose the "best" image for the device that you are using, even if it is not exactly the perfect fit. For example, if you put an image called arrow.png ONLY in the drawable-hdpi folder, all devices will use that image for the arrow drawable, and scale it down or up appropriately, stretching or shrinking the image.
That being said, you should be able to accomplish what you want by simply putting your image in the right folders and allowing the devices to choose the correct one. For example, if you were trying to accomplish your task with only one image, arrow.png:
drawable-xhdpi/ -> arrow.png
drawable-hdpi/ -> empty
drawable-mdpi/ -> arrow.png
drawable-ldpi/ -> empty
drawable/ -> empty
If you use the app on an ldpi device, the device will use the mdpi image, as you wanted, because it is closest to the correct resolution. On the hdpi phone, it will use the xhdpi image, because it is again the closest to the correct resolution.
Yes. Android automatically downscales/upscales resources that it cannot find. If you were to only put resources in the XHDPI folder it would just work, Android would take care of resizing them to work in all the other densities.
We should add this code in MainActivity class and copy image to dhpi folder with ic_launcher, ic_launcher2, ic_launcher3 and ic_1 is image name, we can change size: width and height
int array_image[]={R.drawable.ic_launcher,
R.drawable.ic_launcher2,
R.drawable.ic_launcher3,
R.drawable.ic_1
}
I have images in drawable-hdpi(big images) and in drawable-mdpi(small images)
I opened my app on Kindle fire (its get layout from layout-large) and it use images from
drawable-mdpi , is any way to let app to get images from drawable-hdpi when screen size is large?
thanks
I think what you are looking for is to use configuration qualifiers.
It seems you are really misunderstanding what these folders do.
Your android will select folder based on it's screen size or pixel-density.
Your Kindle Fire has a medium Pixel density and a large screen. So it selects its resources from the res folders with those given qualifiers.
res/layout-large/my_layout.xml
and images from
res/drawable-mdpi/my_icon.png
You cannot tell your kindle to get images from the hdpi folder because it does not have a high pixel density.
So you could either create a folder called
res/drawable-large-mdpi/
specifically for your Kindle Fire device.
Or just make sure the right images are in the right folders.
EDIT: Size qualifiers are deprecated from 3.2.
While deprecated, they still work. Although results may not be what expected (for example: 5" and 7" are seen as same size -large-which still have difference). So they added dp qualifiers to use beyond 3.2. Which are much better. developer.android.com/guide/practices/… It kinda works like media-queries
Updating this with the new qualifiers for Android.
Use of size qualifiers such as drawable-large are deprecated in 3.2 or above.
To use the latest method of supporting multiple layouts and densities, you can use the following:
res/drawable-sw600dp-mdpi
In this example, sw600dprepresents the smallest width available to the activity in density-independent pixels,600dpin this case. This is deemed as being a little more fitting for device-specific layouts and drawables as the width is provided instead of a generalized size grouping such aslarge`.
There are also new options for available width and height, full information available here: Supporting Multiple Screens
All qualifiers are processed in the order they appear in Table2.
Read How Android Finds the Best-matching Resource.
We use 9png mainly to reduce the size of the apk. But, I am facing a peculiar problem. I am not sure in which folder I have to place the 9pngs in. I had put them in HDPI folder. Since Android is 'clever' it looks like if I use the app in an MDPI phone, it 'scales' the 9png which creates crazy effects. I didn't face any major problem until I tried it in Galaxy note. Looks like the 9png was taken from HDPI and scaled (Note has 800x1280) and it created weird effects.
So which is the right place to put the 9pngs?
How to tell Android system not to 'scale' 9pngs based on the folder it is put in?
According to Romain Guy's answer on Google groups:
The behavior of 9-patch is undefined when shrunk. In practice you will
see overlaps of the various sections of the 9patch. Don't do it :)
From what I noticed in my projects, a 9PNG is scaled down just like any regular PNG, so I am usually requesting to our designer the entire set of images for ldpi, mdpi, hdpi and xhdpi, and I transform them all in 9patches.
That, unless there is a very simple 9patch, like a plain button background, that makes no difference when stretched or shrunk, so I usually place it in the regular drawable folder.
I had a similar problem with a nine patch image: if I placed it in the res/drawable folder, it didn't work on an ldpi screen (it distorted the image and lost the transparency).
The solution for me was to put it in the res/drawable-nodpi folder. The documentation states:
This can be used for bitmap resources that you do not want to be
scaled to match the device density.
Just put the 9png in your HDPI folder.
if the effect looks weird in your Galaxy Note.
Ask the designer to give you a new 9png file for the XHDPI. and then put the new file in folder XHDPI.