What are the criteria for a tablet device to fall under largescreens or xlargescreens?
I was looking at the Android dev guide and there is a clear definition for smallScreens and normalScreens, but the documentation is a bit vague regarding largescreens and xlargescreens.
smallScreens
HVGA resolution
normalScreens
HVGA with medium density
WQVGA with low density
WVGA with high density
largeScreens
A large screen is defined as a screen that is significantly larger than a "normal" handset screen.
xlargeScreens
An xlarge screen is defined as a screen that is significantly larger than a "large" screen.
Is there a resolution cut-off for largescreens? For example anything higher than or WSVGA (1024 × 600), and XGA (1024 × 768) is considered xlargeScreens?
smallScreens HVGA resolution
No.
normalScreens HVGA with medium density WQVGA with low density WVGA with high density
Sorta.
Is there a resolution cut-off for largescreens?
Resolution has nothing much to do with screen size. Screen size is self-explanatory: it is the size of the screen. I can have a 480x320 screen that is 1mm, 1cm, 1m, 1km, or 1 parsec in size.
Given resolution and density, you can compute a size, which is why your description of the normal screen size is close to correct.
The Range of Screens Supported section of the Supporting Multiple Screen Sizes documentation shows the diagonal screen sizes buckets that Android supports and what physical sizes those tend to map to:
Related
I have a few questions:
What is the screen size?
What is the screen density?
What is a difference between screen size and screen density?
How I can support different densities and different screen sizes in Android?
I have already read the official documentation, but I was unable to understand the difference between screen size and screen density.
screen size is about how many pixels you can show on screen.
Density is based on your device real size, if it's small and has a higher resolution, than the density is high cause you show more pixels in less physical space.
1.screen size concerns an absolute number of pixels. (check out wikipedia Image Resolution)
2.Density (aka Pixels per inch - PPI) concerns a relative number of pixels per inch. (check out the wikipedia Pixel Density)
To put it simple:
Screen size is the physical size of the screen (whether in inch or cm)
Screen density is the ratio of how many pixels / area of screen size (that's why the unit is dpi, or dots per inch)
Simply put, screen size refers to the size of the screen.This varies from device to device.screen density refers to the amount of pixels in a screen.Both are not independent though as screen size affects screen density.
There are different terms and can't be used interchangeably
density = how many pixels appear within a constant area of the display, dots per inch = dpi or ppi(pixels per inch )
size = amount of physical space available for displaying an interface, screen's diagonal, inch
resolution = number of pixels available in the display, scale-independent pixel = sp
Starting android emulators with the same resolution of 480x800 at different DPIs (120, 160, 240), I would think that the screen with the highest DPI would have the smallest interface elements (images, buttons, etc) and the one with the lowest DPI would have the largest. But exactly the opposite is true. I've included a screen shot to demonstrate what I mean.
My emulator settings are:
HDPI:
Skin resolution: 480x800
Abstracted LCD Density: 240
MDPI:
Skin resolution: 480x800
Abstracted LCD Density: 160
LDPI:
Skin resolution: 480x800
Abstracted LCD Density: 120
I started each of the emulators with the following settings:
Scale display to real size
Screen size: 5 inches
Monitor dpi: 105
Scale: 0.56
Am I doing something wrong, or is this the expected result? If it is, why does it behave in this way? If I do the equivalent in Photoshop (view for print option), I get the exact opposite and correct results.
The problem turns out to be simple math. If we take the formula for calculating DPI as
dpi = sqrt(height^2 + width^2)/(screen size in inches)
it becomes apparent that you cannot choose all three components when running an emulator -- only two, and android will calculate the missing component.
From my original question above, I was specifying a constant resolution (480x800) and a constant screen size (5 inches). But 480x800 always produces a DPI of roughly 186 dpi. So forcing the DPI to be different in each of these cases confused the Android emulator, and I think it discarded my specified original resolution and calculated its own.
This is expected. Android increases the default font size in anticipation of this higher DPI. The goal is so that at a certain physical screen size (say 3") the font has the same physical size, no matter its resolution. Higher density displays have smaller pixels, so when setting the DPI setting higher Android needs use a bigger font to appear the same size relative the screen.
In my application I have 3 different layout folders:
layout
layout-large
layout-xlarge
I did this according to the available Android device screens, described here. So I thought that the screen size in inches is the only thing that is used to decide which layout folder to use. But recent tests with various 7 inch emulator showed that sometimes the layout and sometimes the layout-large folder is used. So can anybody tell me which other factors are used?
7 inch Android tablets are HDPI and large.
xlarge didn't exist at the time they were made, and although most of them have pixel densities around 160 (MDPI) they present themselves as HDPI devices because it looks better.
So the 7inch tablets don't quite fit into the resources system properly, because there wasn't really a way to fit them in prior to 3.0 which introduced new screen-size qualifiers.
I think size in inches is the only thing that matters. There was a question on here a while back where someone has having some odd results with trying to make emulators pick from the correct layout folders for 7 inch devices. I have a Galaxy tab though and it will always take from layout-large, or layout-hdpi.
Edit: perhaps I was incorrect it seems that type of screen and pixel count may matter too -
* small: Screens based on the space available on a low-density QVGA screen. Considering a portrait HVGA display, this has the same available width but less height—it is 3:4 vs. HVGA's 2:3 aspect ratio. The minimum layout size for this screen configuration is approximately 320x426 dp units. Examples are QVGA low density and VGA high density.
* normal: Screens based on the traditional medium-density HVGA screen. A screen is considered to be normal if it is at least this size (independent of density) and not larger. The minimum layout size for this screen configuration is approximately 320x470 dp units. Examples of such screens a WQVGA low density, HVGA medium density, WVGA high density.
* large: Screens based on the space available on a medium-density VGA screen. Such a screen has significantly more available space in both width and height than an HVGA display. The minimum layout size for this screen configuration is approximately 480x640 dp units. Examples are VGA and WVGA medium density screens.
* xlarge: Screens that are considerably larger than the traditional medium-density HVGA screen. The minimum layout size for this screen configuration is approximately 720x960 dp units. In most cases, devices with extra large screens would be too large to carry in a pocket and would most likely be tablet-style devices. Added in API Level 9.
If you happen to have folders with more than one qualifier like layout-large-mdpi etc you have to pay attention to the precedence order also. this page should help out.
According to Google's android screen support guide res/layout is used for normal screens and is the default folder in which the OS looks.
On Android, what is the visual effect of displaying a very high DPI image on a screen with low DPI?
What about a very low DPI image on a high DPI screen?
A high dpi image will just be bigger on the lower DPI screen. Conversely, a low dpi image will be smaller on a high dpi screen.
That's simplifying it a bit. It also depends on whether scaling is enabled. If you only have an hdpi image in your resources, and you're viewing it on an ldpi screen, depending on your settings, Android may scale it downward, in which case you'll have a slightly reduced quality image, that should display around the same size. The other way around (ldpi on hdpi with scaling), you'll have a noticeably pixelated image on your hdpi screen, scaled to the same size.
The dpi really isn't important; what's important is the actual physical size of the image. If you have more pixels squeezed into an inch of display (higher pixel density; hdpi), you'll need a larger image to take up an inch of space on the screen than you would for a low density screen. The benefit of a higher density screen is that you can fit more detail into a specific area. That's why on different devices -- for example, the Droid vs the Droid Eris -- reading text at small sizes is noticeably more difficult on the Eris due to its low density.
If you display a low DPI image on a high DPI screen it will appear smaller than it would on a low DPI screen.
High DPI image on low DPI display: the image will look bigger unless there is some kind of scaling.
Low DPI image on high DPI display: the image will look smaller or less detailed if displayed "as is". Often it will look blurry/pixelized because of scaling.
It's easy to launch emulators to see what happens for yourself.
A HDPI image on a LDPI screen would appear larger than the same image on a MDPI or HDPI screen.
A LDPI image on a HDPI screen would appear smaller than the same image on a MDPI or LDPI screen.
(Oof. Beat by 2 min, 1 min, and 15 sec.)
I'm trying to write an application that will work well on all screen sizes, for that I have my graphic designer produce images that are in the requested dpis for each directory (Low density (120), ldpi, Medium density (160), mdpi, High density (240), hdpi, Extra high density (320), xhdpi) however, they want to know at which resolution and aspect ratio each image should be, after looking around the android documenation, namely:
1)http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources
2)http://developer.android.com/guide/practices/screens_support.html
I came up with the following information:
It is not exact that android supports 3 screen sizes, android is an OS that can run virtually on any screen size but there are some screen sizes that are more common than others, these are demonstrated in the table below (taken from http://developer.android.com/guide/practices/screens_support.html)
Table 1. Screen sizes and densities of emulator skins included in the Android SDK.
Low density (120), ldpi Medium density (160), mdpi High density (240), hdpi Extra high density (320), xhdpi
Small screen QVGA (240x320)
Normal screen WQVGA400 (240x400)
WQVGA432 (240x432) HVGA (320x480) WVGA800 (480x800)
WVGA854 (480x854)
Large screen WVGA800* (480x800)
WVGA854* (480x854)
Extra Large screen
It’s worth noting here that even though it seems that there is no correlation between these screen sizes, there is a 3:4:6 scaling ratio between the three densities, so a 9x9 bitmap in ldpi is 12x12 in mdpi and 18x18 in hdpi (see http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources).
We can see some more information on what the screen sizes mean here:
Screen size
• small: Screens based on the space available on a low-density QVGA screen. Considering a portrait HVGA display, this has the same available width but less height—it is 3:4 vs. HVGA's 2:3 aspect ratio. Examples are QVGA low density and VGA high density.
• normal: Screens based on the traditional medium-density HVGA screen. A screen is considered to be normal if it is at least this size (independent of density) and not larger. Examples of such screens a WQVGA low density, HVGA medium density, WVGA high density.
• large: Screens based on the space available on a medium-density VGA screen. Such a screen has significantly more available space in both width and height than an HVGA display. Examples are VGA and WVGA medium density screens.
• xlarge: Screens that are considerably larger than the traditional medium-density HVGA screen. In most cases, devices with extra large screens would be too large to carry in a pocket and would most likely be tablet-style devices. Added in API Level 9.
We can also support specific aspect ratios, as defined here:
Screen aspect
• long: Long screens, such as WQVGA, WVGA, FWVGA
• notlong: Not long screens, such as QVGA, HVGA, and VGA
--
All of this however, is not enough to answer the simple question of what the resolution should be on those images - can they all be cut from the same high res image or should they be re-done for each dpi since the aspect ratio is different?
please help, this is holding up my project
Thanks!
It depends on your images, really. Very tiny graphics you'll probably want to draw separately, since you're going to lose fine details when interpolating to smaller sizes, whereas with larger ones, you'll probably be fine just rescaling, starting with a high resolution image.
For background images, that's always kind of a tricky one. Since you can't count on a specific resolution, you can either estimate and go with one slightly smaller than the average, and turn it into a 9-patch, where the edges will stretch to cover the leftover space, or you can go with one slightly larger than the average (something like 900 x 500) and just make sure the edge area doesn't contain any pertinent information. Basically, think of it like a bleed for print, it's just extra area that may be cut off if the screen's not big enough. It's easier to just use some sort of gradient drawable or other resolution independent type of image for the background, if possible, due to the large number of different resolutions to support.
When I'm creating graphics I considering this way:
ldpi 240x320
mdpi 320x480
hdpi 480x800
xhdpi 800x1280
Putting images separate drawable folders, drawable-hdpi, drawable-mdpi....
Background is a bit tricky, you may do so with bg or even set it from your program not layout xml file. That will provide you more flexibility, to chose weather you going to resize or crop it.