Apps development for Android step by step

Appendix C: Everything about sizes and dimensions in Android

Designing Android app you have to be aware of enormous variety of devices. They have different physical sizes (from small phones to large tablets), different screen sizes (diagonal from 3 inches or less to above 5 inches), different screen resolutions (from 320×480 pixels to Full HD – 1920×1080 – or more) and different screen densities – number of pixels per inch (from 120 dpi to 480 dpi). And there is also screen orientation (landscape or portrait) to take into account.

It would take very, very long time to create layout for every device separately and you still couldn’t be sure that you included all combinations. Fortunately,  Android creators tried to do it simpler. You don’t have to create unlimited layouts, but it doesn’t mean that there is nothing to worry about.

Available units: Forget inches (in), say goodbye to pixels (px), use density-independent pixels (dp or dip)

Android allows you to measure layout elements even in inches (abbreviation “in”). So you could say that specific TextView or Button would be 3 inch long and 1 inch tall. This would be rather difficult to use as many elements would have to be measured in fractions and still it would be impossible to be very precise. Similar situations is with millimeters (abbreviation “mm”) and points (abbreviation “pt”).

More common approach is to use pixels (abbreviation “px”). But that leads to another problem. If we create an element that is 160 pixels wide it’s length on medium density screen would be 1 inch and on extra high density screen only 0.5 inch even if the screens have the same resolution.

That’s why there is one more unit which hasn’t those problems. It’s called density-independent pixels (abbreviation “dp” or “dip” – both work). If we say that something has 100dp it would have the same real size on every screen. So for all dimensions in Android app use dp only, unless you really have to use some other unit. When you define dimension in dp, Android automatically uses as many pixels as needed on specific screen to achieve expected size.

List of supported units:

dp or dip – density-independent pixels, abstract unit based on physical density of a screen

in – inches (not recommended)

mm – millimeters (not recommended)

pt – points, 1pt equals 1/72 of inch (not recommended)

px – pixels (not recommended)

You have to put unit after the value without space between.

For instance:

Measure units comparison in Android – only dp is universal (Android Studio)

Measure units comparison in Android – only dp is universal (Android Studio)

But what is easy in XML, it’s not so easy in Android Java. Though recommended unit is dp, Java methods use px as default. You have to do conversion on your own. First you have to check device scale ratio and then multiply it by dps you need (and add 0.5 to round it up). The result is float number that have to be change to int for measure methods.

This is an example (textElement is for instance TextView):

This is rather complicated so better define layout in XML or use… dimens.xml described below.

For text size use scale-independent pixels (sp)

When you define font size you could use all previously mentioned measure units. But there is one more unit created especially for text. It’s called scale-independent pixels (abbreviation “sp”). It’s very similar to dp, but have one more characteristic – reacts to user preferences about text size. In most cases sp equals dp, but if user want to scale text  it would allow to increase/decrease font without changing the size of other elements. So it’s recommended to use sp every time you refer to fonts.

For example:

Save dimensions in dimens.xml

Similarly as you define strings or colors you could define dimensions. Typically dimensions are stored in dimens.xml file in values folder (in resources). Usually there is already such a file and all you have to do it’s just adding yours extra definitions.

You could define various dimensions, like margins, padding, height, width, radius, text size etc.

This is an example of dimens.xml:

You could refer to them both in XML and in Java.

XML example:

Java example:

As you see in Java you have to refer to resources and use getDimensionPixelSize() method (that converts result to int, there is also getDimension() method that returns float value without rounding). Be careful as setWidth(R.dimen.textview_length) doesn’t show any error, but only because resources has int IDs. In this case you use ID value not value saved in dimens.xml.

There is one very useful effect of using getDimensionPixelSize() or getDimension(). They automatically convert dp or sp into pixels based on screen density. So you don’t have to do it on your own. If your text size is 16sp on mdpi screen it would have 16px, but on hdpi screen it would have 24 px.

Use many dimens.xml for various device types

Using dp and sp we have guaranteed ourselves that our layout would look the same on screens with different density. But usually we have much more space on 10 inch tablet than 4 inch phone. In the first case layout elements could be bigger.

To use various dimensions for different devices we could create separate dimens.xml files for them. Or to be more precise Android Studio already created them, so our aim is just to fill them with right values.

In project structure you could find values folders for smartphones, medium tablets and big tablets (Android Studio)

In project structure you could find values folders for smartphones, medium tablets and big tablets (Android Studio)

There are three values folders interesting for as: values, values-sw600dp and values-sw720dp-land. First one is mainly for smartphones, second for 7 inch tablets and third for 10 inch tablets (in landscape orientation). You could use just two of them: first for phone and second for all tablets.

In all of them you could find dimens.xml files (if not, just create them). This allows you to decide what size of objects and text would be on different devices.

For instance:

Dedicated layout files for various device types (and screen buckets concept)

Android creators introduced so called buckets to divide devices based on their screens parameters. There were defined four size buckets:

small – screens at least 426dp x 320dp (all smaller are scaled to it)

normal – screens at least 470dp x 320dp

large – screens at least 640dp x 480dp

xlarge – screens at least 960dp x 720dp.

If you want to address large device, you could create folder layout-large and keep there a copy of your layout files.

Unfortunately that concept didn’t work to good as in the large group you could have phones and small tablets that usually need different approach.

New concept is based on minimum available width in dp (for instance in case of 640dp x 480dp it equals 480 dp). There are now three standard selectors and related layout folders:

layout – for all devices with minimum width below 600dp (for instance 480×800 dp)

layout-sw600dp – for all devices with minimum width above 600dp (for instance 1024×600 dp)

layout-sw720dp – for all devices with minimum width above 720dp (for instance 1280×800 dp)

This allows you to create dedicated layout files for them.

For instance:

Dedicated layout files for various screen orientation (landscape and portrait)

You could combine minimum width concept with additional qualifier based on screen orientation do create layout dependent on how user keeps device. There are two such qualifiers: land for landscape and port for portrait.

Let’s imagine that you need special layout for 7 inch device in portrait mode. Then you have to keep your dedicated layout file in res/layout-sw600dp-port.

And for 10 inch tablet in landscape you use res/layout-sw720dp-land.

There is also another option. You could store both files in main layout folder, but with different names. Then when you start your app you first check smallest width and set appropriate layout file.


Java code:

Images  for various screen densities

All images you use in app are automatically scaled to device screen configuration. But that could negatively influence graphic quality. You should deliver images dedicated to various screen densities for the best effect.

There are four main densities you should consider: medium (mdpi – 160 dp), high (hdpi – 240 dp), extra high (xhdpi – 320 dp) and extra extra high (xxhdpi – 480 dp). Beside there is also low density (ldpi – 120 dp), but it isn’t longer important so you could leave it for automatic scaling.

The best if you prepare bitmaps for all for variants. Then you have to save them in appropriate drawable folders. If you don’t have any, Android would try to do it best on its own…

Best practices related to Android apps layout

To sum it up: there is a group of rules that helps to create layout appropriate for all devices:

  • use only dp, match_parent or wrap_content for layout elements dimensions
  • use only sp for text sizes
  • keep dimensions in dimens.xml files (not hardcoded in app code)
  • provide images for various screen densities
  • remember that Android has touch interface – objects that you have to touch can’t be too small or too close to each other. Recommended minimum size for icons is 32 dp and you need 8 dp free space between another icon.