Member Avatar for EddieC
EddieC 0 Posting Whiz in Training

What has proven to be alien to Apple and Microsoft may be just right for Android. Search giant Google this week announced that it is working with Sony, Intel and computer accessory maker Logitech on technology to bring Web searches and applications to the television. Efforts by Google's predecessors--Apple TV and WebTV--turned in disappointing results.

It's early yet and reports are mixed, but most indicate that Google's Android mobile operating system will for the basis for an Atom-based set-top box built by Sony. Other reports have Logitech developing a remote control for the system. In any event, it appears there will be opportunities for developers to build applications to run on the what some are calling "Google TV," as they now run on Android-based phones. Software running on the box will help users surf the Web on television sets and launch apps, visit social networks and view or listen to content. It's even possible that the technology could some day come pre-installed in TVs and other devices such as Blu-ray players.

The Wall Street Journal reported earlier this month reported that Google was working with satellite service provider Dish Network on set-top box software that allows searches for satellite programming and to create a custom viewing experience. But according to the WSJ video report, it could be years before it's ready for deployment.

Google has a pretty good track record when it comes to trail blazing, but can it succeed where others have failed and crack TV? Don't bet against it.

  • 1 Contributor
  • 0 Replies
  • 116 Views

Dani AI

Generated

raised the platform opportunity; the practical next step is preparing apps for a TV-first environment rather than repeating the market background. The biggest gaps developers commonly miss are input model changes, large-screen layout rules, media/playback constraints, and ABI/testing differences. The checklist below focuses on those concrete, actionable items.

Start with the standard Android toolchain (IDE + SDK) and treat TV as a different device class. Key differences: no touch surface as primary input (remote and D‑pad navigation), much larger viewing distance (10‑foot UI), and wider variety of screen sizes/overscan. UI work should use focusable views, visible focus indicators, and layouts designed for high-resolution displays. Avoid touch-only controls and small fonts; prefer simple grids or lists navigable by directional keys.

Media and performance notes: prefer Android media APIs (MediaPlayer/VideoView or a modern media engine) and test hardware-accelerated playback on target hardware. Prepare native libraries for multiple ABIs (ARM and x86 where relevant) so binaries run on both chip families. Account for longer-running playback sessions: handle lifecycle (pause/resume), audio focus, and background/foreground transitions.

Testing and input example: validate on both emulator (large-screen skin + hardware keyboard) and at least one real device with a remote. Key handling often needs explicit code, for example:

@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
    switch (keyCode) {
        case KeyEvent.KEYCODE_DPAD_CENTER:
        case KeyEvent.KEYCODE_ENTER:
            // activate focused item
            return true;
        default:
            return super.onKeyDown(keyCode, event);
    }
}

Design for clarity: large touch targets (for remote selection), high contrast, predictable focus order, and graceful behavior under network variability. Packaging and distribution options may vary by platform; include side-loading testing in addition to any official store workflows.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.