Latest News

What's happening @ Archimedes? Get latest info on events, project updates, or just participate in our geek blogs!

A Date with Android Layouts

Posted by on

As every new dev would dream about is landing into a new project and start learning new things, working around with code, grasping the main theory of Android Framework. My start wasn’t even near to it. Almost every dev considers the task which is related to layout designing a piece of cake and are never interested in learning this dimension of the application. This was my beginning.

7 inch optimization of an app, my first assignment, my entrance in the world of Android. I started working on an app which was already mature and was doing good on Google Play. Its tablet version is available but now a "7 inch version" was also required.

Designing for multiple screens

First thing that comes into my mind while designing layouts for multiple screens is “Multiple screen support”. If you think that Developer’s guide would be kind and easy to go through, then at first you might be right, when the nightmare starts……….. you’ll figure it out.

The developers guide was more of an open puzzle, a 7 inch screen would opt for Large layouts but a 5.1 inch screen would also do the same. According to guide the ranges of xlarge, large and normal layouts were having overlapping boundaries, some 7inch devices would opt for xlarge layout rather than large, but for now it was safe to assume that a 7 inch device would opt for large-layout so I created a respective folder and started to place my layout there.

Working on a mature app one should never forget that there are things implemented in a specific way for a cause. My designs for 7-inch device (emulator) worked like charms and we almost a perfect scale down of 10 inch version. There was no rocket science behind this, all I did was used DP, SP for dimensions and made sure that layouts would appear as desired through re-checking graphical view of the xml files. The problem that came along was with previously implemented animations. They were hard code with 10 inch tab and now they were not functioning as desired.

Differentiate between multiple screen sizes programmatically

Now differentiating between two different screens sizes through code was an easy job. For the first my search results worked as "I feel lucky Today". A simple piece of code that used Window manager to get screen dimensions and would convert them into inches, then a simple Pythagoras theorem would get the screen size. So now animations were re-organized under conditions:

If(screenSize>=6.5&&screenSize<=7.5)

Seems like a hack, but no piracy breach here so it's fine!

I Hate Google

It was a story of Kate and Leopold falling in love after some hurdles but they didn’t expect a twist in the tale when Kate’s ex comes into the scene out of nowhere. Same thing happened when everything got done and I was about to finish up soon, but then came NEXUS 7, an awful device and a nightmare for almost every dev. All of my hard work went down the drain as now my screens wouldn't completely fit into this device. Dianne Hackborn describes this device as out of ratio (sort of) with high density screen (a very high density screen called tvdpi but can be used as hdpi). This device is like 16:10 while other devices are 16:9. So it’s visually wider and would show more contents. Now I had to decide a work around without using weights because they were not compatible with animations. Again a very simple solution but this came after a lot of searching and hit and trail.

Work around (Dynamically adding Layout Parameter)

Calculating screen height and width, subtracting some static-fixed views, dividing the remaining spaces respectively for my view and passing the Layout parameters at run time were a few things that helped me with the compatibility issues. Also calculating the pre-occupied spaces of headers, tabs and some bar (the static views) required converting dp to px (density-pixel to pixel). The formula was easy and could be executed well if one finds a proper way to calculate screen density ratio.

Best Practices

There are different screens with different screen densities and size. If one is optimizing for a screen he/she should also keep in mind that screens also differ in screen densities. To make things more organized one should keep different layouts for screens sizes such as

Layouts-large for 7inch devices.
Layout-xlarge for 10 inch devices.

When defining better layout for different screen resolutions, organize them further. That would be:

Layout-large-hdpi for Nexus 7, Kindle Fire HD.
Layout-large-mdpi for Kindle Fire.

Another thing to keep in mind is that one should never use absolute values. Everything will look nice if you are using fill_parent and wrap_content for your layout_width & layout_height tags. Android does most of the work itself. Also use RelativeLayout and LinearLayout when designing, as it will help your layouts stretch gracefully.

Conclusion

There are things often overlooked by the devs while learning and developing an app - layout designing is on top of the list. It is extremely difficult to come across consistent and exactly same looking screens with proportionally scaled-down layouts. There are thousands of devices running on android and it seems that there are no standards that are kept in mind while vendors design screen hardware. Many devices differ from others in the aspect ratio of screens. There is a with a 4.65 inch screen size and 720x1280 screen dimensions and another device with a 4.7 inch screen that has 720x1280 dimensions. Even minute details won't be consistent across devices with differing dpi, aspect ratios and dimensions.

Fahad Ishaque has not set their biography yet

Comments

  • Guest
    Nauman Rafique Thursday, 19 September 2013

    Well, very nice piece of advice about Layouts, after getting picture of your date .... i am of thoughts to start over android with different layout (feeling excited), would also like to get some help from you for mine "Date" ;)

Leave your comment

Guest Wednesday, 22 November 2017