Confusion in "smallest width dp" in Android - android

I am learning how to use "smallest width dp" to support different screens using this in android.
i get that below number are the smallest of side of device in dp.
Typical numbers for screen width dp are:
320: a phone screen (240x320 ldpi, 320x480 mdpi, 480x800 hdpi, etc).
480: a tweener tablet like the Streak (480x800 mdpi).
600: a 7” tablet (600x1024).
720: a 10” tablet (720x1280, 800x1280, etc).
According to this post nexus 6 has 730 x 410 dp.
The Nexus 6 boasts an impressive 5.96” Quad HD screen display at a
resolution of 2560 x 1440 (493 ppi). This translates to ~ 730 x 410 dp
(density independent pixels).
but as explained in this
dp = (px/dpi)*160
= (1440/493)*160
= ~467
then how come this translates to 730 x 410 dp?
further more when i run the demo in nexus 6, device is using padding dimension defined under res/values-sw320dp/dimens.xml
this confuses me. how does one actually calculates dp and create view accordingly using "smallest width dp" ?
apart from res/values-sw320dp i have res/value and res/values-sw600dp that has dimens.xml under it.
UPDATE figured out my confusion. check comment under question.

You can get the correct values with the following code:
DisplayMetrics displayMetrics = this.getResources().getDisplayMetrics();
float dpHeight = displayMetrics.heightPixels / displayMetrics.density;
float dpWidth = displayMetrics.widthPixels / displayMetrics.density;
Log.d("dpHeight-----",String.valueOf(dpHeight));
Log.d("dpWidth------",String.valueOf(dpWidth));
For example for the Xperia Z 1080x1920px the values are 360x592dp, the settings is values-sw360dp

Related

How to create custom dimen files for same DPI bucket devices?

I am writing an Android game and I am testing it in two devices at the same time:
Huawei P10 Lite: 5.2", 1920x1080, 424dpi, xhdpi.
Huawei P40 Pro:
6.58", 2640x1200, 441dpi, xhdpi.
These two devices are utterly different, as they differ in screen size and resolution, but NOT in dpi and dpi bucket; both are xhdpi.
That means regardless the dimen files I create (dimen-mdpi, dimen-hdpi...), any graphic element looks the same in both phones, which completely breaks the layout and proportions in the small phone.
I'm taking this as a reference for bucket classification:
Well dpi is all about resolution, and not screen size. If you want to create resources for screen sizes, and not screen resolutions, you should use smalest width qualifiers.
According to the docs:
One DIP is one pixel on an
approximately 160 dpi screen (for example a 240x320, 1.5"x2" screen),
providing the baseline of the system's display. Thus on a 160dpi screen
this density value will be 1; on a 120 dpi screen it would be .75; etc.
So if I understand correctly, you would convert from pixel to dp by: pixelSize / dip / 160. In this case the formula for your device width in dp is as follows: deviceWidthInPixels / (deviceDip / 160).
P10 width in dp: 1080 / (424 / 160) = 407.54
P40 width in dp: 1200 / (441 / 160) = 435.37
Looks like other people also came to this conclusion

I can not deal with non-standard resolution

I have design for my project. It for Nexus 6 with resolution 1440px x 2560px and 493 ppi. My design - 1440px x 2560px.
I know that:
ldpi 120 dpi
mdpi 160 dpi
tvdpi 213 dpi
hdpi 240 dpi
xhdpi 320 dpi
xxhdpi 480 dpi
xxxhdpi 640 dpi
I have - 493 ppi. what's this? I have a button size 100x50 pixels on the design.
how many dpi need button to look as well as in the design?
Hope this helps: Getting Your Apps Ready for Nexus 6 and Nexus 9
Nexus 6
Screen
The Nexus 6 boasts an impressive 5.96” Quad HD screen display at a
resolution of 2560 x 1440 (493 ppi). This translates to ~ 730 x 410 dp
(density independent pixels).
Check your assets
It has a quantized density of 560 dpi, which falls in between the
xxhdpi and xxxhdpi primary density buckets. For the Nexus 6, the
platform will scale down xxxhdpi assets, but if those aren’t
available, then it will scale up xxhdpi assets.
EDIT:
Consider this line
2560 x 1440 (493 ppi). This translates to ~ 730 x 410 dp (density
independent pixels)
It implies the scaling factor is 2560/730 = 1440/410 ~ 3.5
For a screen of width 410 and height 730 in dp, if you want to specify a button of half the screen width in dp, the width should be 410/2 = 205 dp which translates to 717px = 205*3.5 (width in dp * scaling factor)
A button of size 100px x 50px would translate to 28 x14 dp (100/3.5 * 50/3.5) on a 410 x 730 dp screen size.
If you are genuinely concerned about proper display resolution (which it sounds like you are) then you should never rely on the generic folders. The folders are there for generalized purposes - not for customized or high value display.
You should use displayMetrics to measure the screen size and select the appropriate asset, or even do customized image scaling. There are a lot of resources around this set of properties, but essentially it allows you to address the issue you are facing: set appropriate margins, padding, resolution, layout, etc. for a highly customized display.
Here are the docs:
http://developer.android.com/reference/android/util/DisplayMetrics.html
And then some "simple" implementations of getting the metrics:
How to get screen display metrics in application class
getting the screen density programmatically in android?

