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.
Related
I have an emulator for 5.96-inch device. This device gets dimensions from folder values-sw320dp instead folder values-sw480dp
But, documentation says that 480dp: a large phone screen ~5" (480x800 mdpi).
Can some one describe why this happens
The smallest width of a device takes into account screen decorations and system UI. For example, if the device has some persistent UI elements on the screen that account for space along the axis of the smallest width, the system declares the smallest width to be smaller than the actual screen size, because those are screen pixels not available for your UI.
Docs
Facts of OP emulator device:
Size: 5.96 inch;
Resolution 480x800
Pixel Density mdpi
The pixel density is the number of pixels within a physical area of the screen and is referred to as dpi (dots per inch). This is different from the resolution, which is the total number of pixels on a screen.
The DisplayMetrics.density field specifies the scale factor you must use to convert dp units to pixels, according to the current pixel density. On a medium-density screen, DisplayMetrics.density equals 1.0; on a high-density screen it equals 1.5; on an extra-high-density screen, it equals 2.0; and on a low-density screen, it equals 0.75. This figure is the factor by which you should multiply the dp units in order to get the actual pixel count for the current screen.
https://developer.android.com/guide/practices/screens_support
https://developer.android.com/training/multiscreen/screendensities
Solution: to choose from values-sw480dp:
Edit the Pixels configuration to increase it to 720x1200 hdpi.
This happens because it's usually not about the physical screen size, but also about the screen pixel density.
px = dp * (dpi / 160)
https://developer.android.com/training/multiscreen/screendensities
How to handle design in multi screen for mobiles in Android without using dimention in values folder.
My application it's support all android mobiles, and I had a problem with the design, because I'm using dimen in values folder to handle it.
So please anyone can help me to handle this problem without using the dimention.
layout compatibility is very important part of any project
sorry but you have to use dimens for handle this problem.
and i think best way for design is use density.
you can use dimens-hdpi or dimens-mdpi or ...
and can use dimens-small or dimens-large or ...
and can use both of them together. like dimens-larg-mdpi
but this is so hard to design.
i using dimens smallest screen width
this use density and i think you can handle all of phones or tablets by 4 or 5 dimens.
like this picture.
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).
if you have a device don't support by one of these you can add
another smallest screen width for that.
you can read more details here , here , here and this help you know your phone pixels per inch.
example:
you have a phone 1080*1920 pixel and 5" size.
first formula help you calculate pixel per inch (dpi).
second formula help you calculate Pixel ratio.
and last formula help you calculate dp.
this phone have 392 dp in width and smallest width for that is 320.
if you like use dpi Pixel ratio can help you.
ldpi => Pixel ratio = 0.75
mdpi => Pixel ratio = 1.0
hdpi => Pixel ratio = 1.5
xhdpi => Pixel ratio = 2
xxhdpi => Pixel ratio = 3
xxxhdpi => Pixel ratio = 4
if you want to support all resolution (ldpi ,mdpi ,hdpi , xhdpi , xxhdpi , xxxhdpi ) then you can put your images those folders.
For text sizes its a good practice to use dimension folder. But if you do not want to use dimension folder then you can pick resolution of device programatically and change your text sizes
mipmap-hdpi, mipmap-mdpi,mipmap-xxhdpi, this folder are you that u need to use them for diffrent resolution
you can read : http://developer.android.com/guide/practices/screens_support.html
I'm trying to understand which layout uses which device.
For instance, I've different layouts:
layout
layout-sw600dp
layout-sw720dp
Nexus 7" (800x1280) uses layout-sw600dp
Samsung GTp3100 7" (600x1.024) uses layout-sw600dp
Samsung Tab 10.1 (1280x800) uses layout-sw720dp
Sony XPERIA S 4.3 (1280x720) uses layout
Can you guys explain "with your words" why isn't XPERIA S using sw600dp or sw720dp?
SW != smallest width? So smallest with from XPERIA S is 720. It should be using sw720 or sw600, right? Or am I wrong?
I've read tons of documentation, but can't understand why is this happening.
Thanks a lot.
The Smallest-Width qualifier refers primarily to screen size and not the physical pixels.
Using sw720dp for example means the device must have a minimum screen width of 720 dp (device-independent pixels) - this isn't about 720 physical pixels. From the documentation...
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.
The physical width of the Sony XPERIA S 4.3 is 2.5" but I don't know how much of that is the actual width of the screen.
Let us pretend for the sake of calculations that the screen covers the full width...in this case to calculate dpi for width we simply use 720 / 2.5 = 288dpi.
From the documentation for dp...
The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160).
Rearranging the formula above to calculate dp we do this...
dp = px / (dpi / 160)
...this gives us the width in dp (and a necessary Smallest-width qualifier) of...
720 / (288 / 160) = 400dp
In short the answer is, the Sony XPERIA S 4.3 may have a high-density screen (for its size) but it isn't a large screen.
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.
So I get the whole Android pixel independency thing.
I'm creating a SplashScreen that is using a 9patch that will stretch its edges to account for all screensizes.
I also use a differenlty sized 9patch image in ldpi mpdi hdpi xhdpi for each splash screen as well.
That way the logo (the non stretched area of the 9patch) will be the correct size.
I know mdpi is 1.0 and hdpi x1.5 in relative size and xhdpi is x2, but when I'm creating that first mdpi image how do I know how many pixels wide/high it should be?
Hope that makes sense.
Really there's no one answer. Firstly though, I wouldn't start at mdpi and scale up -- It's best to start at the highest quality that you can. Vector, if it fits the design, or a high resolution image (even larger than the largest screen size you currently plan to support). Then, from there, just downsize for the device that you plan to test. For example, a typical HDPI resolution would be 480 x 800, so fit it appropriately there. An XHDPI resolution might be something like 1280 x 720. It's best to just leave a good amount of margin on the edges in case it's used on a device with a different aspect ratio, or something. But yeah, basically, design as large as you can, and then just export based on some average screen resolutions for the density bucket you're working on.
(...) when I'm creating that first mdpi image how do I know how many pixels
wide/high it should be?
Since mdpi is the baseline for all other density buckets, 1dp on an mdpi device will translate to exactly 1px. In other words, use an mdpi device to figure out the relative size on the screen and from there on apply the given scaling ratios to produce resources for the ldpi, hdpi and xhdpi buckets. Obviously you do not actually have to scale up that mdpi resource - all you need determine is the size for that screen density and then you can use whatever source file to produce images for all buckets.
The link xBroak has given, is actually the best source of information regarding your question. A quote from there to support above statements:
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.
It may also come in handy to be aware of the simple d(i)p to px formula (also from that same link):
The conversion of dp units to screen pixels is simple: px = dp * (dpi
/ 160)
With this information, you can easily verify that 1dp on an mdpi device (with 160dpi screen) is equal to 1px. Just fill in 160dpi and you get px = dp * (160 / 160), which simplifies to px = dp * 1, and hence px = dp for 160dpi. QED. :)
These are your basic guidelines:
xlarge screens are at least 960dp x 720dp
large screens are at least 640dp x 480dp
normal screens are at least 470dp x 320dp
small screens are at least 426dp x 320dp
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).
More info: http://developer.android.com/guide/practices/screens_support.html