Received an email from my first Motorola Droid user. The new 480x854 resolution introduced in Android 2.0 (as opposed to 320x480) is wreaking havoc with my user interfaces. Everything is smaller and ill-positioned.
I was under the impression that if we follow the XML layout guides we were resolution-safe, as no absolute coordinates are used. Does anyone have experience in making the UI resolution-safe? Will we need a main.xml for each resolution times each orientation?
Which dimension units did you use?
AFAIK using dp and sp should keep you safe.
From documentation:
dp
Density-independent Pixels - an abstract unit that is based on the
physical density of the screen. These
units are relative to a 160 dpi
screen, so one dp is one pixel on a
160 dpi screen. The ratio of
dp-to-pixel will change with the
screen density, but not necessarily in
direct proportion. Note: The compiler
accepts both "dip" and "dp", though
"dp" is more consistent with "sp".
sp
Scale-independent Pixels - this is like the dp unit, but it is also
scaled by the user's font size
preference. It is recommend you use
this unit when specifying font sizes,
so they will be adjusted for both the
screen density and user's preference.
The eclair emulator works wonders for these issues, also make sure to read:
http://developer.android.com/guide/practices/screens_support.html
Your application responds to different resolutions based on many factors, even the min-sdk.
Also, from the page, are some best practices:
Prefer wrap_content, fill_parent and the dip unit to px in XML layout files
Avoid AbsoluteLayout
Do not use hard coded pixel values in your code
Use density and/or resolution specific resources
Aside from the resolution difference, the other thing to consider is that the Droid's WVGA screen has a different aspect ratio from previous devices like the G1. In many older apps that I've downloaded, this manifests as a gap at the bottom of the screen, or elements that are vertically misaligned in portrait mode. You may want to try running your app in the emulator with a WVGA skin to check for any hidden assumptions that your layout makes about the aspect ratio.
Related
If I wanted to create something that is exactly one inch apart on every Android screen, I would use pixels correct? Inches and dp seem to scale to the individual size of the screen meaning on one device it could be one inch and on another it could be 1 1/4th.
Also, is there an easier way to do this besides finding how many pixels are in an inch and then adding the views with the correct margin pragmatically?
You would use density independent pixels. Also known as dip or just dp.
Dp ensure that things are nearly the same size on every screen. ("Nearly" because this is android, with a huge fragmentation, and custom roms, ...etc)
So one inch will be a varying amount of pixels on each screen. If you use pixels, things will be smaller on high resolution displays. So use dp and everything will be the correct size on the actual screens.
While using dp might be off by a pixel or two (might!), this is probably as good as it gets. Also, you should try not to create pixel perfect design with android—You will have a hard time with different screen sizes (and not just resolutions)
Generally speaking you should try and follow the material design guidelines by google for android, and rather use multiples of 8dp for sizes, instead of trying to find out how much an inch is.
Density-independent pixels (dp) is the unit of measure which appears to be the same actual length on any device.
Try this: create a view whose width is 100dp and run it on a hdpi device. Measure the width of the view using a ruler or something. Then run the app on a mdpi device and measure the width. You will find that the two widths are about the same.
This means that, just as its name suggests, the actual length of a dp is independent of the screen density.
If you used pixels, however, the actual length will vary from screen density to screen density. If the screen is denser, 100px will appear shorter. If the screen is less dense, 100px will appear longer.
Get it?
tl;dr: Just use dp!
I've developed an interface and everything has used dp settings so I thought it should have been good for most screen sizes. However when testing it gets messed up on most screen sizes, bigger and smaller. I get the icons not showing right since I only have one set for Nexus 4 size and density as they are only placeholders until I build the proper icons at the proper scales.
What is going wrong? Is dp the wrong way to go about designing it for scale? I've considered designing specific layouts for various screen sizes but I'm not sure where to begin in regards to what to target.
Here is what is should look like. (Nexus 4)
Smaller Screen (Nexus One)
Bigger Screen. (Nexus 5) - See how the text collides with the vertical divider.
dp - an abstract unit that is based on the physical density of the screen. which is the baseline density assumed by the system for a "medium" density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use.
It doesn't mean that image can scale automatically. It works in the specific density devices well.
Generate ur icons with http://romannurik.github.io/AndroidAssetStudio/icons-generic.html and place the icons and check.
For text don't use dp : instead use sp
I'm designing an android activity which I want it can be compatible with all screens resolutions. Right now, I did it knowing that the screen will have 1024x600pixels, and in the layout_weidth and height, I used absolute pixels... (I started with dp's but it doesn't work in my mobile, but it works in the emulator... very confusing, so I decided to try with pixels and they worked) but if I get another resolution, then it crash...
So I though in creating a xml with percents of the actual resolution of the screen, so it can be compatible with all the screens...
But thoughting, what can I do with the textSize, for example? How can I make it compatible?
I need some advice... thanks
Using Relative layout is a better option
Use dp - density independent pixels for UI components and sp for Text sizes
sp
Scale-independent Pixels - this is like the dp unit, but it is also scaled by the user's font size preference. It is recommend you use this unit when specifying font sizes, so they will be adjusted for both the screen density and user's preference.
72 pts is always equal to 1 inch, yet 160 dip is not always equal to 1 inch.
As such, why do people recommend us to use dips instead of pts?
Isn't it better to base our dimensions on pts which is predictable, instead of dips which is unpredictable?
The reason why you should use dip (Density Indepentdent Pixel) is that this way your application will support multiple screen sizes. This means that if you set a value to 100dip, it would be translated into 75px on a low density screen (ldpi), 100px on a medium density screen (mdpi), 150px on a high density screen (hdpi) and 200px on a extra high density screen (xhdpi) but the layout will look the same on each screen (but scaled to the screen density).
The only reason to use pt is if you actually need the exact size and don't care about the screen density (I can't see when that would be the case).
You should read through this article to better understand why dp/dip is the way to go:
Supporting Multiple Screens
Also this similar question has a good explenation of the difference between the different units:
Difference of px, dp, dip and sp in android
Always use dip (Device Independent Pixel), this will respect the width and height of the device you're running on. So by using dip, the layout will be the same for all devices.
if you want your app to work in just a single device or a single resolution, you can use pts. if you would like your app to work on multiple resolutions (which i think you would) you are better going with dip or dp. Try your app on different resolutions using the emulator and you would see what the issues are. The app will look different in different resolutions.
I've got a final app design made i Photoshop where everything is measured in PX.
Now I realize that Android apps are using DP for font-sizes and other things.
Is there any way I can convert PX to DP ?
On a more practical note, you have a few choices in increasing work and fidelty:
Have your resources scaled for 160 dots per inch, put them in your res/drawable directory, and let the OS scale them to look right on the device.
Make two copies of your resources: one at 160 dots per inch in your res/drawable and one at 240 dots per inch in your res/drawable-hdpi directory. Let the OS scale for the exact device starting from a pretty close number.
Decide that you don't want any scaling and have raw pixels, so put your assets in the res/drawable-nodpi directory. This means that at 320x480 (pixel) graphic might be 2 inches by 3 inches on one phone but only 1 1/3 inches by 2 inches on another screen.
Specify the exact scaling strategy for your work, using the draw9patch tool. This can be very useful for keeping the corners of boxes from getting the "jaggies" from scaling and for making full screen graphics cope with different aspect ratios.
Make separate graphics for every device you care about and fall back on scalable graphics for the rest. You will need to outrun zealots waving style guides trying to convince you not to do it this way.
Oh, and as a gotcha, specify sp for your fonts, instead of dp or pt. A 10 point font would be a 22 sp font [ =10 * (160/72) or = number of points times 2.222]. sp units scale with user preferences for small, medium, or large fonts.
From this list of the dimension units supported by Android, here's a description of DP:
Density-independent Pixels - an abstract unit that is based on the physical density of the screen. These units are relative to a 160 dpi screen, so one dp is one pixel on a 160 dpi screen. The ratio of dp-to-pixel will change with the screen density, but not necessarily in direct proportion. Note: The compiler accepts both "dip" and "dp", though "dp" is more consistent with "sp".
This means that the "conversion" between pixels and DP will not be consistent -- on some devices, the ratio might be 1DP = 160px, but it could theoretically be anything. This is all well and good when you're setting the width of a button to, say, 100dp (since it will get rendered dynamically), but it presents a problem when you have images which must have a fixed size.
Read this page on "Supporting Multiple Screens" -- Android has something called resource directory qualifiers, which let you create size- and density-specific versions of your image resources. For example, for low-density screens, you could create a smaller version of your image and place it in the drawable-ldpi directory (or drawable-hdpi for high-density screens).
tl;dr You can't practically "convert from PX to DP" (since the ratio is not fixed), but you can create multiple versions of your images and tell Android which to use with resource directory qualifiers.
A pixel is PX and the DP or DIP are device independent pixels. I don't think that you need to convert these. But you can use scalable 9patch images using the draw9patch tool from the android tools.
I have same issue but now got the Solution.
Why you not use the online convertor to see which dp or px you have to for different resolution of android device ??
See this link: this link which helps me a lot and also helps you.
Enjoy coding.
This is a online DP/PX Converter tools: http://labs.rampinteractive.co.uk/android_dp_px_calculator/