Update News

***TOP NEWS * How to delete google search? Give the offer GOOGLE

Monday, 16 March 2015

Building TV Apps

Building TV Apps

GET STARTED

DEPENDENCIES AND PREREQUISITES

  • Android 5.0 (API level 21) or higher
  • Android Studio 0.8 or later and Gradle 0.12 or later
Android offers a rich user experience that's optimized for apps running on large screen devices, such as high-definition televisions. Apps on TV offer new opportunities to delight your users from the comfort of their couch.
TV apps use the same structure as those for phones and tablets. This approach means you can create new TV apps based on what you already know about building apps for Android, or extend your existing apps to also run on TV devices. However, the user interaction model for TV is substantially different from phone and tablet devices. In order to make your app successful on TV devices, you must design new layouts that can be easily understood from 10 feet away, and provide navigation that works with just a directional pad and a select button.
This class describes how to start building apps for TV, including setting up your development environment, basic requirements for layouts and navigation, as well as guidance on how to handle hardware features that are not typically available on TV devices.
Note: You are encouraged to use Android Studio for building TV apps, because it provides project setup, library inclusion, and packaging conveniences. This training assumes you are using Android Studio.

Lessons

Getting Started with TV Apps
Learn how to create a new Android Studio project for TV apps or modify your existing app project to run on TV devices.
Building TV Layouts
Learn the minimum requirements for TV layouts and how to implement them.
Creating TV Navigation
Learn the requirements for TV navigation and how to implement TV-compatible navigation.
Handling TV Hardware
Learn how to check if your app is running on TV hardware, handle unsupported hardware features, and manage controller devices.

Get Started with TV Apps

PREVIOUSNEXT
TV apps use the same structure as those for phones and tablets. This similarity means you can modify your existing apps to also run on TV devices or create new apps based on what you already know about building apps for Android.
Important: There are specific requirements your app must meet to qualify as an Android TV app on Google Play. For more information, see the requirements listed in TV App Quality.
This lesson describes how to prepare your development environment for building TV apps, and the minimum required changes to enable an app to run on TV devices.

Set up a TV Project

This section discusses how to modify an existing app to run on TV devices, or create a new one. These are the main components you must use to create an app that runs on TV devices:
  • Activity for TV (Required) - In your application manifest, declare an activity that is intended to run on TV devices.
  • TV Support Libraries (Optional) - There are several Support Libraries available for TV devices that provide widgets for building user interfaces.

Prerequisites

Before you begin building apps for TV, you must:

Declare a TV Activity

An application intended to run on TV devices must declare a launcher activity for TV in its manifest using aCATEGORY_LEANBACK_LAUNCHER intent filter. This filter identifies your app as being enabled for TV, and is required for your app to be considered a TV app in Google Play. Declaring this intent also identifies which activity in your app to launch when a user selects its icon on the TV home screen.
The following code snippet shows how to include this intent filter in your manifest:
<application
  android:banner="@drawable/banner" >
  ...
  <activity
    android:name="com.example.android.MainActivity"
    android:label="@string/app_name" >

    <intent-filter>
      <action android:name="android.intent.action.MAIN" />
      <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
  </activity>

  <activity
    android:name="com.example.android.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">

    <intent-filter>
      <action android:name="android.intent.action.MAIN" />
      <category android:name="android.intent.category.LEANBACK_LAUNCHER" />
    </intent-filter>

  </activity>
</application>
The second activity manifest entry in this example specifies that activity as the one to launch on a TV device.
Caution: If you do not include the CATEGORY_LEANBACK_LAUNCHER intent filter in your app, it is not visible to users running the Google Play store on TV devices. Also, if your app does not have this filter when you load it onto a TV device using developer tools, the app does not appear in the TV user interface.
If you are modifying an existing app for use on TV, your app should not use the same activity layout for TV that it does for phones and tablets. The user interface of your TV app (or TV portion of your existing app) should provide a simpler interface that can be easily navigated using a remote control from a couch. For guidelines on designing an app for TV, see the TV Design guide. For more information on the minimum implementation requirements for interface layouts on TV, see Building TV Layouts.

Declare Leanback support

