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.
Related
Why was dp created when there were already other density independent units such as cm?
Is the dp to px conversion by the Android system based on buckets rather than the exact device's pixel density? Wouldn't this result in a discrepancy in how much physical space elements measure on different device screens?
Because cm are too big. You'd have to work with floats, which means you'd need to round all the time. They wanted something smaller. Also, the first devices were 160 dpi, do 1dp=1px which was convenient at the time (now very few devices ship at mdpi so this advantage is gone). It also just so happens to match the dpi of the iphone, rounded to the nearest 10 (iphone was 163 dpi), so measurements were what mobile devs were used to making easy conversions.
Its based on the physical dimensions. There can be some discrepancy, but in practice there isn't. If you have an image that is a little too small, the amount of distortion you get from stretching the tiny amount is negligible. The other major use of dp is in padding, and there the slight rounding errors are unnoticable as long as you're consistent on a single device.
As said by #Gabe Sechan, cm are too big (even mm). Contrary to cm, conversion to pixels is based on density category rather than exact density of the screen, which avoids rounding issues you'd have with cm to px (factor of 1.5x, 2x, 3x, etc rounds much better than an "arbitrary" ppi).
Yes. Conversion of dp to px is based on the density bucket the screen belongs to (mdpi, hdpi, xhdpi, etc) rather than the exact physical ppi. Bitmap graphics of an app are categorized by buckets, so for measurement consistency the dp is converted based on the density bucket rather than the real ppi. The drawback is that unlike a unit such as cm, the measurements are not guaranteed to be the same physical size on every screen (example of such inconsistency).
References:
Why aren't standard physical length units like mm used for touch UI layout?
Why “dp-to-pixel” ratio changes with the screen density, but not necessarily in direct proportion
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!
There are a lot of questions on this on here, but none that answer my specific question. When I use px, eclipse tells me to avoid it. So I did. But when I use dp, the grid/borders I am making around my cells in GridView seems too fat. I want it much thinner. When using 1 px as opposed to 1dp, I get the desired result. I understand warning on avoiding it, but should I really avoid it in this case?
Yes you should. "dp" will give pretty the same look on all devices, but pixels are not.
http://developer.android.com/guide/practices/screens_support.html
Long story short:
The density-independent pixel is equivalent to one physical pixel on a 160 dpi 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. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.
px doesnt work on all devices i think it stopped working in android 2.2
I recommend sticking with dp.
I am confused about android's multiple screen support. http://developer.android.com/guide/practices/screens_support.html I read this article, but still something is not clear for me.
I used dp instead of px in my layout
I put high, medium, low version's of an image to drawable directories.
I made this changes according to this article. But in some densities, there is still problem although some of them work very well.
The question is what is the exact width and height in dp units for variety of android screen types. if it is changeable, what is the difference between px?
px is changeable, dp is changeable too??? what is the difference??
if changeable, should I change the view's width and height by code on Create function or create seperate layouts for each screen dentisies? Please give a way to understand this...
Thanks in advance..
px are not changeable. dps or dips are.
To calculate how many px your object specified in dps will be use the formula below:
The density-independent pixel is equivalent to one physical pixel on a 160 dpi 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. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.
px is a fixed measure. This means that if 100px on a small screen take up 1/2 of the screen, it will take up much less on a large screen. dp = density (independent) pixels, is based on the densitity of the device. So if you specify a width to 50dp on a small screen, it will expand on a large screen. Note that dp is not an insurance of layout compability on all devices, since devices have different aspect ratios. To build a perfect layout, that looks exactly the same on all devices, you must use more techniques. Linearlayout allows you to assign weights. Look into that. http://developerlife.com/tutorials/?p=312
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.