Optimizing graphical content for Android devices

One commonly overlooked problem that can arise in Android app development is optimizing the graphics to look great across all ranges of devices.

There are many different Android devices and since there are no particular rules on what size the screen should be, what the resolution should be, or the aspect ratio of screens, creating a good looking app can quickly become a daunting task. Throw tablets into the mix and one could quickly foresee a headache in their future.

To help grasp the seriousness of the situation, imagine that you have assigned a background image to fit perfectly to a certain device. On another device with a different aspect ratio and resolution, the image will fit much differently, can could look skewed, distorted, stretched, or cause memory issues because the device was expecting a much smaller image knowing it has a much smaller resolution.

Thankfully Android does provide solutions to these issues. Take a look at the specs of some popular android devices.

Device Screen Size (inches) Resolution Pixels Per Inch Aspect Ratio Density Category(DPI)
Galaxy Note 5.3 800×1280 285 5:8 (10:16) xhdpi
Galaxy Note II 5.55 720×1280 267 9:16 xhdpi
Galaxy S II (I9100) 4.27 480×800 219 3:5 hdpi
Galaxy S III (I9300) 4.8 720×1280 306 9:16 xhdpi
Galaxy S4 (I9500) 5 1080×1920 441 9:16 xxhdpi
Galaxy Note 10.1 10.1 1280×800 149 8:5 (16:10)
Galaxy Note 10.1 (2014 Edition) 10.1 2560×1600 299 8:5 (16:10) xhdpi

Take Notice of all the different Screen Sizes, Resolutions, and Aspect Ratios. This is a designer’s nightmare! There must be a way to deal with this, and there is.

This is where screen sizes and densities (which can be found by the ppi (pixels per inch)) that android has broken into Density Categories come into play.

Much like iOS lets you define a ‘normal’ and ‘retina’ resource for images, Android allows you to define different images and layouts for different screen sizes and density categories. Each category is designed to hold the image that should be shown on a device with a density that falls into that category. However since large tablet screens can have a higher resolution and a lower ppi because of their large screen size, the density categories can be broken down further into a basic screen size.

First the default or ‘phone’ set of resources, can be defined and placed into the following categories

  • drawable-ldpi
  • drawable-mdpi
  • drawable-hdpi
  • drawable-xhdpi
  • drawable-xxhdpi
  • drawable-xxxhdpi

Tablets of approx. 7″ can have their resources defined  and placed into these following

  • drawable-large-mdpi
  • drawable-large-hdpi
  • drawable-large-xhdpi

Tablets of approx. 10″ can have their resources defined  and placed into these following

  • drawable-xlarge-mdpi
  • drawable-xlarge-hdpi
  • drawable-xlarge-xhdpi
Here are the categories further broken down into some usable information.
ldpi mdpi hdpi xhdpi xxhdpi xxxhdpi
scale factor 0.75 1 1.5 2 3 4
suggested icon size 36×36 48×48 72×72 96×96 144×144 192×192
approx pixel density 120 160 240 320 480 640
I know that creating 12 version of each resource can seem like a daunting task, but it is a necessary one if the app demands to be heavily image dependent, and it wants to look good across all devices. Further more we can actually define completely different layouts (or arrangements of the contents of the screen) for different screen sizes, so a small screen, can have a different layout than a medium screen, which can be different from a large one’s layout.
One problem that can be ran into with this, is the size of your app. By including so many images, that size will grow rapidly. Google has created a solution for this problem, in which you release the same app multiple times. So technically you will have multiple types of the same app out, each one targeting different hardware, but the app will still be listed as the same app. Here is an excerpt from google about it
Multiple APK support is a feature on Google Play that allows you to publish different APKs for your application that are each targeted to different device configurations. Each APK is a complete and independent version of your application, but they share the same application listing on Google Play and must share the same package name and be signed with the same release key. This feature is useful for cases in which your application cannot reach all desired devices with a single APK.
With this in mind, we can create a phone version, small tablet version, and large tablet version of the same app, and eliminate issues with the size of the app.
Another thing you can do is only include every other Category of resources, so instead of including ldpi, mdpi, and hdpi, include only ldpi and hdpi. eliminating some of the categories in this style can save memory, time, and often have a very small effect on the app visually. Android will automatically pull the closest to correct size resource it needs, and scale if for you. If it doesn’t quite look right, you can always include it later.
Finally, the best optimization is try to eliminate large images altogether! The design trend is moving towards solids and flats, but Android can even create gradients and some more complicated shapes and backgrounds through cheap, scalable, and easy to use .xml drawable files. By using .xml drawable files for backgrounds, you can save memory at runtime and the size of the app, all while improving performance. This could be a post all in itself, how to use android .xml drawables, and it may well be: just remember that more is possible with these gems then you might think, and they look amazing across all screens.
Real quick I want to touch on another topic that could be its own post, or series of posts. Cutting out the android resources from a reference file or artwork, is much different than doing so for iOS. In iOS you can assign the background image, and then place views according to the image. In Android you can not do this, due to everything mentioned above (differing resolutions, ratios, and sizes). Each Icon will need to be cut out on its own. If you look at the reference image, and can pick out separate parts of the image, like a green textured bar here, or a special background behind  a certain item, those images will need to be cut separately. Views in Android are placed relative to other content, not relative to the resolution, ratio, or size of the screen. As such each piece of content needs its own graphics.