Declare that your app uses the Leanback user interface required by Android TV. If you are developing an app that runs on mobile (phones, wearables, tablets, etc.) as well as Android TV, set the required attribute value to false. If you set the required attribute value to true, your app will run only on devices that use the Leanback UI.
<manifest>
    <uses-feature android:name="android.software.leanback"
        android:required="false" />
    ...</manifest>

Declare touchscreen not required

Applications that are intended to run on TV devices do not rely on touch screens for input. In order to make this clear, the manifest of your TV app must declare that a the android.hardware.touchscreen feature is not required. This setting identifies your app as being able to work on a TV device, and is required for your app to be considered a TV app in Google Play. The following code example shows how to include this manifest declaration:
<manifest>
    <uses-feature android:name="android.hardware.touchscreen"
              android:required="false" />
    ...</manifest>
Caution: You must declare that a touch screen is not required in your app manifest, as shown this example code, or your app cannot appear in the Google Play store on TV devices.
An application must provide a home screen banner for each localization if it includes a Leanback launcher intent filter. The banner is the app launch point that appears on the home screen in the apps and games rows. Desribe the banner in the manifest as follows:
<application
    ...
    android:banner="@drawable/banner" >

    ...</application>
Use the android:banner attribute with the <application> tag to supply a default banner for all application activities, or with the <activity> tag to supply a banner for a specific activity.
See Banners in the UI Patterns for TV design guide.

Add TV Support Libraries

The Android SDK includes support libraries that are intended for use with TV apps. These libraries provide APIs and user interface widgets for use on TV devices. The libraries are located in the<sdk>/extras/android/support/ directory. Here is a list of the libraries and their general purpose:
  • v17 leanback library - Provides user interface widgets for TV apps, particularly for apps that do media playback.
  • v7 recyclerview library - Provides classes for managing display of long lists in a memory efficient manner. Several classes in the v17 leanback library depend on the classes in this library.
  • v7 cardview library - Provides user interface widgets for displaying information cards, such as media item pictures and descriptions.
Note: You are not required to use these support libraries for your TV app. However, we strongly recommend using them, particularly for apps that provide a media catalog browsing interface.
If you decide to use the v17 leanback library for your app, you should note that it is dependent on the v4 support library. This means that apps that use the leanback support library should include all of these support libraries:
  • v4 support library
  • v7 recyclerview support library
  • v17 leanback support library
The v17 leanback library contains resources, which require you to take specific steps to include it in app projects. For instructions on importing a support library with resources, see Support Library Setup.

Build TV Apps

After you have completed the steps described above, it's time to start building apps for the big screen! Check out these additional topics to help you build your app for TV:
  • Building TV Playback Apps - TVs are built to entertain, so Android provides a set of user interface tools and widgets for building TV apps that play videos and music, and let users browse for the content they want.
  • Helping Users Find Your Content on TV - With all the content choices at users' fingertips, helping them find content they enjoy is almost as important as providing that content. This training discusses how to surface your content on TV devices.
  • Games for TV - TV devices are a great platform for games. See this topic for information on building great game experiences for TV.

Run TV Apps

Running your app is an important part of the development process. The AVD Manager in the Android SDK provides the device definitions that allow you to create virtual TV devices for running and testing your applications.
To create an virtual TV device:
  1. Start the AVD Manager. For more information, see the AVD Manager help.
  2. In the AVD Manager dialog, click the Device Definitions tab.
  3. Select one of the Android TV device definitions and click Create AVD.
  4. Select the emulator options and click OK to create the AVD.
    Note: For best performance of the TV emulator device, enable the Use Host GPU option and, where supported, use virtual device acceleration. For more information on hardware acceleration of the emulator, see Using the Emulator.
To test your application on the virtual TV device:
  1. Compile your TV application in your development environment.
  2. Run the application from your development environment and choose the TV virtual device as the target.
For more information about using emulators see, Using the Emulator. For more information on deploying apps from Android Studio to virtual devices, see Debugging with Android Studio. For more information about deploying apps to emulators from Eclipse with ADT, see 





Handling TV Hardware

PREVIOUSNEXT
TV hardware is substantially different from other Android devices. TVs do not include some of the hardware features found on other Android devices, such as touch screens, cameras, and GPS receivers. TVs are also completely dependent on secondary hardware devices. In order for users to interact with TV apps, they must use a remote control or game pad. When you build an app for TV, you must carefully consider the hardware limitations and requirements of operating on TV hardware.
This lesson discusses how to check if your app is running on a TV, how to handle unsupported hardware features, and discusses the requirements for handling controllers for TV devices.

