## Tips for Designers: from a Developer

Android is a versatile OS with more than 1000 device manufacturers and more than 18000 distinct devices. Screen size of android phones vary from 2.6â€ – 6â€ and the resolution of screen ranges from 240 X 320 to 1440 X 2560 px with screen density from 120 to 640 dpi (ldpi to xxxhdpi). It is difficult for designers to create such designs which work well on all these devices irrespective of the size, density and aspect ratio of device and still stay developer friendly. In this blogpost I will discuss some useful techniques that ease out the painful design implementation in Android devices that I’ve learnt over a period of time.

# Android’s way of dealing with this diversity:

Android provides basic structure to support these devices by putting them in different density buckets i.e. ldpi, mdpi, hdpi, xhdpi, xxhdpi and xxxhdpi.

```mdpi is base density and 320 X 480 px is the base screen size for mdpi.
```

For keeping all these ‘screen resolution and density’ combinations simpler, Android wants us to consider them as DIP or DP units (Density Independent Pixels), which are corrected for density. For designing/development perspective, Android treats any device as its DP unit size instead of its actual pixel size. Android calculates DP size by using following formula:

` DP size of any device is (actual resolution / density conversion factor).`

Density conversion factor for density buckets are as follows:
ldpi: 0.75
mdpi: 1.0 (base density)
hdpi: 1.5
xhdpi: 2.0
xxhdpi: 3.0
xxxhdpi: 4.0

# Examples of resolution/density conversion to DP:

* ldpi device of `240 X 320 px` will be of `320 X 426.66 DP`.
240 / 0.75 = 320 dp
320 / 0.75 = 426.66 dp

* xxhdpi device of `1080 x 1920 pixels` (Samsung S4, S5) will be of `360 X 640 dp`.
1080 / 3 = 360 dp
1920 / 3 = 640 dp

` Designers should treat all Android devices as their DP size. `

So in this approach, designer can create a base design and can provide resources(drawables) for all density buckets. Developer just need to create the basic layout according to the base design and put the drawables in correct drawable-density folder and thats it, OS will pick the correct resources based on current device and design will look awesome on following screens:

# Actual Issue

` Screen resolution vary vastly in one density bucket. `

It means Density independent size of devices vary vastly. So, lets compare base size with Samsung Galaxy Mega:
Base size of Android device in DIP is `320 X 480 dp` on the other hand Samsung Galaxy Mega is of `480 X 853 dp` or 720 X 1280 px hdpi.

Fundamentally Samsung Galaxy Mega is 160 dp wider and 373 dp taller than base size. (and here I am referring DP not px)
Actual issue is, designer should create such designs which scales well on all the screen sizes to cover this extra screen space.

# Guidelines for scalable designs

` Designers should create base designs of { base size of mdpi devices(320 X 480) * density conversion factor of highest supported density bucket } size.`

For example, if we want to support devices upto 3x density(xxhdpi) then designer should create base designs of 960 X 1440 px (320 * 480 X 3). Reason for creating base designs for highest supported density is that we can down scale drawables for lesser density buckets easily.

For scalability designers can utilise following guidelines:
1. Guidelines for background
2. Guidelines for foreground

# Guidelines for background

Background could be one of the following:

