Develop Reference

Text sizes, different density devices and material design

I'm trying my best to follow the material design guidelines when it comes to fonts as I can, but I'm struggling to fix an issue I'm having without using dimens dependant on density. My issue is;
I'm using styles for my fonts so an example of this;
<style name="Text.MyApp.Heading3" parent="TextAppearance.MaterialComponents.Headline3">
<item name="android:fontFamily">?attr/RegularFont</item>
<item name="fontFamily">?attr/RegularFont</item>
<item name="android:textSize">?attr/TextSizeHeadingThree</item>
</style>
And applying this as the style of the text, my font size comes from the material guidelines so for Heading 4 I have
<dimen name="text_size_heading_three">48sp</dimen>
My problem is, I've got a view where there's two numbers using Heading3 in a row on the screen, This may look like +£100.00 | -£200.00, these are constrained to a separator view in the middle.
Where my issue lies is on a Pixel 4 XL (xx-hdpi) this looks fine, but bringing this down onto a Nexus S (hdpi) the text squashes together, overlaps the separator in the centre and comes off the end of the screen slightly.
It was to my understanding of the use of SP is that it would scale this text size which doesn't appear to be happening, a worry also arises that SP takes from the users text size preferences so increasing the text size of the device will likely also break this.
Just short of changing the font size for hdpi to a smaller text size for this text view, is there a way I can make this style scale with the screen?

sp actually scales in regard to the screen pixel density and the selected font size of the system.
The issue you are facing is related to the screen's actual width instead.
To achieve what you want, you can try either of the following two:
Have different sp values for your dimen for each screen width. You can do this by creating additional resource files that would contain your dimen values and will be screen width dependant. You can read more about this here:
https://developer.android.com/training/multiscreen/screensizes#TaskUseSWQuali
Use an autosizing TextView. You can find more information here:
https://developer.android.com/guide/topics/ui/look-and-feel/autosizing-textview

sp units are literally about the user's choice of text size:
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 the user's preference.
Basically users can choose the general size of text on their device, and that multiplies dp values by a specific factor (Normal is * 1.0, I think Huge is * 2.0) and that's what the sp value is. When you specify sizes in sp, you're allowing the system to scale that text up so it's readable for everyone.
So you need to be mindful of that when designing - it's always worth having an emulator with a small screen (limited space) and the text size set to the largest setting, just to make sure everything still fits in those extreme cases.
You have four options I think:
reduce your font's sp size in the layout, so it always fits
make different layouts for different configs, and tweak that (more work for you)
use autosizing TextViews like #kandrit mentions - set the space you want to fill, and it will scale the text size to fit it (this sounds like what you were expecting, and you can tweak things like having a fixed set of possible sizes)
don't use sp, use dp instead (won't scale according to the user's preference - but above a certain size, it doesn't need to because it will be readable)
You'll get a warning about the last one, but in my opinion it's completely fine and the right thing to do in some cases. Think about an app with a clock in the middle of the screen - it's a fixed size, designed and laid out a certain way, and it's large enough to be easily read. It's meant to look a specific way, take up a specific area of the screen, and there's no need for it to change size - so it makes sense to define it in dp like any other visual element. Maybe that works for what you're doing!

Problem is not with your text size, it is with your layout design
I also had the similar problem I solved it by giving a margin to views which was placed inside constraint layout so in a case of large screen it will use constraints and ignore the value of margin and in case of small screen it use the value of margin to keep views separate
If you are using a Linear Layout then set layout_weight to 1 and give margins to views then it will work same as with constraint layout

UI design implementation for multiple screens

I am in android development for last 6 months, recently got a design from a client. I implemented the design and he said this is not exactly look like what the designer has done. Then again he gave me the design with following specifications
my question is - is this right to add the spacing as he has given will this be proper in all devices else how can I explain him what he says is wrong
Please correct me am I wrong or he is wrong

As other users told you, px is not a relative dimension. As an example, we suppose a mobile phone with 5x10 cm screen dimensions, the model has hdpi resolution (480x854 px). For this device, a horizontal margin of 100px takes up more than 20% of the screen width. But, we also have another phone with the same screen dimensions (5x10 cm), but this one is more expensive and it has higher resolution (xxhdpi -> 1080x1920 px). For this case, a horizontal margin of 100 px will not take up more than 10% of the screen width. Therefore, it is needed a relative dimension as dp.
A possible way to deal with your designer could be decide a device to do the designs (a common one). This is a useful link with some devices and their configurations: https://material.io/tools/devices/ . I could recommend you to design using a 720x1080 px (xhdpi) one as MotoG or Nexus 4. For this case, you only need to divide by 2 the px value that he provides you to get each dp value.