Check for a TV Device

If you are building an app that operates both on TV devices and other devices, you may need to check what kind of device your app is running on and adjust the operation of your app. For instance, if you have an app that can be started through an Intent, your application should check the device properties to determine if it should start a TV-oriented activity or a phone activity.
The recommended way to determine if your app is running on a TV device is to use theUiModeManager.getCurrentModeType() method to check if the device is running in television mode. The following example code shows you how to check if your app is running on a TV device:
public static final String TAG = "DeviceTypeRuntimeCheck";
UiModeManager uiModeManager = (UiModeManager) getSystemService(UI_MODE_SERVICE);
if (uiModeManager.getCurrentModeType() == Configuration.UI_MODE_TYPE_TELEVISION) {
    Log.d(TAG, "Running on a TV Device")
} else {
    Log.d(TAG, "Running on a non-TV Device")
}

Handle Unsupported Hardware Features

Depending on the design and functionality of your app, you may be able to work around certain hardware features being unavailable. This section discusses what hardware features are typically not available for TV, how to detect missing hardware features, and suggests alternatives to using these features.

Unsupported TV hardware features

TVs have a different purpose from other devices, and so they do not have hardware features that other Android-powered devices often have. For this reason, the Android system does not support the following features for a TV device:
HardwareAndroid feature descriptor
Touchscreenandroid.hardware.touchscreen
Touchscreen emulatorandroid.hardware.faketouch
Telephonyandroid.hardware.telephony
Cameraandroid.hardware.camera
Bluetoothandroid.hardware.bluetooth
Near Field Communications (NFC)android.hardware.nfc
GPSandroid.hardware.location.gps
Microphone [1]android.hardware.microphone
Sensorsandroid.hardware.sensor
[1] Some TV controllers have a microphone, which is not the same as the microphone hardware feature described here. The controller microphone is fully supported.
See the Features Reference for a complete list of features, subfeatures, and their descriptors.

Declaring hardware requirements for TV

Android apps can declare hardware feature requirements in the app manifest to ensure that they do not get installed on devices that do not provide those features. If you are extending an existing app for use on TV, closely review your app's manifest for any hardware requirement declarations that might prevent it from being installed on a TV device.
If your app uses hardware features (such as a touchscreen or camera) that are not available on TV, but can operate without the use of those features, modify your app's manifest to indicate that these features are not required by your app. The following manifest code snippet demonstrates how to declare that your app does not require hardware features which are unavailable on TV devices, even though your app may use these features on non-TV devices:
<uses-feature android:name="android.hardware.touchscreen"
        android:required="false"/>
<uses-feature android:name="android.hardware.faketouch"
        android:required="false"/>
<uses-feature android:name="android.hardware.telephony"
        android:required="false"/>
<uses-feature android:name="android.hardware.camera"
        android:required="false"/>
<uses-feature android:name="android.hardware.bluetooth"
        android:required="false"/>
<uses-feature android:name="android.hardware.nfc"
        android:required="false"/>
<uses-feature android:name="android.hardware.gps"
        android:required="false"/>
<uses-feature android:name="android.hardware.microphone"
        android:required="false"/>
<uses-feature android:name="android.hardware.sensor"
        android:required="false"/>
Note: Some features have subfeatures like android.hardware.camera.front, as described in the Feature Reference. Be sure to mark as required="false" any subfeatures also used in your app.
All apps intended for use on TV devices must declare that the touch screen feature is not required as described in Get Started with TV Apps. If your app normally uses one or more of the features listed above, change theandroid:required attribute setting to false for those features in your manifest.
Caution: Declaring a hardware feature as required by setting its value to true prevents your app from being installed on TV devices or appearing in the Android TV home screen launcher.
Once you decide to make hardware features optional for your app, you must check for the availability of those features at runtime and then adjust your app's behavior. The next section discusses how to check for hardware features and suggests some approaches for changing the behavior of your app.
For more information on filtering and declaring features in the manifest, see the uses-feature guide.

Declaring permissions that imply hardware features

