- Planning Ahead
- Managing Your Resources
- The Developer's Perspective on Tablets
- New Devices Mean New Audiences
- Publishing Tablet-Friendly Apps
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Developer's Perspective on Tablets
From a developer's perspective, tablets can be considered just another device, provided that you haven't made any unfortunate development assumptions, such as the ability to make and receive phone calls. With the addition of these extra features, tablets begin to diverge from what developers may have come to expect—despite the fact that such features haven't been required historically.
Tablets are not smartphones. What does this mean to you? If your applications include phone features, you'll have to provide graceful alterative features for any device (likely a tablet, but could be a toaster) that doesn't have phone features. If your application requires phone features, flag it as required in the Android manifest file. Or make it a conditional feature, flag it as optional, and document that your app will have a limited feature set on tablets (or bonus features on smartphones). Quality assurance testers need to be aware of this distinction, so that they might spend less time testing lifecycle interrupts (incoming phone calls being the most common culprit) and more time on common tablet issues, such as frequent screen-orientation changes.
Tablets don't require a special Android SDK. The Android 3.0 SDK introduced some tablet-friendly features, such as the Fragments APIs, but the compatibility library can be used to provide Fragments support as far back as Android 1.6, and this technology certainly isn't limited to tablets.
Some of the most exciting new tablets have special APIs for accessing special device features. As a developer, you must decide whether you want to take advantage of these features, or stick with a generic tablet solution. Manufacturer add-ons are managed much like Android SDK versions, using the Android SDK and AVD Manager. Be sure to read the fine print on the licensing terms for these third-party add-ons, as they may differ from the Android SDK license agreement.
Design your application to use Fragments from the start. As of this writing, only one Android 3.0 device is available on the market, but the Fragment API was available as far back as Android 1.6, using a compatibility library provided by Google. Regardless of whether you're developing for tablets, Fragments help to separate user-interface functionality from application logic. Using Fragments from the start greatly simplifies any later shuffling of the user interface, speeds up development of tablet-centric user interfaces, and makes your app ready for any new classes of devices that hit the market in the future.
Gaming the System
Let's take a minute to look at an application category that can pose specific challenges for tablet development: games. Because today's games use a lot of custom UI, are fully 3D, and naturally scale by virtue of their rendering systems, they may be the application most prepared for the switch to tablets.
However, games aren't immune to problems, especially when a game has been designed for a handheld device. Here's a simple example: Suppose you have a great game that is normally played while held in landscape mode, using side thumb controls. On a typical Android smartphone, players can reach most of the screen with their thumbs. However, on a tablet, 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 also cannot be held or cradled as easily as a phone can.