Android Tablet Design

Android devices come in many shapes and sizes. Designing applications to run flawlessly, regardless of the device characteristics, is as much an art as a science. Tablet development involves some special considerations. Designing for tablets is not the same as designing for phones, but there are many similarities. In this tutorial, learn development techniques for designing applications that work well on tablets, many of which can be applied to other types of devices as well.

We’re currently experiencing a “tablet boom”—check out any electronics shop and you’ll find dozens of Android tablets for sale. These tablets range from low-end devices with screens no larger than a typical phone running ancient versions of the Android SDK (i.e. Android 1.6) to fancy e-book readers and highly anticipated devices like the Motorola Xoom. But despite the plethora of Android tablets available today, only two large screened tablets ship with official Android Market and the host of Google services: the Samsung Galaxy tab and the Motorola Xoom. As such, we’ll use these popular devices as examples, but the advice in this tutorial applies to most properly-configured (by the manufacturer) tablets.

How Honeycomb Fits In

The Android SDK 3.0 (Honeycomb) release focused heavily on bringing previously-nonexistent tablet features to the Android development community. However, these features are likely to be merged with existing phone features sooner rather than later; it is not expected that these technologies (phone vs. tablet) will go off in different directions.
With the release of Honeycomb, complete with tablet-friendly optimizations and UI features, many more tablets are sure to appear on the market. Already this quarter, dozens of upcoming devices have been announced at the various mobile and electronic conferences.

Some of the techniques we’ll discuss require the new Android 3.0 SDK, although these same features are likely to find their way to older devices as the Android team makes them available via a backwards-compatible shared library and builds them into future SDKs made available to all devices. Other techniques discussed can be used with any version of the Android SDK.

A Common User Interface Design Paradigm for Tablets

Most existing applications were not designed with the large, high resolution screens in mind. Phone applications are generally design to show a minimum of information on the screen to keep the user interface easy to read and navigate. Tablet screens have a lot more real estate available. When your traditional phone app is scaled to a large screen device, this design works but often leads to a very sparse look. Figure 1 shows a screenshot of Google Reader, which hasn’t been updated just yet.

Compare that to Pulse, which has a nice dual-pane design that takes advantage of the screen space available on the tablet user interface to show more information, while keeping the visual appeal and simplicity of a lightweight handheld device.

This design pattern is repeated in many applications for tablets. One way to implement this type of design pattern is to have a ListView on left side of the screen and a details view of some sort on the right. The details view could be a WebView, an ImageSwitcher, or any other sort of view where you can dynamically update the content.

Leveraging Alternative Resources for Tablets

The layout design on a tablet is important, but it’s not the only design decision to consider. Size and resolution of resources, font sizes, button sizes, and other aspects are equally important factors in good UI design for tablets.

Android has a great system for dynamically loading resources based on a long list of device criteria. These criteria are qualifiers listed as part of the resource directories. You may already be familiar with the ldpi, mdpi, and hdpi resolution qualifiers as the default Eclipse Android New Project wizard creates these for the icon graphics. However, there are many others. When it comes to tablet design, you’ll want to create resources and use qualifiers such that they look great on the tablet–frequently larger, higher resolution drawables, larger dimensions and the like.

Let’s look at an example. The Xoom is an extra large, medium density screen while the Galaxy tab is a large, high density screen. Most phones, though, have normal size medium or high density displays.

A layout for the full-sized tablet would exist in a directory named layout-xlarge-mdpi while a layout for a handheld tablet would exist in a directory named layout-large-hdpi. For instance, this screen shot shows the two tablet specific directories and the layout designer showing what the xlarge-mdpi layout looks like.

Using just these two qualifiers will, currently, cleanly separate the resources used by the Galaxy Tab and the Motorola Xoom not only from each other, but also from most available phones. This technique alone can be used to develop a custom look-and-feel for your application on these devices. Use it to provide different layouts, different graphic or dimension resources for different devices your app wants to support.

Let’s talk a bit more about graphics and dimensions. On a tablet, you’ll usually want images to be larger, in pixels. On the other hand, interface elements like buttons you’ll want to be large enough, but not too large. The pixel dimensions could even end up being smaller than on a smaller screen.

When creating resources (and especially layouts) keep in mind that they’ll be loaded within the same activities that they originally were. Creating vastly different user interfaces on different screens will lead to more code paths and testing requirements.

Some other useful resource qualifiers for handling screens:

• Orientation: port, land — Loads resources based on portrait mode versus landscape mode.
• Aspect ratio: long, notlong — Loads resources different based on a screen being a wide screen or a standard width screen. The current tablets and high resolution phones are all wide screen, so this has limited use currently.
• Docks: car, desk — Loads different resources if the device is in a dock of some sort.
• System version: v8, v9, v11, etc. — Loads different resources based on the SDK version.

There are many other resource qualifiers available. See the Android documentation for more information on them.

Fragments: Designing for Tablets andPhones Simultaneously

We’ve gone over various design considerations specific to tablets. Android, however, has a good system in place for creating one application that will run on nearly all types of devices. One of the primary means to implement this is using the resource qualifiers already discussed.

Android 3.0, however, introduced a new means of supporting user interface variances between different types of screens. This new mechanism is called Fragments, which might be best described as sub-activities. Fragments are independent of any specific Activity class, yet a specific instance of a Fragment must exist within an Activity.One of the most common examples of using Fragments is to implement the classic List-beside-detail UI pattern we discussed earlier. When implementing this with Fragments, there’s a little bit more configuration up front, but the end result is more maintainable application with less code. Basically, to use Fragments in this instance, you would turn the left-hand ListView and the right-hand details view into Fragments. You would then detect the type of screen you’re on and either show one fragment next to the other within the same Activity or show the detail fragment in a second activity (screen) that only comes into play when they aren’t on the same screen. The code for handling the interaction between the two is the same.

There’s a big caveat here, though: Fragments are currently only available in Android 3.0. This means to design using Fragments and run on older versions you’d need to jump through a bunch of coding hoops. Google, however, has stated that they are working on creating a static library to provide the Fragment API to Android SDK versions as old as 1.6. When this happens, we’ll all benefit from being able to use Fragments on just about every existing Android device. Until then, you can either follow multiple code paths — and maybe even multiple binaries — or design for the new API now and hope that this library does surface sooner than later.

Manifest Changes Required To Support Tablets

Tablet considerations are not just confined to user interface concerns. The Android Manifest file should be updated to explicitly list what features your newly modified application supports, including tablet-specific features. Amongst the manifest file settings available are settings like the supports-screens tag to show that you support both large and xlarge devices. To use the xlargeScreens setting, you’ll need to be compiling with API Level 9 or higher.

Other tags to properly set are:

• <uses-configuration>
• <uses-feature>
• <uses-permission>

Properly configuring your manifest file is critical to reduce the number of users that may end up with your application on a device that you don’t support, and ensuring that those user’s devices you do support can install your application.

Testing Tablet Applications

Now that you’ve spent time developing a great looking tablet application, you’ll need to test it. The absolute best way to test it is on the target devices themselves. If you’re at a company, this is pretty much a given. If you’re on your own, you might have to get a little creative. Buy, borrow, or beg for a Galaxy tab, a Motorola Xoom, and a few target phone devices as well. Consider providing the application to friends to test as well.

Regardless of how you do it, the only sure way to validate that your application looks and behaves as expected is to install it on the target devices. That said, the emulator can suffice for early development and testing. Its performance isn’t as good as the real devices, but the results can be useful in the early stages of your project. See our tutorial on Android Tablet Virtual Device Configurations right here on Mobiletuts+ to learn how to create AVD instances that come very close to mimicking how tablets look and behave.

Keeping Application Package Sizes Under Control

On high resolution devices, resources like high-res graphics bulk up the APK file quickly. If you’re providing separate resources for normal-hdpi, large-hdpi, and xlarge-mdpi you may find your package size getting out of control very quickly.
Although there is no limit to package sizes, the Android Market has a limit of just 50MB for a final APK file. This may seem like a lot, but on a competing tablet platform, I have about three dozen popular applications installed that easily exceed this size.

One solution to this problem is to provide a minimal set of resources for launching the application and then download the rest of the image graphics specific to the device from an application server. This method has multiple benefits:

1. Images can be updated without updating the application.
2. New target devices can be added without updating the application.
3. The initial download and installation on all devices will be much faster.
4. Users won’t complain about large package size wasting space on their device.

These extra application assets could be hosted on the same servers that run your service, or they could be hosted through a cloud file hosting service, such as Amazon S3.

Games such as the popular Gun Bros from Glu Mobile take this approach. On the Motorola Xoom, the first run of the game downloads a file of well over 100MB while the market download size is just over a megabyte. Here’s a screen shot of Gun Bros initial prompt to download resources.

Conclusion

You’ve now learned about some of the tips and tricks for designing Android applications for tablets, from designing user interfaces that use the generous screen space more efficiently to using new features of Android 3.0 SDK to have custom yet dynamic layouts for different types of devices. You’ve also got some new ideas to consider when it comes to managing application sizes and testing tablet apps.