Android Multi-Language support

Recently I’ve been adding the ability to code an app so it can be understood in different languages..

Let’s say for instance that we want to do a Hello World! app and be able to say hello in different languages.

First, you need to decide what languages you need to support (these may vary depending on the devices).

Then you create “values” folders for each of those languages within the res folder in your project.

To get an idea for what the folder suffix should be, check the Custom Locale app on your device.. for English, there are several options to choose from, and you can support each one with a different folder naming convention – en-GB for Great Britain English for instance, or en-US for United States English.  Be sure you change the underscore (if there is one) to a dash as the underscore won’t be recognized and your app won’t interpret properly.

Now within each values folder there should be a strings.xml file.  There is no special naming convention needed on the strings.xml file name itself.

all strings.xml should have something like the following specified at the top:

<?xml version=”1.0″ encoding=”utf-8″?>

<resources>

For our english value version for “Hello World!” we would put the following line:

<string name=”hello_world”>Hello World!</string>

For our spanish value version – it would be something like this:

<string name=”hello_world”>¡Hola Mundo!</string>

and close your strings.xml file with

</resources>

Note that the string name is the same for both languages “hello_world”.  this is the value that we will reference later on in the code.

Now within your layout xml, or in a src java file,  you can reference the string by @string/hello_world or getResources().getString(R.string.hello_world).

At runtime your app will know based on your device Locale which language to choose from.

Smart Phone Apps for Medical Tests

I have recently had the opportunity to work for Joel Ehrenkranz and the i-calQ team, developing and engineering the proto-type software of their android apps that diagnose and measure hemoglobin and TSH content. It was a thrilling experience. This kind of cutting edge technology, software, and ideas, could help lead a revolution of easy access to cheap and effective means of medical help. People may be wary of it at first, but this is certainly the way of the future. The app works effectively and accurately, taking images of your blood, and measuring certain aspects to give you the results immediately. The ways this kind of technology could be useful is uncountable, and immeasurable. From children in Africa, to families in China and India, to the American on their morning commute in the subway, this mobile technology could help millions, if not billions of people manage their health.

KSL recently did a spot on it,

http://www.ksl.com/index.php?sid=27584140&nid=148&title=utah-physician-invents-disease-diagnosing-smartphone-app

in which they too can see the impact potential of this technology.

RECENT POSTS

  • Android – Simple Tips – Bitmap Memory Leaks

    The Problem Java uses garbage collection to manage memory. This does not mean that memory leaks never happen. They do. Bitmaps are one area where memory leaks can occur when creating and Android application. What Android Developers Has To Say “On Android Android 2.2 (API level 8) and lower, when garbage collection occurs, your app’s

  • iPhone 5s and iOS 7 Review

    Not only one iPhone but two were released this past month and along with those phones came the iOS 7 update, the first major overhaul since the iPhone’s birth. I have heard many mixed reviews about the new iPhone as well and the update and I am here to write a few pros and cons

  • Easy Android XML changes for many controls

    Something that I found recently is the option to change any property of several controls in XML for an Android app (at the same time) using Eclipse. To do this, simply command click (or control click for windows users) the various objects (fields, widgets, layouts, images, etc) you would like to edit from the Graphical

  • The Mobile Explosion

    The mobile industry continues to grow exponentially.  Android, iOS, even Windows Phone, you name it, is experiencing rapid penetration worldwide.  With increased penetration comes ever-growing revenue for firms to capture.  Since 2010, global mobile app revenue has grown at a rate of over 107%.  This year’s revenues alone are expected to reach an unprecedented 25

  • Building a Mobile App

    Making an appealing and successful mobile application is often times much more difficult than people might expect. Making the application on a good budget (and sticking to it) is usually harder still. Many times people want their apps made, but don’t have a full understanding of the process, or where common snags will cut into

1

1