Conversion from px to dp for Google nexus 7

I am new to tablet application development. I am having Google Nexus7 with screen resolution (600 * 960 dip) So I want to know is it fall in to mdip category?
According to that 1px = 1dp (baseline). But If I follow this its not looks good on tablet. I am creating separate layout folder for nexus7 -sw600dp and mention sizes according to mdip but it not working. My images also not looking good. What I want to know what is actual conversion rate for google nexus 7. Need help.
Formula: pixels = dips * (density / 160)
The Nexus 7 is 800x1280 with a 213 px density, which means it's resolution code is tvdpi (which means you can have a folder called drawable-tvdpi).
You can measure available screen size, minus window decorations, with:
this.getResources().getConfiguration().screenWidthDp;
this.getResources().getConfiguration().screenHeightDp;
On my N7, it returns 600 dp w, 888 dp h. Following the above formula, 888 dp height is 1280px - window decoration.
The Nexus7 is a unique device, with a somewhat strange dpi structure.
For nexus 7
layout-large-hdpi
Here is a very good explanation (from Dianne Hackborn - an Android engineer at Google): Dianne Hackborn explains the unique resolution of the Nexus7
Note: The app takes images from these folders only if you have not given higher precedence qualifiers. For example if you have given a layout folder like layout-sw360dp the app will take only the images from this folder even if you have given separate layouts like the one I said above. Because in android there is an order of precedence in which you have to give layouts.
Screen Density
Commonly referred to as dpi (dots per inch). Android groups all actual screen densities into four generalized densities: low (120), medium (160), high (240), and extra high (320). A device such as Galaxy Nexus has "extra high" screen density (more specifically, the dpi value is set at 320). The Nexus 7 uses "tvdpi" - i.e. 213 dpi.
Density Independent Pixel
Commonly referred to as dp. This is the virtual pixel unit used when displaying content. The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen. To calculate dp use the following formula:
px = dp * (dpi / 160)
or equivalently:
dp = (px / dpi) * 160
The reason Nexus 7 can show more content than the Galaxy Nexus despite having similar resolutions is this: the dpi of Nexus 7 is lower than Galaxy Nexus.
Galaxy Nexus (320 dpi, 720 pixels wide)
(720 / 320) * 160 = 360 dp
Nexus 7 (213 dpi, 800 pixels wide)
(800 / 213) * 160 = 600 dp
This means that when apps are rendering on the Galaxy Nexus, the width of the screen is actually 360 dp (rendered using 720 pixels). Whereas on the Nexus 7, the width of the screen is 600 dp (rendered using 800 pixels).
Try below code, give pixel value to below method it will give you result in dp.
public int convertSizeToDeviceDependent(int value) {
DisplayMetrics dm = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(dm);
return ((dm.densityDpi * value) / 160);
}

Confusion with "smallest width 600 dp" selector

