Screen Geometry Fun

The recent announcement of the Samsung Galaxy Tab should be a wake-up call for Android developers. What’s scary is that we’ve never seen a screen like this on an Android device before. What’s reassuring is that most apps Just Work (in fact, a lot of the ones I’ve tried so far have looked terrific) and the potential problems are easy to avoid. Here’s what you need to do to take advantage of not just the Tab, but all the new form factors that are coming down the pipe.

Let’s consider the Tab as a “teachable moment”:

• Its screen is 1024x600; no compatible device’s screen has ever had a thousand pixels in any dimension before.

• A lot of people are going to want to hold it sideways, in “landscape” mode, most of the time.

We recommend spending quality time with the Developers’-guide discussion of supporting multiple screens; we'll be revising that regularly when required as the device landscape changes. Also, this blog recently ran Dan Morrill’s One Screen Turn Deserves Another, which should help out in handling the landscape default.

What density means

When you build your app, you can provide layouts and assets (graphics) which vary by screen density, screen size, and landscape or portrait orientation. Clearly, pulling these together is not as much fun as designing groovy layouts and clever Intent filters; but there’s no way around it.

In this context, the Samsung has another little surprise: If you do the arithmetic, its screen has 170 DPI, which is far from the densest among Android devices. Still, it declares itself as “hdpi” (and as having a “large” screen size). The reason is simple: It looks better that way.

Samsung found that if you rendered your graphical resources bit-for-bit using medium-density sources, they looked great, but most large-screen designs ended up looking sparse, with too much space between buttons and icons. At high resolution, the framework scales up the resources an amount that turns out to be just enough.

As a photography hobbyist, I’m reminded of how you juggle aperture and shutter speed and ISO sensitivity. If, for example, you want a fast shutter speed to capture a dancer in mid-leap, you’d better compensate with a wider aperture or more sensitivity. Similarly, the Galaxy Tab’s screen is at the large end of “large”, so declaring it as high-density applies a useful compensation.

The good news is that the scaling code in the framework is smart enough and fast enough that it comes out well; the graphics in my own apps look remarkably good on the Tab. Here is the front page of my “LifeSaver 2” app; first the Nexus One, then the Galaxy Tab, resized for presentation here. Different densities, different geometries, and the only important difference is that the version on the big screen looks prettier.

Your take-away should be what I said above: Make sure you provide your graphics at all three resolutions, and chances are the Android framework will find a way to make them look great on a huge variety of devices.

Other Ways To Go Wrong

As I noted, most apps work just fine on this kind of device, out of the box, no changes required. However, we have run across a few Worst Practices that can make your app look dorky or even broken; for example:

• Using AbsoluteLayout; this is a recipe for trouble.

• Using absolute rather than density-independent pixels.

• One member of my group ran across a couple of apps that suffered a Null Pointer Exception because they were calculating screen size when their Activity started, and doing their own resource loading rather than letting the framework take care of it. The problem was that they hadn't built in handling for the 1024x600 screen. The problem would vanish if they'd hand the work to the framework (or at least make sure that all their switch statements had default cases).

Escape the Shoebox

I've observed that a certain number of applications appear “shoeboxed”, running in a handset-like number of pixels in the center of the screen, surrounded by a wide black band. They work fine, but this is silly, and easy to avoid. It turns out that this happens when you have a targetSdkVersion value less than four; this is interpreted to mean that you’re targeting the legacy Cupcake flavor of Android, which only supported HVGA.

In any case, if you want to make 100% sure that your app doesn’t get pushed into the shoebox, the supports-screens element is your friend; here’s what we recommend:

(Both those attributes default to "false" for API levels less than 4.) Given a chance, the framework gets a good result on almost any Android screen imaginable.

Testing

When a device comes along that’s different in one way or another from what’s been available before, and you don’t have one, the only way to be sure your app will treat it properly is to run it on an Android emulator; the emulator code is flexible enough to model anything we’ve seen or know is coming down the pipe.

In the case of the Galaxy Tab, Samsung will be providing an add-on including a custom AVD and skin as an SDK add-on, to make your life easier; I used a pre-release to make the LifeSaver screenshot above.

Why All the Extra Work?

Because, as 2010 winds down, Android isn’t just for phones, and isn’t just for things that fit in your pocket. The minor effort required to deal with this should pay off big-time in terms of giving your apps access to a universe of new kinds of devices.