Some uses-permission manifest declarations imply hardware features. This behavior means that requesting some permissions in your app manifest can exclude your app from from being installed and used on TV devices. The following commonly requested permissions create an implicit hardware feature requirement:
PermissionImplied hardware feature
RECORD_AUDIOandroid.hardware.microphone
CAMERAandroid.hardware.camera and
android.hardware.camera.autofocus
ACCESS_COARSE_LOCATIONandroid.hardware.location and
android.hardware.location.network
ACCESS_FINE_LOCATIONandroid.hardware.location and
android.hardware.location.gps
For a complete list of permission requests that imply a hardware feature requirement, see the uses-featureguide. If your app requests one of the features listed above, include a uses-feature declaration in your manifest for the implied hardware feature that indicates it is not required (android:required="false").

Checking for hardware features

The Android framework can tell you if hardware features are not available on the device where your app is running. Use the hasSystemFeature(String) method to check for specific features at runtime. This method takes a single string argument that specifies the feature you want to check.
The following code example demonstrates how to detect the availability of hardware features at runtime:
// Check if the telephony hardware feature is available.
if (getPackageManager().hasSystemFeature("android.hardware.telephony")) {
    Log.d("HardwareFeatureTest", "Device can make phone calls");
}
// Check if android.hardware.touchscreen feature is available.
if (getPackageManager().hasSystemFeature("android.hardware.touchscreen")) {
    Log.d("HardwareFeatureTest", "Device has a touch screen.");
}

Touch screen

Since most TVs do not have touch screens, Android does not support touch screen interaction for TV devices. Furthermore, using a touch screen is not consistent with a viewing environment where the user is seated 10 feet away from the display. Make sure that your UI elements and text do not require or imply the use of a touchscreen.
On TV devices, you should design your app to work with this interaction model by supporting navigation using a directional pad (D-pad) on a TV remote control. For more information on properly supporting navigation using TV-friendly controls, see Creating TV Navigation.

Camera

Although a TV typically does not have a camera, you can still provide a photography-related app on a TV. For example, if you have an app that takes, views, and edits photos, you can disable its picture-taking functionality for TVs and still allow users to view and even edit photos. If you decide to enable your camera-related app to work on a TV, add the following feature declaration your app manifest:
<uses-feature android:name="android.hardware.camera" android:required="false" />
If you enable your app to run without a camera, add code to your app that detects if the camera feature is available and makes adjustments to the operation of your app. The following code example demonstrates how to detect the presence of a camera:
// Check if the camera hardware feature is available.
if (getPackageManager().hasSystemFeature("android.hardware.camera")) {
    Log.d("Camera test", "Camera available!");
} else {
    Log.d("Camera test", "No camera available. View and edit features only.");
}

GPS

TVs are stationary, indoor devices, and do not have built-in global positioning system (GPS) receivers. If your app uses location information, you can still allow users to search for a location, or use a static location provider such as a zip code configured during the TV device setup.
// Request a static location from the location manager
LocationManager locationManager = (LocationManager) this.getSystemService(
        Context.LOCATION_SERVICE);
Location location = locationManager.getLastKnownLocation("static");
// Attempt to get postal or zip code from the static location object
Geocoder geocoder = new Geocoder(this);
Address address = null;
try {
  address = geocoder.getFromLocation(location.getLatitude(),
          location.getLongitude(), 1).get(0);
  Log.d("Zip code", address.getPostalCode());
} catch (IOException e) {
  Log.e(TAG, "Geocoder error", e);
}

Handling Controllers

TV devices require a secondary hardware device for interacting with apps, in the form of a basic remote controller or game controller. This means that your app must support D-pad input. It also means that your app may need to handle controllers going offline and input from more than one type of controller.

D-pad minimum controls

The default controller for a TV device is a D-pad. In general, your app should be operable from a remote controller that only has up, down, left, right, select, Back, and Home buttons. If your app is a game that typically requires a game controller with additional controls, your app should attempt to allow gameplay with these D-pad controls. In this case, your app should also warn the user that a controller is required and allow them to exit your game gracefully using the D-pad controller. For more information about handling navigation with D-pad controller for TV devices, see Creating TV Navigation.

Handle controller disconnects

