10. Best Practices for Tablet and Google TV Development
The Android platform may have started as a smartphone platform, but it has quickly moved into other device form factors. Android tablets and eBook readers such as the Amazon Kindle Fire have been especially popular lately. At the same time, Google released its Google TV, a highly interactive and connected television experience that runs on Android. Designing and developing for these different types of devices involves maximizing where the devices are similar, and handling the differences as necessary. In this chapter, we talk about some of the best practices for developing for different types of devices such as tablets and Google TV.
Understanding Device Diversity
These new types of Android devices do not require a special Android SDK; they use the same SDKs that the other Android devices use. Many application developers want to publish their applications to as many users (and therefore devices) as possible. This was relatively straightforward when Android was almost exclusively a smartphone platform. Developers can assume that the device screen size is within a certain reasonably small range. They can assume the device had telephony features, a camera, a numeric keypad, and the like.
These days, with the Android platform making its way onto tablets, TVs, toasters, eBook readers, net books, watches, and even car rearview mirrors (no joke: http://goo.gl/lUhuh) application developers cannot make these assumptions, which brings us to our first tip.
Don’t Make Assumptions about Device Characteristics
Don’t make assumptions about the device your application runs on, because tomorrow (or the day after), there will be yet another new type of Android device that users are trying to download your app onto that breaks your assumptions. Instead, ensure that your application runs smoothly by configuring your application’s Android manifest file appropriately to reflect what your application does and does not need to run correctly. Does it require a certain version of the Android SDK? If so, specify it. Does the application require a camera or telephony features? Declare those features using the <uses-feature> tag. Do you want your application to display correctly on a variety of device screens, whether they are large or small, portrait or landscape, high definition, or otherwise? Start by using flexible user interface design that can attempt to smooth over and accommodate the differences between devices.
Designing Flexible User Interfaces
Regardless of what devices your application targets, there’s no substitute for good application design. In many ways, all Android devices are created equal—they use the same operating system, the same SDKs, the same platform targets, the same tools for development. Designing for all device sizes, shapes, and form factors enables your application to look, behave, and run smoothly across the widest range of devices, regardless of type. Here are some things to consider with any Android project:
• Use flexible layout designs and controls such as RelativeLayout.
• Use dimension values such as dp instead of px to enable better scaling and support of multiple screen attributes with less work.
• Make your graphics stretchable using graphic formats (nine-patch, XML-defined drawables) where possible.
• Provide alternative resources for various screen sizes and densities.
• Don’t limit alternative resources to just images and layouts. Styles and values also make great alternate resources; they can sometimes be effective enough to reduce the need for some layouts.
• Adjust your user interface when hardware features aren’t available. For instance, instead of requiring a camera, make it optional and present only that option when the camera is available. If it’s not available, present an option to pick an image from the gallery instead. Perhaps the user has a device with a camera that is syncing to the gallery on the device without the camera.
• Be aware that not all devices have touch screens and that keyboards are a primary input mechanism on many devices, including Google TV, tablets and phones with docks, and so on. Even the mouse gets used on several popular devices. Handle the Enter key and arrow keys appropriately.
• Use a Fragment-based application design from the start, as this new technology is supported in both smartphones and tablets and makes for flexible screen workflows and more code reuse.
Following these guidelines enables your application to display and function well on a variety of different devices. However, when working with devices that are often substantially larger that smartphones, scaling gracefully is not usually enough; you need to provide alternative resources for different resolutions and orientations.
Attracting New Types of Users
When you add new types of devices, different types of users buy them. This expands the user base—a good thing for developers who make a living from downloads. The audience for smartphones is different from that of tablets and TVs and other devices such as eBook readers. The Kindle Fire is a great example of a device that introduced many new people to the Android platform—many without even knowing the device runs Android. Understanding these new audiences can have an impact on your application design and development process.
Tablets can be used by individuals with special needs who are incapable of using smaller smartphones. This is especially true of the visually impaired, but certainly not limited to this crowd. Leverage the accessibility APIs available in the Android SDK to make your application as accessible as possible to these audiences, regardless of your device targets. The same design principles hold true for another audience—very young users—who generally require larger button controls, high contrast colorations, and other such design features. Televisions are used by the whole family, not just the tech-savvy users or those who can afford (or are old enough to have) smartphones.
Tablets aren’t phones and can sometimes be purchased outright without a wireless data plan for use on Wi-Fi networks. This enables new classes of Android users—those who live outside the current wireless coverage maps of the world. This makes localization even more important for applications that support tablets.
Leveraging Alternative Resources
You can achieve a lot by simply using alternative resources. The Android SDK enables you to supply project resources such as graphics and layout designs for different target device characteristics such as screen sizes, resolutions, orientations, and other device features. Used well, each class of device can have its own distinct look and feel while the underlying code remains unchanged. For more information on alternative resources, see the Android SDK documentation at http://d.android.com/guide/topics/resources/providing-resources.html#AlternativeResources (http://goo.gl/1YTdc).
Using Screen Space Effectively on Big Landscape Screens
Most tablets and televisions have screens that are seven inches or larger. In terms of resources, tablets are usually defined as having large or extra large screens. A large screen is defined as 5 inches to around 7 inches and extra large as 7–10 inches. There is some overlap in the definition and the one a device uses is manufacturer-dependent. When using the resource qualifier, you’re looking at the large and xlarge values. Although xlarge was introduced at API Level 9, it will be quietly ignored on earlier devices.
Tablets are most frequently held and used in landscape mode and televisions are exclusively used in landscape mode. Although supporting both orientations is ideal, if you’re going to focus on only one orientation for a tablets and televisions, we recommend landscape mode. Keep in mind that you can use alternative resources to design a landscape layout that differs substantially from the portrait layout. You’ll want to consider different layouts using the port and land qualifiers.
Just scaling graphics up for these big screens is often not enough. Take, for example, a smartphone layout that has four buttons across, sized so even big fingers will have no trouble tapping them. Enlarge that to a 10-inch tablet screen—which might be over 8 inches wide—and you now have buttons on the order of 2 inches wide. That might work for a toddler-friendly interface, but for most people, those big buttons will look silly—and on television interfaces without touch screens, a complete waste of space. Reduce the size of the buttons and find something else useful to put in the newly gained space.
One kind of application that may pose special challenges when it comes to design is games. Today’s games use a lot of custom user interface, are fully 3D, and naturally scale by virtue of their rendering systems. These apps can transition easily to tablets and other larger devices, but they are not immune to problems—especially when a game has been designed as a “handheld” game.
Let’s look at a simple example. You have a great game that is normally played while held in landscape mode with side thumb controls. On a typical Android smartphone, this generally means that the player can reach most of the screen with his thumbs. However, on a tablet, your thumbs only go so far. Entire areas of the screen are unreachable using thumb controls; if the user is required to tap in the middle of the screen, the tablet cannot be “held” or “cradled” as easily either.
Going even farther, on a Google TV, there is no touch screen. If you can, implement alternative controls with a keyboard or mouse. If you can’t, possibly look into using another device, such as a phone, which you can use as a controller connected via Wi-Fi to the Google TV. Keep in mind, though, that if a touch screen is used as a controller and the user isn’t looking at it, he’ll need some sort of cues about what buttons he’s pressing. Another option is to use one of the many wireless controllers that can hook up directly to the device and be used as an alternative input method.
Developing Applications for Tablets
Some say that 2011 was the year of the tablet (see Figure 10.1), the year they went mainstream (the way was paved by the success of the iPad—thanks Apple!). Samsung, Motorola, ASUS, HTC, ARCHOS, and many others shipped some fantastic tablet devices in various sizes and orientations. Amazon shipped the Kindle Fire to great fanfare. This new niche poses new challenges for Android developers creating apps, so let’s look at what it means to design, develop, test, and publish Android applications for tablet devices.
Figure 10.1. Tablets everywhere! (Google image search result.)
• From a developer perspective, tablets can be considered just another device, provided you haven’t made any unfortunate development assumptions.
• Tablets run different versions of the Android platform, as far back as Android 1.0, although official tablet support by Google did not occur until Android 3.0.
• Tablets are not smartphones. This means that if your applications include telephony features, you will have to provide graceful alterative features for devices without these features, or effectively exclude these devices through Android Manifest file configuration.
• Unlike smartphones, most tablets default to landscape, not portrait mode. Tablet users are more likely to change orientations than smartphone users.
• Tablets tend to have fewer hardware sensors than high-end smartphones.
• Fragments help separate user interface functionality from application logic. Using the Fragment class from the start greatly simplifies any shuffling of the user interface later on, speeds up development of tablet-centric user interfaces, and makes your app ready for the Android devices of the future.
• The Android Market has no specific way to target or disable publication to specific types of devices such as tablets. You can, of course, use market filters to restrict your application to users with devices of certain screen sizes, libraries, and other device features, but there is no tablet “flag,” per se.
We do not recommend naming your app for its device target (for example, “The ACME App for Tablets”).
Developing Applications for Google TV
Google announced a new platform initiative in early 2010—Google TV. The vision: a highly interactive and connected television experience leveraging the Android platform. Google wasn’t going to do it alone, but partner with some of the top manufacturers in the television and set-top box business, including Sony (see Figure 10.2), Vizio, LG, Samsung, and others.
Figure 10.2. Google TV devices are often set-top boxes. This one, from Sony, was announced at CES 2012.
Just as smartphones put apps in your pocket, Google TV brings them to your living room. The sky’s the limit when it comes to the types of apps and content you might want to provide to Google TV users. Let’s talk for a moment about what types of applications are suitable for Google TV users.
There are two ways to bring your applications to Google TV devices: Chrome web apps and native Android apps. The Google TV website lists all supported Google TV devices you can purchase at http://www.google.com/tv/get.html. You have the option of purchasing a complete package (TV screen and all) or a set-top box that works with existing HDTV systems.
Suitability may be less of an issue for web-based applications. However, many Android applications rely upon hardware assumptions that are not applicable to Google TV users, including the existence of cameras, location-based services, sensors, telephony, and such. In terms of user interface design, you don’t have to worry so much about state changes like orientation changes or frequent network drops because your user is always connected. Therefore, only certain classes of existing Android applications are appropriate for the Google TV platform. Only you, the developer, can determine whether your app is suitable. There’s nothing stopping you from developing interesting apps that fuse the power of existing smartphones and tablets (that have cameras, hardware sensors, and such) with the power of Google TVs.
Optimizing Web Applications for Google TV
Your existing website and web applications, including those using HTML5 and Flash, can target the Google TV. At this time, Google TVs run Chrome and support Adobe Flash. Optimizing your websites for display on a high definition television screen involves many common sense tweaks. You’ll hear a lot of Google TV developers talk about “the 10-foot experience.” This simply acknowledges the fact that Google TV users sit at some distance from the screen, and developers need to adjust their application’s user experience to suit this typical use case.
Screen designs should be simple and elegant, using extra-large, readable fonts, and graphics. There’s quite a bit more wide-screen real estate to work with, but scrolling is less appealing and navigation, typically by D-pad, should be simple and straightforward. Some color schemes need to be adjusted for the high contrast and saturation levels typical of televisions. Finally, you’ll want to come up with a high-resolution favicon so that your website looks slick in the Chrome bookmarks and other references.
When it comes to Flash, you’ll want to check out Adobe’s recommendations for optimizing Flash apps for televisions.
Developing Native Android Applications for Google TV
Native Google TV apps are written using the Android SDK and can be published through the Android Market. At this time, Google TVs are running the Honeycomb SDK (Android 3.1) and must be developed using the latest Android tools and the GoogleTV add-on from the Android SDK Manager.
Developing native applications for Google TV is basically like developing for a large tablet without a touch screen, camera, and so on. Most of the challenges of porting an Android app to Google TV revolve around:
• Setting the appropriate manifest file settings to allow for, market filter for, and not accidentally exclude Google TV devices.
• Using appropriate alternative resources for large, high-definition television displays (at 10 feet).
• Avoiding certain methods and API calls that assume telephony device features.
• Adjusting user interface controls to be large and readable for television viewing.
• Adjusting layout navigation to support D-pad as the primary input. Add handling for the media keys for play, pause, and so on. Consider fast ways to get out of long lists; don’t make a user traverse a long list just to get to a button at the bottom of the screen.
• Avoid using methods and APIs that assume telephony device features and other features unsupported by the Google TV, such as the Android NDK. For more information, see the Google TV documentation for feature support at https://developers.google.com/tv/android/docs/gtv_android_features.
Once you have installed the Google TV add-on, you can use it to create compatible AVDs to run in the Google TV Emulator. Find out more in the Google TV Emulator documentation at https://developers.google.com/tv/android/docs/gtv_emulator.
Developing Apps for the Amazon Kindle Fire
The Amazon Kindle Fire, shown in Figure 10.3, is another type of new Android device in the hands of today’s users. Although the device itself is simply a basic tablet, it runs a modified version of the Android platform that centers around the Amazon Appstore, instead of the Google experience many users associate with the platform—and there is no Android Market. The home screen is customized and, as such, doesn’t present such opportunities as app widgets or live wallpapers. To learn more about app development for the Amazon Kindle Fire, check out the Amazon Appstore Developer Portal at https://developer.amazon.com/welcome.html or check out our book, Learning Android Application Programming for the Kindle Fire (Addison-Wesley, August 2012, ISBN 9780321833976).
Figure 10.3. The Amazon Kindle Fire, a 7-inch Android device with Amazon Appstore and a custom home screen.
Summary
Tablets, Google TVs, and other new types of devices that run mobile operating systems are a new and popular category of Android device. As you have learned, designing and developing for these new niche devices is fairly simple when you keep your assumptions about device characteristics at a minimum and specify which device features and permissions your application requires in the Android manifest file. With planning, careful use of resources, and good development techniques, supporting these exciting new devices need not be a trial.
References and More Information
Android Dev Guide: “Supporting Tablets and Handsets”:
http://d.android.com/guide/practices/tablets-and-handsets.html
Google TV Developers website:
https://developers.google.com/tv/
Google TV Web Developer’s Guide:
https://developers.google.com/tv/web/
Google TV Native Android Application Developer’s Guide: