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:
<supports-screens android:largeScreens="true" android:anyDensity="true" />
(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.
--
Salam,
Agus Hamonangan
http://groups.google.com/group/id-android
http://groups.google.com/group/id-gtug
Gtalk : id.android
Follow : @agushamonangan
E-mail : id.android@gmail.com
--
"Indonesian Android Community [id-android]"
Join: http://groups.google.com/group/id-android/subscribe?hl=en-GB
Moderator: id.android@gmail.com
Peraturan Jual dan Kloteran ID-Android http://goo.gl/azW7
ID Android Developer: http://groups.google.com/group/id-android-dev
ID Android Surabaya: http://groups.google.com/group/id-android-sby
ID Android on FB: http://www.facebook.com/group.php?gid=112207700729
No comments:
Post a Comment