You should take in account 3 Things:
Px - dp proportions:
Read this answer : https://stackoverflow.com/a/2025541/5884956 (actually the whole post is useful)
Percentage doesn't work for you:
What you improve by using dp instead of px is that for screens with same
aspect ratio and different pixel density, the layout looks exactly the same (dp-density independent pixel). It means everything inside the screen will look with the same proportions (buttons, imageviews, margins... etc).
Then, you would imagine all android phones have the same aspect ratio (16:9 for example). Which means that for every 16 dp of high, they have 9 dp of width , or in other words if you divide the height of the phone between the width of the phone will give you the same solution as 16/8.
But this is way far from the reality. The most common one is 16:9 but some phones like "Samsung Galaxy S8" have 18,5:9 and there are a lot more aspect ratios: https://material.io/tools/devices/. If you work with %, the time you see your design in a different aspect ratio, your items will look stretched. And this is not the desired.
Size does matter
By this time you should be convinced that dp is the best solution, if not, someone pease improve my answer. Buuuuuut, as the screen size vary, the number of dp also does. So for a phone of bigger dimensions (even for same aspect ratio) we have more dp. Then you should work knowing that some parts are going to be stretched (it should be the spaces between items and margins).
Ideally (Android Studio should do all this work for you) working with same aspect ratio , % of dp should be the mesure and when changing the aspect ratio
this changes must be reflected in spaces between views. But this is a hard work.
TL;DR
Select a standard device that designers are going to use to design (use a common one).
Tell them the design is not going to look exactly the same for every device (unless you design a different layout for each).
They need to decide which parts of the design are going to be the
stretched (stretch spaces and margins please, not buttons or images).
Let them work with px, they may feel more comfortable (meanwhile you must convert it to dp and work with dp). Also if you choose an 'mdpi' device dp = px.
Look at the layouts that allows you work better with this kind of the
designs ( I feel comfortable with ConstraintLayouts, but by working you will notice that this doesn't fit for everything ), but this is up to you.
Extra Information
https://developer.android.com/training/multiscreen/screensizes

Is it a good idea to programmatically create my layout using pixels?

In my activity, I use DisplayMetrics to dynamically get the pixel height and width of the screen, and then I assign each of the components in the Activity sizes based on those dimensions. I wanted to know how this could be affected by screens that have different densities? Is it a good idea to use pixels?
Edit:
The purpose of using pixels dynamically is so that my layout scales based on the given screen. I just want to know how density will play into this. For example, if I have two screens with a height of 1024px and width of 800px, but one is twice as dense as the other, and I want to use 40% of the height and 40% of the width (this is just hypothetical) for a button, why should the density matter? This will just mean that the size of the button will have more pixels in the higher density screen, but the physical size of the button will be the same as DisplayMetrics will always give me the absolute size in pixels. Or am I wrong about this?

See this question and its answers. You will get the answer to your question.
Edit:
From one of the answers on the mentioned question
If you are any serious about developing an Android app for more than one type of device, you should have read the screens support development document at least once. In addition to that it is always a good thing to know the actual number of active devices that have a particular screen configuration.
Screen Sizes and Densities

To help in your case it is proposed to use dp units instead of pixels, but still there will be differences from one device to another.
On a tablet screen with a high pixel density, the elements probably will occupy less relative space.
If you want to improve it more then you will have to do the dimensions calculation by your own.
Or use a layout that auto distributes the space, for example the LinearLayout
Also you have to take into account that it is the system that decides the size of some widgets, for example the standard buttons

Android Scaling for Multiple Resolution Screens

I am developing an Android application where the server sends all the values corresponding to dimensions in pixels for 1920*1080 resolution device.I need the app to be supported on multiple screen resolutions.I went through Android documentation on supporting multiple screen resolutions.It suggests to convert pixels to dip and then render.I did that in my application but the views are not rendered as required.So I tried applying simple unitary method by dynamically getting the screen width and height and then scaling all dimensions based on current screen width and height.
Say my current screen width is X and height is Y.So what I did was
Scaling factor in horizontal direction = New Screen Width/1920.
Scaled dimension in horizontal direction = Scaling factor in horizontal direction * Dimension from server in horizontal direction.
Similarly for vertical direction.
The application is now looking fine on my device.But is it a reliable way of doing things ? Should I be dealing with density of display too ?

DP is probably the better approach, if you elaborate a bit on what you mean by 'not rendered as required' I can try to help.
I can think of two main issues with your current method:
Different aspect ratios of devices. Using your method you will end up with distorted imagery. For example a square in 'server dimensions' is 400x400. In a 800x480 phone, that square will be 162x177 - no longer a square. Depending on your visuals and purpose of your app, this may or may not be an issue. If it is an issue, you need to account for that.
Physical views' size. One of the purposes of the DP method is to ensure a view will have (almost ) the same size across different devices, mainly never too small to handle for the user. So using the DP approach, a 100dp button will be 200px on a high density device, and 100px on a medium density device. This way the button is physically the same size on both devices.
But your method ignores that. Take the square from the first example - it will always be a fifth (400/1920) of the width of the screen. This can be either huge or tiny, depending on the device dimensions. Again, depending on your needs this may or may not be a problem.
Your method can work, as long as you account for these (and maybe more) problems. But it does require special care and probably more coding and work to make it work perfectly compared to simply using DP.

What's dp (density independent pixels) units with CSS?

For Android, people recommend using dp (density independent pixels) measurements for UI elements, and there are conventions that exist such as using 48dp for a button height, etc.
I'm working on a web application, and I'm getting a lot of criticism on the UI design saying it does not conform with Android design standards. Obviously, my application is going to look different since it is using CSS and HTML instead of the Android Holo theme, but I would still like to make it conform as much as possible. However CSS does not allow density independent measurements.
When I test my application on different resolutions and pixel densities, it does not look good, and sometimes, it is way out of proportion so it's not even functional. CSS doesn't have dp units like Android native development does, but I was wondering what some alternatives are.
Can I somehow get the pixel density using Javascript and manually scale everything appropriately? What is the best way for making a web app that looks and works nicely on all resolutions/densities?

I disagree with the currently accepted answer. As uber5001 suggests, a px is a fixed unit, and in a similar spirit to the efforts of the Android-specifc dp.
Per Material's spec:
When writing CSS, use px wherever dp or sp is stated. Dp only needs to be used in developing for Android.
Additionally
When designing for the web, replace dp with px (for pixel).

http://www.w3.org/TR/css3-values/#lengths
The closest unit available in CSS are the viewport-percentage units.
vw - Equal to 1% of the width of the initial containing block.
vh - Equal to 1% of the height of the initial containing block.
vmin - Equal to the smaller of vw or vh.
vmax - Equal to the larger of vw or vh.
The only mobile browser to be aware of that doesn't support these units is Opera. http://caniuse.com/#feat=viewport-units

Use rem.
It is the font size of the root element and a very good base unit for the size of other UI elements.
If one used the same absolute size (in centimeter), the text and other elements would be much too big on mobile or much too small on desktop.
If one used the same amount of pixels, the text and other elements would be much too small on mobile or much too big on desktop.
The rem unit is on spot because it says "Hey, this is how big normal text should be." Basing the size of other UI elements on this is a pretty reasonable choice.

In CSS3 it may be more accurate to say that the web doesn't have Android's px. The spec for CSS3's px says this:
pixels; 1px is equal to 1/96th of 1in
px might be the measurement you want, in the future.

As of CSS3, there are no CSS units that are truly device-independent. See the W3C spec on absolute lengths. In particular, the absolute units might not match their physical measurements. From the spec:
Note: If the anchor unit is the pixel unit, the physical units might not match their physical measurements. Alternatively if the anchor unit is a physical unit, the pixel unit might not map to a whole number of device pixels.
Note: This definition of the pixel unit and the physical units differs from previous versions of CSS. In particular, in previous versions of CSS the pixel unit and the physical units were not related by a fixed ratio: the physical units were always tied to their physical measurements while the pixel unit would vary to most closely match the reference pixel. (This change was made because too much existing content relies on the assumption of 96dpi, and breaking that assumption broke the content.)
If physical units were true to their purpose, you could use something like points; points are close enough to dps:
1 in = 72 pt
1 in = 160 dp
1 dp = 72 / 160 pt
If you use SCSS, you can write a function to return in pts:
#function dp($_dp) {
#return (72 / 160) * $_dp + pt;
}
And use it:
.shadow-2 {
height: dp(2);
}

