screen size for app design

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.

screens-densities

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

For more details about DIP read here.

            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:

my_art

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.

actual__size_problem

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
Gradient
9-patch Drawable
Repeating Pattern
Full screen image

A NinePatch drawable is a PNG image in which you can define stretchable regions. More information about 9-patch drawable and how to create one

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.

background_image

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

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.

bg_full_screen

            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.

bg_stratching

            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_in_center

* 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

content_to_cover_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.

list_view

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:

full_width_content

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.

content_in_center_vertical

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.

panorma

panorma2

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.