• Color
• 9-patch Drawable
• Repeating Pattern
• Full screen image
```A NinePatch drawable is a PNG image in which you can define stretchable regions.

If we are using anything other than ‘Full screen image’ as background, it won’t cause any issue as all of them are scalable.

# Using full screen image as background

First of all, its not a recommended approach as it might cause memory issue. Even though if designer needs to use full screen image as background, there are following ways to scale it:

• Use Image with largest supported dimension
• Keep it in center and add a colored/gradient border around it
• Can stretch it to full screen (aspect ratio will not be maintained)

# Use Image with largest supported dimension

If dimension of the largest supported phone is 1080 X 1920 px, designer can use the background image of this size. On smaller devices image will be cropped from center.

For example if designer wants to use following image as background, s/he can crop it to 1080 X 1920 px.

This cropped image will look as follows on nexus 5 and nexus S.

`Tip for designer: Should choose the image wisely so that no important details lie at borders.`
```Tip for developer: can use scaleType CENTER_CROP of ImageView to crop the image from center without distorting the image.
more details ```

# Keep image in center and add a colored/gradient border around it

If designer don’t want to lose any details from border of the image and wants the image to be fully visible on all the devices, s/he can provide the images of 320 X 480 dp and can provide a color/gradient to be visible as borders on larger devices.

In this case, background will look as follows on larger device with brown color border.

```Tip for developer: can use scaleType CENTER_INSIDE of ImageView to keep the image inside device boundary without distorting the image.
more details ```

# Can stretch image to full screen

If designer has created a background which don’t look bad if stretched a little bit we can stretch the image to cover the full background.

`Tip for developer: can use scaleType FIT_XY of ImageView to stretch the image to full screen. more details `

# Guidelines for foreground

We can categorise foreground designs in following three types according to the content scrollability:
1) Non scrollable content
2) Vertically scrollable content
3) Horizontally scrollable Content

# 1) Guidelines for non scrollable content

If content is non scrollable, designer can arrange content as follows:

* Content could be in center of the screen
No special arrangement needed to support different screen sizes. Most of the splash screens lie in this category.

* Content could be aligned in top left corner (for LTR languages)

* Content could be aligned in top right corner (for RTL languages)

* Content could be aligned to fill entire screen

Tips for designer:
1. Can create designs in which some part is non-stretchable (logo in above example) and other parts are stretchable (5 list items in above example)
2. Cannot change the size of text for specific density bucket: it means if the size of text for mdpi is 16px it will remain same for all mdpi devices but for other density buckets Android will automatically scale them according to the density conversion factor, so for hdpi devices text size will be 24 px, for xhdpi devices text size will be 32 px and so on.
3.Cannot change the size of image for specific density bucket.

Tip for developer:
For stretchable content developer can put them in LinearLayout and can assign individual content a ‘layout_weight’ and Android will automatically distribute the extra space accordingly.

# 2) Guidelines for vertically scrollable content

If content is vertically scrollable, no special arrangement needed to tackle with extra height as more vertical content will be visible. For dealing with extra available width designer can arrange content as follows:

* Content could be edge to edge (covers whole width)
Most of the list items lie in this category.

Tips for designer:
1. Can keep left and right margins constant for all the devices of same density bucket.
2. In list row, can keep left and right items with fixed width and can make item in center stretchable.
In above list, icon image and distance text are of fixed width.
Center text (item name and description) is of variable width, so it will cover the extra width available on larger devices.

Tips for developer:
For creating such list items developers can use RelativeLayout as the parent layout and can arrange child elements as follows:
Left item: Assign layout_alignParentLeft property true and provide the fixed width.
Right item: Assign layout_alignParentRight property true and provide the fixed width.
Center item: (with flexible width) Mark it as ‘toRightOf’ of ‘left item’ and ‘toLeftOf’ of ‘right item’ and provide appropriate margin/padding.

Another example of full width content is as follows:

Tips for designer:
1. Can show the images which cover full width of device and can keep the aspect ratio intact.
2. Can make text to cover full width. (Though can’t change the font size for same density bucket. On wider devices extra content will be visible in one line)
3. Can show buttons, edit texts to cover full width. Only background will be stretched. Text on button or edit text will remain the same size. Background of these elements could be color, gradient, 9-patch drawable or repeating pattern.
(for instance, if a button takes full width of screen with some margin from left and right and its background is stretchable, the button can take full width on all screen sizes).

* Content could be left aligned, right aligned or horizontally centered
If content is not edge to edge, it could lie in this category. Following is an example of horizontally centered content.

Tips for designer:
1. Can’t change the size of the elements.
2. Can’t change the spacing between elements. It means, if content is left justified, all extra width will be covered by right free space, if right justified then by left free space and if content is in center, extra space will be equally distributed in left and right margins.

# 3) Guidelines for horizontally scrollable content

View Pager is an example of horizontally scrollable content. View Pager displays pages which user can scroll horizontally.
If width of a single page is equal to width of screen we can handle extra available space by above mentioned techniques. Examples: Play Store’s application listing, Gmail’s email detail pages etc.
Else there could be cases where width of page won’t be equal to the screen width. One example of this view is Food Network On the Road app’s dashboard, where content of left and right pages are peeking into the screen from sides. (similar to Panorama View of Windows Phone). Designers can utilise extra space in following ways:
* Can keep the width of peeking views constant so it will increase the distance between current page content and peeking views.
* Can increase the visible width of peeking views and keep the distance between current page content and peeking views constant.

To conclude, designers should design the screens keeping in mind the extra space available on Android devices and should clearly mention how to fill this extra space using redlines so that developers can create the layouts which looks as expected.

1. Maragues says:

Great sum up, thanks!

2. Varun Tewari says:

Good Read ! Thanks for the detailed information. Designers/Developers tips are out of box.

Being an Android Developer often new designers comes to me with there confusion over various densities and resolution.
I often tell them to follow below table when designing pixel perfect Style Guides and providing graphics assets.

Density Ratio

(Baseline) MDPI 160 1 StyleGuide for Baseline coz 1 px equals 1 dp. Designers can design in px and Developers can put them as dp.
HDPI 240 1.5
XHDPI 320 2
XXHDPI 480 3
XXXHDPI 640 4 Graphics Assets for Max Device Support

To keep apk size low we only provide assets for max density supported device. And let lower end devices to scale-down.
I find this approach less expensive than adding graphics for all supported density folders or scaling up assets.
Is this the correct way, can you please provide your view ?

3. alok says:

In my opinion, it’s better to include specific assets for the densities we want to support. This way it will be more memory efficient. For example, if we have an asset of 400X400px for XXXHDPI devices, for MDPI devices the same asset will be of 100X100px. If we provide only XXXHDPI assets and use them on MDPI devices, they have 16 times the amount of data that they need for MDPI devices, which has to be handled when the app starts and resources are prepared.

If we provide assets for all supported density buckets apk size will be larger (downside) but at runtime our app will consume lower memory will be more efficient and there will be less chance for an OutOfMemoryException.

4. Pingback: Android Screen Density | Abdalla Adel Essa

hey thanks for the helpful information

6. Kushal Gandhi says:

Very nice tutorial for Android UI screen topic
Thank you Vinsol and team

7. tom says:

This is a good read. I have an android developer who asked for UI screen designs delivered in PSD format to the size of the Nexus 5. I thought it was odd that he didn’t ask me to design alternative boards for other screens, or at least deliver assets for the different device sizes. Does this mean the app he develops will only look correct on a Nexus 5?

8. alok says:

Hey Tom, App might or might not look correct on other devices, it completely depends on the way layouts are written. But it is always good to put assets in different density drawable folders until we are using svg assets.

9. Soul says:

Hi! Alok

Thanks for the article. Really a nice one.

I am a UX designer learning mobile design (android and hybrid app) and I want to know the answer for the below questions,

1) You have mentioned DP as units instead of px in the drawable(images). Since one dp is equal to one px is it fine to explain to my fellow visual designers in pixels who use photoshop/sketch and other tools in px/pt?

2) I have to create an app UX/UI design. Which is the correct size to start with mdpi/hdpi/xhdpi?

3) If so what pixel dimensions should I consider? Should it be based on the actual resolution (1080 x 1920 px) and consider the base font as 48px since its xxhdpi? and should I consider icon size based on the material design as png 144x144px size?

4) https://material.io/icons/ When I click on one of the icon, there is a blue bar which says 18dp, 24dp, 36dp and 48dp what are those? and svg, png and font download Can you pls expalin these.

5) And I am trying to learn android and hybrid app. Should I follow the same process for hybrid app too. But hybrid app uses html5, css3 and javascript by using cordova or phone gap. Or please help me with some resources to understand hybrid app?

Thanks and Regards
Deepak

10. alok says:

Hi Deepak,

1) You have mentioned DP as units instead of px in the drawable(images). Since one dp is equal to one px is it fine to explain to my fellow visual designers in pixels who use photoshop/sketch and other tools in px/pt?
A) Yes.

2) I have to create an app UX/UI design. Which is the correct size to start with mdpi/hdpi/xhdpi?
A) If you are using Sketch (or any other vector graphic tool), my suggestion would be to design in mdpi as Sketch provides option to extract assets in 2x, 3x and 4x effortlessly. But if you are using Photoshop then you should design for 4x(xxxhdpi) as it would be easier to downscale the assets.

3) If so what pixel dimensions should I consider? Should it be based on the actual resolution (1080 x 1920 px) and consider the base font as 48px since its xxhdpi? and should I consider icon size based on the material design as png 144x144px size?
A) I suggested in the post to create base design of 960 X 1440px (320*480 X 3) but as the post is 2 years old and things are changing rapidly in mobile world, now I will suggest you to create base design of 1440 X 2560px that is 360*640 X4. Reason is, now most of the Android devices are 360X640dp or larger. Base font will be 48px.

About launcher icon: Now we put launcher icons in mipmap folders which are different then drawable folders. Base icon size is 48*48px for mdpi and 1.5, 2, 3, 4 times for hdpi. xhdpi, xxhdpi and xxxhdpi respectively.

4) https://material.io/icons/ When I click on one of the icon, there is a blue bar which says 18dp, 24dp, 36dp and 48dp what are those? and svg, png and font download Can you pls expalin these.
A) Sizes are for status bar icon, tab bar icon, menu icon and launcher icon. Different formats are for downloading assets in those formats.

5) And I am trying to learn android and hybrid app. Should I follow the same process for hybrid app too. But hybrid app uses html5, css3 and javascript by using cordova or phone gap. Or please help me with some resources to understand hybrid app?
A) I have never worked on hybrid app so I wonâ€™t be able to help you in that regard.

Regards,
Alok