Controllers for TV are frequently Bluetooth devices which may attempt to save power by periodically going into sleep mode and disconnecting from the TV device. This means that an app might be interrupted or restarted if it is not configured to handle these reconnect events. These events can happen in any of the following circumstances:
  • While watching a video which is several minutes long, a D-Pad or game controller goes into sleep mode, disconnects from the TV device and then reconnects later on.
  • During gameplay, a new player joins the game using a game controller that is not currently connected.
  • During gameplay, a player leaves the game and disconnects a game controller.
Any TV app activity that is subject to disconnect and reconnect events must be configured to handle reconnection events in the app manifest. The following code sample demonstrates how to enable an activity to handle configuration changes, including a keyboard or navigation device connecting, disconnecting, or reconnecting:
<activity
  android:name="com.example.android.TvActivity"
  android:label="@string/app_name"
  android:configChanges="keyboard|keyboardHidden|navigation"
  android:theme="@style/Theme.Leanback">

  <intent-filter>
    <action android:name="android.intent.action.MAIN" />
    <category android:name="android.intent.category.LEANBACK_LAUNCHER" />
  </intent-filter>
  ...</activity>
This configuration change allows the app to continue running through a reconnection event, rather than being restarted by the Android framework, which is not a good user experience.

Handle D-pad input variations

TV device users may have more than one type of controller that they use with their TV. For example, a user might have both a basic D-pad controller and a game controller. The key codes provided by a game controller when it is being used for D-pad functions may vary from the key codes sent by a physical D-pad.
Your app should handle the variations of D-pad input from a game controller, so the user does not have to physically switch controllers to operate your app. For more information on handling these input variations, see
Building Layouts for TV

A TV screen is typically viewed from about 10 feet away, and while it is much larger than most other Android device displays, this type of screen does not provide the same level of precise detail and color as a smaller device. These factors require you to create app layouts with TV devices in mind in order to create a useful and enjoyable user experience.
This lesson describes the minimum requirements and implementation details for building effective layouts in TV apps.

Use Layout Themes for TV

Android Themes can provide a basis for layouts in your TV apps. You should use a theme to modify the display of your app activities that are meant to run on a TV device. This section explains which themes you should use.

Leanback theme

A support library for TV user interfaces called the v17 leanback library provides a standard theme for TV activities, called Theme.Leanback. This theme establishes a consistent visual style for TV apps. Use of this theme is recommended for most TV apps. This theme is strongly recommended for any TV app that uses v17 leanback classes. The following code sample shows how to apply this theme to a given activity within an app:
<activity
  android:name="com.example.android.TvActivity"
  android:label="@string/app_name"
  android:theme="@style/Theme.Leanback">

NoTitleBar theme

The title bar is a standard user interface element for Android apps on phones and tablets, but it is not appropriate for TV apps. If you are not using v17 leanback classes, you should apply this theme to your TV activities to suppress the display of a title bar. The following code example from a TV app manifest demonstrates how to apply this theme to remove the display of a title bar:
<application>
  ...

  <activity
    android:name="com.example.android.TvActivity"
    android:label="@string/app_name"
    android:theme="@android:style/Theme.NoTitleBar">
    ...

  </activity>
</application>

Build Basic TV Layouts

Layouts for TV devices should follow some basic guidelines to ensure they are usable and effective on large screens. Follow these tips to build landscape layouts optimized for TV screens:
  • Build layouts with a landscape orientation. TV screens always display in landscape mode.
  • Put on-screen navigation controls on the left or right side of the screen and save the vertical space for content.
  • Create UIs that are divided into sections, using Fragments, and use view groups like GridView instead ofListView to make better use of the horizontal screen space.
  • Use view groups such as RelativeLayout or LinearLayout to arrange views. This approach allows the system to adjust the position of the views to the size, alignment, aspect ratio, and pixel density of a TV screen.
  • Add sufficient margins between layout controls to avoid a cluttered UI.

Overscan

