I'm designing an android activity which I want it can be compatible with all screens resolutions. Right now, I did it knowing that the screen will have 1024x600pixels, and in the layout_weidth and height, I used absolute pixels... (I started with dp's but it doesn't work in my mobile, but it works in the emulator... very confusing, so I decided to try with pixels and they worked) but if I get another resolution, then it crash...
So I though in creating a xml with percents of the actual resolution of the screen, so it can be compatible with all the screens...
But thoughting, what can I do with the textSize, for example? How can I make it compatible?
I need some advice... thanks
Using Relative layout is a better option
Use dp - density independent pixels for UI components and sp for Text sizes
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.
Related
I've been using dp for dimensions and sp for text size for 3 years now, ever since I've started developing apps for Android.
But recently, I've been joined with a couple people that don't believe in dp and sp saying "it doesn't show the same on all devices".
The method they've used is:
When setting the text size, you don't use 24 sp nor 24 dp, you set it as 24% of the screen width or height in pixels. in this way, the text is always the same size in pixels on all devices (including tablets).
How correct/valid is this method? What is the professional way to design? What is the opinion of a professional Android designer to this method?
Don't know how good % can replace dp, but don't use it as a text size.
sp is great because users can resize it by changing their preferred text size in the device settings. Don't take away this possiblity just because it makes your design easier for you.
Accessibility > Design
See this guide for reference: Support different pixel densities
When defining text sizes, however, you should instead use scalable pixels (sp) as your units (but never use sp for layout sizes). The sp unit is the same size as dp, by default, but it resizes based on the user's preferred text size.
Best unit for text is sp and for dimensions best unit is dp.
That is given perfect result of in which you want.
In most of developer use this unit for text and dimensions.
I try for your % but that is not work in my app.
dp stands for density independent pixels. Its goal is, to define a more or less physical dimension. E.g. 48dp are about the size if a finger tip, and that's why tappable icons (e.g. on ActionBar) should have that size.
So for UIs you should always use dp (and sp for texts). It also has the advantage, that you can show more data on a larger screen (e.g. more items in a list are visible etc.).
If you're using % of the screen size, you are doing the exact opposite. On a small device 24% it will be small (physically speaking) on a large tablet it will be large.
Using % might make sense if you're developing a game for example and you want the same image shown on every device, large or small.
DP/SP Does not claim to be the same on all screen sizes but about the same size across screen densities. The reason it is only about the same size is that density is broken up into categories (e.g. mdpi, hdpi, xhdpi...).
You don't want the text to be relative to the screen size because then the text will be really small for devices that have a small screen and really large for devices that have a large screen. Instead you want the font size to be comfortable to read and about the same size on large or small screen. The large screens will just have the advantage of more text on the screen at a time.
In addition as other users have mentioned sp (and apparently now dp) can be scaled based upon user preferences which is really helpful for people with poor eyesight.
I would like to create a adaptive UI for both mobile and tablet devices. I would like to know for example for mobile devices if I give android:textsize="2dp then how much I should give for tablet devices. I know I should give them in values-w820dp and appropriate folder but how to calculate the difference of this dp. I couldn't find any resource for this. Help me out.
(1) For most text, it's best to size it in sp units so it scales automatically relative to the user's text-size preference. Folks with lesser vision can pick larger text and then be able to read your app without eyestrain.
(2) If you need some text to appear in a fixed size, e.g. a big headline, then use dp units so it scales automatically relative to the screen's pixel density. (Pixel density is independent of the overall screen size. It's a high vs. low density thing, not a phone vs. tablet thing.)
But don't use size 2dp! That'd be unreadably tiny -- the height of 2 physical pixels of a 160 dpi screen.
(3) If you need some text that uses approximately a fixed proportion of the screen size, then it makes sense to either define screen-size-dependent parameters, e.g. in values-w820dp, or to size it in code.
(4) If you need some text in a fixed number of pixels tall even when the pixels are really tiny, e.g. to draw into a raster image, then use px units.
See Supporting Multiple Screens - best practices.
There are no strict rules here. You can have android:textsize="2dp on your tablet as well if you wish so. You can have a look at the following android developer page which tells how to support tablets and contains chapter called: 5. Adjust Font Sizes and Touch Targets
Hi Iam developing android Titlebar , so I need to clarify which is use to android text either sp or dip
or
Which is standard and what is the difference between sp and dip? Thanks!
SP is always used for textSize
DP is used for pretty much everything else
See "Supporting Different Densities" for more info.
From the docs:
One common pitfall you must avoid when designing your layouts is using absolute pixels to define distances or sizes. Defining layout dimensions with pixels is a problem because different screens have different pixel densities, so the same number of pixels may correspond to different physical sizes on different devices. Therefore, when specifying dimensions, always use either dp or sp units. A dp is a density-independent pixel that corresponds to the physical size of a pixel at 160 dpi. An sp is the same base unit, but is scaled by the user's preferred text size (it’s a scale-independent pixel), so you should use this measurement unit when defining text size (but never for layout sizes).
sp is used for text size and dp for everything else. These are mainly to achieve the best support for multiple screens with different sizes and density
I've developed an interface and everything has used dp settings so I thought it should have been good for most screen sizes. However when testing it gets messed up on most screen sizes, bigger and smaller. I get the icons not showing right since I only have one set for Nexus 4 size and density as they are only placeholders until I build the proper icons at the proper scales.
What is going wrong? Is dp the wrong way to go about designing it for scale? I've considered designing specific layouts for various screen sizes but I'm not sure where to begin in regards to what to target.
Here is what is should look like. (Nexus 4)
Smaller Screen (Nexus One)
Bigger Screen. (Nexus 5) - See how the text collides with the vertical divider.
dp - an abstract unit that is based on the physical density of the 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.
It doesn't mean that image can scale automatically. It works in the specific density devices well.
Generate ur icons with http://romannurik.github.io/AndroidAssetStudio/icons-generic.html and place the icons and check.
For text don't use dp : instead use sp
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.