In my application I am supporting phone/tablet form factors and to have individual layouts I use selector "layout" (for phones), "layout-sw600dp" (for tablets).
Following are the details:
http://android-developers.blogspot.in/2011/07/new-tools-for-managing-screen-sizes.html
Typical numbers for screen width dp are:
320: a phone screen (240x320 ldpi, 320x480 mdpi, 480x800 hdpi, etc).
480: a tweener tablet like the Streak (480x800 mdpi).
600: a 7” tablet (600x1024).
720: a 10” tablet (720x1280, 800x1280, etc).
I am having a Nexus 4 mobile, following are its attirbutes
Size: 4.7 inches
Resolution: 768 x 1280 pixels
DPI: 318
dp: 386
Here is the dp calculation
dp = (px * 160)/dpi
dp = (768 * 160)/318
When I use 768 px in dp calculation formula the dp value comes as 386, but when I pass 1280 px the dp value comes as 644.
With the following understanding I thought for Nexus 4 landscape it would read the layout from sw600dp, but that's not the case.
As the resolution is width X Height, it will be reversed when the device is rotated.
I thought this is the improvisation made with sw selectors compare to pre-3.2 large, xlarge sectors.
As it says in the Android documentation here in bold (scroll down a bit to the "smallestWidth" section of Table 2):
The smallestWidth is a fixed screen size characteristic of the device;
the device's smallestWidth does not change when the screen's
orientation changes.
The sw figure is always the shorter of the two screen dimensions, regardless of the device orientation. That's where the "smallest" in the name "smallestWidth" comes from. The advantage over Gingerbread-style "large" &c. selectors is only that you get more granularity of control, and it's more predictable what screen sizes you'll actually get, because it doesn't rely on how the manufacturer classes their screen size.
If you want to select a layout based on the width or height of the screen in its current orientation, use a directory called layout-w600dp or layout-h600dp.

Declaring Tablet Layouts for Android 3.2 - mild confusion

According to this guide's chapter px = dp * (dpi / 160) and to that layout specifications change from buckets(physical size in inches) to "dp" units so that:
320dp: a typical phone screen (240x320 ldpi, 320x480 mdpi, 480x800
hdpi, etc).
480dp: a tweener tablet like the Streak (480x800 mdpi).
600dp: a 7” tablet (600x1024 mdpi).
720dp: a 10” tablet (720x1280 mdpi, 800x1280 mdpi, etc).
Since "dp" values depend on "px" and "dpi" values so that: dp = px / (dpi / 160) - isn't it possible that a phone device with high resolution will take a layout from w600dp folder?
For instance: Samsung galaxy s3 dp = 1280 / (303 / 160) = 670; Samsung galaxy s2 dp = 800 / (217 / 160) = 592. So, galaxy s3 is going to take "tablet-oriented" template, right. Is it okay, especially if a tablet version contains more elements and overall interface ergonomics gonna suffer from the tablet layout in case of s3 ? Why don't just stick to display buckets ?
You're probably going to recommend using "sw" key but I just want make sure that those "dp" units actually relate to sizes so that tablet-oriented template won't be shown on phone devices.
So, would you mind sharing your practical knowledge on applying the new approach ?
Thanks
A dp or dip is a (screen) Density Independant Pixel. The confusing part about that is that is mentions pixel. It is actually a unit similar to a centimeter or inch.
Each device defines a dpi bucket for it's screen, for example mdpi which is 160dpi. That means that you find 160 pixel across one inch on the screen. It's not 100% accurate since physical screens are usually not exactly 160 dpi (or whatever value that is defined for the bucket). But it's a value that comes close.
That means that 160dp on a perfect 160dpi screen are actually 160 pixel. On a device with a perfect xhdpi (=320dpi) screen those 160dp would be 320 pixel. (px = 160dp * (320dpi / 160))
To work with dp don't think in pixel. Think in inch, milimeter or what unit you prefer. The recommended 48dp rythm for UI elements for example explains that
On average, 48dp translate to a physical size of about 9mm (with some variability)
To approximate that: 50dp = one finger wide.
That hopefully explains why a typical 320dp phone screen is always smaller than a 720dp tablet screen although the smaller screen can have more pixel than the larger. The dpi / pixel thing is already factored into dp.
How to do different layout for different screensizes? (i.e. phone vs table)
Use the screen size buckets (small, ..., xlarge) for the layout. They represent physical small to large screens. You don't need sw600dp etc unless you need to adjust very special cases.
The different dpi buckets should only concern you for images. E.g. high resolution images for high resolution screens of any size in the drawable-hdpi folder.
The S3 does not have a density of 160.

Categories

Resources