Layouts for TV have some unique requirements due to the evolution of TV standards and the desire to always present a full screen picture to viewers. For this reason, TV devices may clip the outside edge of an app layout in order to ensure that the entire display is filled. This behavior is generally referred to as overscan.
Avoid screen elements being clipped due to overscan and by incorporating a 10% margin on all sides of your layout. This translates into a 48dp margin on the left and right edges and a 27dp margin on the top and bottom of your base layouts for activities. The following example layout demonstrates how to set these margins in the root layout for a TV app:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
  android:id="@+id/base_layout"
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  android:orientation="vertical"
  android:layout_marginTop="27dp"
  android:layout_marginLeft="48dp"
  android:layout_marginRight="48dp"
  android:layout_marginBottom="27dp" >
</LinearLayout>
Caution: Do not apply overscan margins to your layout if you are using the v17 leanback classes, such asBrowseFragment or related widgets, as those layouts already incorporate overscan-safe margins.

Build Useable Text and Controls

The text and controls in a TV app layout should be easily visible and navigable from a distance. Follow these tips to make your user interface elements easier to see from a distance:
  • Break text into small chunks that users can quickly scan.
  • Use light text on a dark background. This style is easier to read on a TV.
  • Avoid lightweight fonts or fonts that have both very narrow and very broad strokes. Use simple sans-serif fonts and anti-aliasing to increase readability.
  • Use Android's standard font sizes:
    <TextView
      android:id="@+id/atext"
      android:layout_width="wrap_content"
      android:layout_height="wrap_content"
      android:gravity="center_vertical"
      android:singleLine="true"
      android:textAppearance="?android:attr/textAppearanceMedium"/>
  • Ensure that all your view widgets are large enough to be clearly visible to someone sitting 10 feet away from the screen (this distance is greater for very large screens). The best way to do this is to use layout-relative sizing rather than absolute sizing, and density-independent pixel (dip) units instead of absolute pixel units. For example, to set the width of a widget, use wrap_content instead of a pixel measurement, and to set the margin for a widget, use dip values instead of px values.
For more information about density-independent pixels and building layouts to handle larger screen sizes, seeSupporting Multiple Screens.

Manage Layout Resources for TV

The common high-definition TV display resolutions are 720p, 1080i, and 1080p. Your TV layout should target a screen size of 1920 x 1080 pixels, and then allow the Android system to downscale your layout elements to 720p if necessary. In general, downscaling (removing pixels) does not degrade your layout presentation quality. However, upscaling can cause display artifacts that degrade the quality of your layout and have a negative impact on the user experience of your app.
To get the best scaling results for images, provide them as 9-patch image elements if possible. If you provide low quality or small images in your layouts, they will appear pixelated, fuzzy, or grainy, which is not a good experience for the user. Use high-quality images instead.
For more information on optimizing layouts and resources for large screens see Designing for multiple screens.

Avoid Layout Anti-Patterns

There are a few approaches to building layouts that you should avoid because they do not work well on TV devices and lead to bad user experiences. Here are some user interface approaches you should specifically notuse when developing a layout for TV.
  • Re-using phone or tablet layouts - Do not reuse layouts from a phone or tablet app without modification. Layouts built for other Android device form factors are not well suited for TV devices and should be simplified for operation on a TV.
  • ActionBar - While this user interface convention is recommended for use on phones and tablets, it is not appropriate for a TV interface. In particular, using an action bar options menu (or any pull-down menu for that matter) is strongly discouraged, due to the difficulty in navigating such a menu with a remote control.
  • ViewPager - Sliding between screens can work great on a phone or tablet, but don't try this on a TV!
For more information on designing layouts that are appropriate to TV, see the TV Design guide.

Handle Large Bitmaps

TV devices, like any other Android device, have a limited amount of memory. If you build your app layout with very high-resolution images or use many high-resolution images in the operation of your app, it can quickly run into memory limits and cause out of memory errors. To avoid these types of problems, follow these tips:
  • Load images only when they are displayed on the screen. For example, when displaying multiple images in aGridView or Gallery, only load an image when getView() is called on the view's Adapter.
  • Call recycle() on Bitmap views that are no longer needed.
  • Use WeakReference for storing references to Bitmap objects in an in-memory Collection.
  • If you fetch images from the network, use AsyncTask to fetch and store them on the device for faster access. Never do network transactions on the application's main user interface thread.
  • Scale down large images to a more appropriate size as you download them; otherwise, downloading the image itself may cause an out of memory exception.
For more information on getting the best performance when working with images, see Displaying Bitmaps Efficiently.