What about a interface based on rem units?
I'm not experienced enough on the matter to confirm, but I think you could make some math based on the viewport size to apply a font-size in the root element and the entire interface would adjust accordingly. This stuff is a bit of witchcraft to me yet.

Why not use points, it is a consistent size across devices. And is relative to the screen size. Most are not familiar with it since it comes from traditional publishing.

What about use some mix between vw ( screen's width for any device) and em?
Here font-size is changing dynamically, depending your device screen width.
Use in your main CSS file next rule:
font-size: calc(100vw * 10 / 375);
(width for iPhone 6/7/8 is 375px, change it to 320px (iPhone5) and etc)
In all cases it is going work perfect. There is only one minus. If your goal is "pixel perfect", then you need to use big numbers after dot.
Example: your goal is font-size h5: 18px on all screens.
Then your perfect "em" will be:
h5 {
font-size: 1.79904em;
}
without perfection use 18 / 10:
h5 {
font-size: 1.8em;
}
According to Google Chrome you get 18.0096px;

It's 2023 and responsive web design with breakpoints that target device widths are the best practice to anticipate changes to screen and appropriate sizes for typography. An alternative to using break points to adjust font sizes is to load discrete CSS files per device, so separate sets of CSS exist in parallel for each width. This latter however is a nightmare to maintain, and simply keeping CSS written with breakouts for breakpoints together keeps everyone sane and everything tidy.
That all said, use PX, reduce font sizes for smaller screens with breakpoints, and let the devices themselves handle the smoothing.
Having lived in the world of relative units where sub-elements refer up a level for their size reference so 1em at the root level and 1em two levels down the child hierarchy / DOM are not the same is another recipe for madness.