what is the best way for controlling the size of widget on Android?
Look on following table:
• On 3.6-4.0 inch screen (smartphone) with 480x800px the dpi is about 240dpi
• On 4.3 inch screen (smartphone) with 540x960px the dpi is about 270dpi
• On 7 inch screen (tablet) with 480x800px the dpi is about 130dpi
• On 7 inch screen (tablet) with 600x1024px the dpi is about 170dpi
• On 8.9 inch screen (tablet) with 1280x800/768px the dpi is about 170dpi
• On 10.1 inch screen (tablet) with 1280x800px the dpi is about 150dpi
So in general smartphones comes with much higher dpi.
Now if I create a control with 100px width it will be good on low dpi displays but bad on high, where the control will be too small. If I create the same control with 100dp it will be opposite – on high resolution displays it will scale to e.g. 150 px, but on low dpi screens (tablets) it will be still 100px or smaller is the density falls below 160dpi.
So how I should make a control that on 4inch display occupy 1inch on 7inch display occupy 1.5inch and on the 10.1inch display occupy 1inches? In other words – bigger screen size, the bigger is the control, but without considering the resolution.
But is that in fact a good approach?
Regards,
SteN
Please include this in your android manifest file..
<supports-screens
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="true"
android:resizeable="true"
android:anyDensity="true"
/>
and also check the following link from android developer site, this may help you in finding a rite solution for your question..
http://developer.android.com/guide/practices/screens_support.html
Related
I'm developing an application and i need it to fit all screen sizes and densities.
I created 4 folders for the resources (drawable-ldpi,drawable-mdpi,drawable-hdpi,drawable-xhdpi) and 4 xml layouts. But i'm confused a little about many points:
1- If I have a Samsung Galaxy tab 10.1 (mdpi screen) with a 1280 x 800 screen size and a Samsung Gio (mdpi screen) with a 320 x 480 screen size, how can I make the "layout-mdpi" folder including the xml layout file for medium dpi, fits these 2 devices having the same dpi but 2 different screen sizes (Galaxy tab is much bigger than Samsung Gio)?
2- I'm creating my png's using Photoshop, these png's must be saved with 320dpi,160dpi,240dpi..? Or all the resources must be saved in 72 dpi but different sizes?
3- I tested a star icon on my Samsung Galaxy tab 10.1 (mdpi screen) having 32x32px size, dunno why my icon is blurred!
You have to make all 4 different sizes images and put that images according to folder.And also set the property in menifest like this.
<supports-screens
android:anyDensity="true"
android:largeScreens="true"
android:normalScreens="true"
android:smallScreens="true" />
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:
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.
On Xoom tablet i am getting density value 1.0. Is there anything i have missed in manifest file to support 3.0 or greater os devices? Below is the code snippet to print the density value on tablet.
System.out.println("******==="+getResources().getDisplayMetrics().density
+"===widht=="+getResources().getDisplayMetrics().widthPixels
+"===height=="+getResources().getDisplayMetrics().heightPixels
+"====="+getResources().getDisplayMetrics().toString());
I have also added all supported screens set to true but still getting density value wrong.
<supports-screens android:resizeable="true" android:smallScreens="true"
android:normalScreens="true" android:largeScreens="true"
android:xlargeScreens="true" android:anyDensity="true" />
Anybody have any ideas on this?
Have a look to the Android doc density:
The logical density of the display. This is a scaling factor for the Density Independent Pixel unit, where 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.
This value does not exactly follow the real screen size (as given by xdpi and ydpi, but rather is used to scale the size of the overall UI in steps based on gross changes in the display dpi. For example, a 240x320 screen will have a density of 1 even if its width is 1.8", 1.3", etc. However, if the screen resolution is increased to 320x480 but the screen size remained 1.5"x2" then the density would be increased (probably to 1.5).
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.