Provide Effective Advertising

Advertising on Android TV must always be full-screen. Ads must not appear alongside or over content. The user must be able to dismiss an advertisement with the D-pad controller. Video ads must be dismissible within 30 seconds of their start time.
Android TV does not provide a web browser. Your ads must not attempt to launch a web browser or redirect to the Google Play Store.
Note: You can use the WebView class for logins to services like Google+ and Facebook.






Creating TV Navigation

PREVIOUSNEXT
TV devices provide a limited set of navigation controls for apps. Creating an effective navigation scheme for your TV app depends on understanding these limited controls and the limits of users' perception while operating your app. As you build your Android app for TVs, pay special attention to how the user actually navigates around your app when using remote control buttons instead of a touch screen.
This lesson explains the minimum requirements for creating effective TV app navigation scheme and how to apply those requirements to your app.

Enable D-pad Navigation

On a TV device, users navigate with controls on a remote control device, using either a directional pad (D-pad) or arrow keys. This type of control limits movement to up, down, left, and right. To build a great TV-optimized app, you must provide a navigation scheme where the user can quickly learn how to navigate your app using these limited controls.
The Android framework handles directional navigation between layout elements automatically, so you typically do not need to do anything extra for your app. However, you should thoroughly test navigation with a D-pad controller to discover any navigation problems. Follow these guidelines to test that your app's navigation system works well with a D-pad on a TV device:
  • Ensure that a user with a D-pad controller can navigate to all visible controls on the screen.
  • For scrolling lists with focus, make sure that the D-pad up and down keys scroll the list, and the Enter key selects an item in the list. Verify that users can select an element in the list and that the list still scrolls when an element is selected.
  • Ensure that switching between controls between controls is straightforward and predictable.

Modifying directional navigation

The Android framework automatically applies a directional navigation scheme based on the relative position of focusable elements in your layouts. You should test the generated navigation scheme in your app using a D-pad controller. After testing, if you decide you want users to move through your layouts in a specific way, you can set up explicit directional navigation for your controls.
Note: You should only use these attributes to modify the navigation order if the default order that the system applies does not work well.
The following code sample shows how to define the next control to receive focus for a TextView layout object:
<TextView android:id="@+id/Category1"
        android:nextFocusDown="@+id/Category2"\>
The following table lists all of the available navigation attributes for Android user interface widgets:
AttributeFunction
nextFocusDownDefines the next view to receive focus when the user navigates down.
nextFocusLeftDefines the next view to receive focus when the user navigates left.
nextFocusRightDefines the next view to receive focus when the user navigates right.
nextFocusUpDefines the next view to receive focus when the user navigates up.
To use one of these explicit navigation attributes, set the value to the ID (android:id value) of another widget in the layout. You should set up the navigation order as a loop, so that the last control directs focus back to the first one.

Provide Clear Focus and Selection

The success of an app's navigation scheme on TV devices is depends on how easy it is for a user to determine what user interface element is in focus on screen. If you do not provide clear indications of focused items (and therefore what item a user can take action on), they can quickly become frustrated and exit your app. For the same reason, it is important to always have an item in focus that a user can take action on immediately after your app starts, or any time it is idle.
Your app layout and implementation should use color, size, animation, or a combination of these attributes to help users easily determine what actions they can take next. Use a uniform scheme for indicating focus across your application.
Android provides Drawable State List Resources to implement highlights for focused and selected controls. The following code example demonstrates how to enable visual behavior for a button to indicate that a user has navigated to the control and then selected it:
<!-- res/drawable/button.xml -->
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:state_pressed="true"
          android:drawable="@drawable/button_pressed" /> <!-- pressed -->
    <item android:state_focused="true"
          android:drawable="@drawable/button_focused" /> <!-- focused -->
    <item android:state_hovered="true"
          android:drawable="@drawable/button_focused" /> <!-- hovered -->
    <item android:drawable="@drawable/button_normal" /> <!-- default -->
</selector>
The following layout XML sample code applies the previous state list drawable to a Button:
<Button
    android:layout_height="wrap_content"
    android:layout_width="wrap_content"
    android:background="@drawable/button" />
Make sure to provide sufficient padding within the focusable and selectable controls so that the highlights around them are clearly visible.

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)