In today’s world, there are a plethora of devices for people to choose from and it can be daunting to try to accommodate and build for the best experiences on all devices. However, it’s important to stay up-to-date with the most popular screen sizes and resolutions when designing mobile applications. A site that is optimised and responsive makes for an easier user flow and ultimately, an enjoyable experience for your audience.
With wide range of devices like mobiles, desktops, tablets and further more, websites traffic rate(Number of times user hits a website) has tremendously increased and developers have to offer the best experience for their users because user may judge your application within few seconds. This might be debatable, you may argue saying.. “that’s unfair man”.. blah blah, but dude.. judge for yourself. Whats the first thing that comes to your mind when you see a website or an mobile application? You don’t intend to see its functionality unless its interface is actuating, right?
Responsive design means designing your app keeping in mind will be used across range of devices screen sizes.When you are building an android application it is bad practice to just completely design your full app and then to start the brainstorm about higher screen UI because those UI pattern often has impact on the phone design and the architectural decisions.
There are no mobiles with consistent sizes and cannot guarantee on how manufacture’s next version of device screen could be? Devices that are more costlier offers more pixel perfect than those of less costlier ones, right? We need to build applications that adapts to all different devices but there are so many devices, so where do we begin??
We start by grouping devices into buckets based on their size like a bucket for phones, a bucket for 7inch tablet and a bucket for 10inch tablet.To simplify the way that you design your user interfaces for multiple screens, Android divides the range of actual screen sizes into a set of four generalised sizes:
- xlarge(Extra large)
Nope. Classifying based on size alone is not enough, even among devices with same size there stills wide range of screen densities.
What the heck it screen density anyway? Screen density or dpi is calculated from number of dots per inch. More the number of dots, greater the sharpness of the screen.
- ldpi (low) ~120dpi
- mdpi (medium) ~160dpi
- hdpi (high) ~240dpi
- xhdpi (extra-high) ~320dpi
- xxhdpi (extra-extra-high) ~480dpi
- xxxhdpi (extra-extra-extra-high) ~640dpi
As shown in the image, as we move from left to right, the pixels are more compacted and crowded with density.
When we specify view dimensions, we quickly realise we can’t use pixels.For example, a 40pixel button that looks fine on a MDPI device, will look much smaller on a XXHDPI where are pixels are more compacted and the physical size of 48pixels is much smaller. How do we solve our problem? Is there any consistent unit to measure like cm or mm?
Consistent Unit of measure ?
The number of pixels a single “dp” translates to, varies depending on the pixel on screen density and the density bucket the device falls into. Just specify view dimensions as dp and leave the rest to android framework, it will do all the hard work for you.
If you are interested in how it works, do give a read to the next section for the same, else you may skip it, doesn’t cost you much though.
Wondering how a dp is mapped to physical pixel?
The density-independent pixel is equivalent to one physical pixel on a 160 dpi 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.
The conversion of dp units to screen pixels is simple:
px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application's UI, to ensure proper display of your UI on screens with different densities.
Resource Qualifiers : Buckets with different sizes
Android allows you to create alternatives versions of every resource by placing them into folders with different qualifiers. We separate each of those using a hyphen(-). So at run time android will check the current device configuration and load right layout and drawables accordingly.
res/layout/main.xml : Layout inflated at runtime for normal screen sizes.
res/layout-small/main.xml : Layout inflated at runtime for small screen sizes.
res/layout-large/main.xml : Layout inflated at runtime for large screen sizes.
res/layout-large-land/main.xml : Layout inflated at runtime for large screen sizes with landscape mode.
and many more to it.
The fact that activity restarts on a orientation change, makes sense as layout may look entirely different from the previous layout.
Android framework, at runtime inflates the more apt resources specified for your device configuration are fetched and populated for the best user experience. Also note when inflating resources for different screen sizes, if android doesn’t find any of the apt resource specified in the layout it currently using, then it falls back to the next bucket screen size and perform a look up and so on. This way, android could use resource that is being inflated in two or more different devices with a single version of it and the duplications could be avoided since it might significantly increase the size of your apk file.
This is my first ever blog, and I believe it wasn’t that bad and please do suggest me for better ways. Let me know if this has helped you in anyway through comment section.
Thats all for now, cheers and best of luck.