Handling Multiple Screen Sizes, Part Four

This is the first part of a several part series on handling multiple screen sizes in your Android projects. This material is adapted from a chapter in The Busy Coder’s Guide to Android Development, Version 3.0.

The Android emulators will help you test your application on different screen sizes, to exercise the support you added based on the previous blog posts in this series. However, that will only get you so far, because mobile device LCDs have different characteristics than your desktop or notebook, such as:

• Mobile device LCDs may have a much higher density than does your development machine
• A mouse allows for much more precise “touchscreen” input than does an actual fingertip

Where possible, you are going to need to either use the emulator in new and exciting ways, or try to get your hands on actual devices with alternative screen resolutions.

Density Differs

The Motorola DROID has a 240dpi, 3.7-inch, 480×854 pixel screen.

To emulate a DROID screen, based on pixel count, takes up one third of a 19″ 1280×1024 LCD monitor, because the LCD monitor’s density is much lower than that of the DROID – around 96dpi. So, when you fire up your Android emulator for an FWVGA display like that of the DROID, you will get a massive emulator window.

This is still perfectly fine for determining the overall look of your application in an FWVGA environment. Regardless of density, widgets will still align the same, sizes will have the same relationships (e.g., Widget A might be twice as tall as Widget B, and that will be true regardless of density), and so on.

However:

• Things that might appear to be a suitable size when viewed on a 19″ LCD may be entirely too small on a mobile device screen of the same resolution
• Things that you can easily click upon in the emulator with a mouse may be much too small to pick out on a physically smaller and denser screen when used with a finger

Adjusting the Density

By default, the emulator will keep the pixel count accurate at the expense of density, which is why you get the really big emulator window. You do have an option, though, of having the emulator keep the density accurate at the expense of pixel count.

The easiest way to do this is to use the new Android AVD Manager, introduced in Android 1.6. The Android 2.0 edition of this tool has a “Launch Options” dialog that pops up when you go to start an emulator instance via the Start… button:

By default, the “Scale display to real size” checkbox is unchecked, and Android will open the emulator window normally. You can, however, check that checkbox and then provide two bits of scaling information:

1. The screen size of the device you wish to emulate, in inches (e.g., 3.7 inches for the Motorola DROID)
2. The dpi of your monitor – click the ? button to bring up a calculator to help you determine what your dpi value is

This will give you an emulator window that more accurately depicts what your user interface will look like on a physical device, at least in terms of sizes. However, since the emulator is using far fewer pixels than will a device, fonts may be difficult to read, images may be blocky, etc.

Accessing Actual Devices

Of course, the best possible way to see what your application looks like on different devices is to actually test it on different devices. You do not necessarily have to get every Android device ever made, but you may want to have access to ones with distinctive hardware that impacts your application…and screen size impacts just about everyone.

You can virtually test devices using services like DeviceAnywhere. This is an improvement over the emulator, but it is not free and certainly cannot test everything (e.g., changes in location).

You can purchase devices, perhaps through back channels like eBay. Unlocked GSM phones can readily share a SIM when you need to test telephony operations or go SIM-less otherwise.

If you live in or near a city, it may be you can set up some form of user group and use that group for testing applications on your collective set of hardware.

You can also always take the user-testing route, releasing your application as a free beta or something, then letting user feedback guide adjustments. You may wish to distribute this outside of the Android Market, lest beta test feedback harm your application’s market rating.

In tomorrow’s final post in the series, we will look at ways you might take proactive advantage of larger screens, rather than merely reacting by drawing the same UI bigger.