Posts in Category "AIR"

UI personality for AIR for TV applications

Here’s another user interface design consideration for AIR for TV applications. (This and other tips will be incorporated soon into Adobe online documentation).

This tip considers that users of AIR for TV applications are typically seeking TV quality entertainment in a fun and relaxed environment. They are not necessarily knowledgeable about computers or technology.

Therefore, design AIR for TV applications with the following characteristics:

  • Do not use technical terms.
  •  

  • Avoid modal dialogs.  Modal dialogs confuse some users.
  •  

  • Use friendly, informal instructions appropriate for a living room environment, not a work or technical environment.
  •  

  • Use graphics that have the high production quality that TV watchers expect.

 

     

    Usability of your AIR for TV application

    Here’s another design consideration for the user interface of AIR for TV applications. (This and other tips will be incorporated soon into Adobe online documentation).

    Users of AIR for TV applications are in a “living room” environment. They are sitting across the room from the TV, some 10 feet away. The room is sometimes dark. They typically use a remote control device for input. More than one person can be using the application, sometimes together, sometimes serially.

    Therefore, to design your user interface for usability on a TV, consider the following:

    • Make the user interface elements large.This best practice might be obvious to many developers, but the temptation does exist to crowd the screen just because the screen has so much space.  Don’t give in to this temptation. When designing text, buttons, or any other user interface elements, consider that the user is sitting across the room. Make everything easy to see and read from, for example, 10 feet away. 
    • Use good contrast to make the content easy to see and read from across the room.
    •  

    • Make obvious which user interface element has the focus by making that element bright.  See the blog entry from March 8 about Managing Focus.
    •  

    • Use motion only as necessary. For example, sliding from one screen to the next for continuity can work well. However, motion can be distracting if it does not help the user navigate or if it is not intrinsic to the application.
    •  

    • Always provide an obvious way for the user to go back through the user interface.

    Using graphics hardware acceleration in AIR for TV apps

    And here is yet one more tip from soon-to-be-available-at-adobe.com documentation about AIR for TV application development.

    AIR for TV devices provide hardware acceleration for 2D graphics operations. The device’s hardware graphics accelerators off-load the CPU to perform the following operations:

    • Bitmap rendering
    • Bitmap scaling
    • Bitmap blending
    • Solid rectangle filling

    This hardware graphics acceleration means many graphics operations in an AIR for TV application can be high performing. Some of these operations include:

    • Sliding transitions
    • Scaling transitions
    • Fading in and out
    • Compositing multiple images with alpha

    To get the performance benefits of hardware graphics acceleration for these types of operations, use one of the following techniques:

    • Set the cacheAsBitmap property to true on MovieClip objects and other display objects that have content that is mostly unchanging. Then perform sliding transitions, fading transitions, and alpha blending on these objects.
    • Use the cacheAsBitmapMatrix property on display objects you want to scale or translate (apply x and y repositioning).

      By using Matrix class operations for scaling and translation, the device’s hardware accelerators perform the operations. Alternatively, consider the scenario where you change the dimensions of a display object that has its cacheAsBitmap property set to true. When the dimensions change, the runtime’s software redraws the bitmap. Redrawing with software yields poorer performance than scaling with hardware acceleration by using a Matrix operation.

      For example, consider an application that displays an image that expands when an end user selects it. Use the Matrix scale operation multiple times to give the illusion of the image expanding. However, depending on the size of the original image and final image, the quality of the final image can be unacceptable. Therefore, reset the dimensions of the display object after the expanding operations are completed. Because cacheAsBitmap is true, the runtime software redraws the display object, but only once, and it renders a high-quality image.

      Note: Typically, AIR for TV devices do not support hardware-accelerated rotation and skewing. Therefore, if you specify rotation and skewing in the Matrix class, AIR for TV performs all the Matrix operations in the software. These software operations can have a detrimental impact to performance.
    • Use the BitmapData class to create custom bitmap caching behavior.

     

    User interface responsiveness in AIR for TV applications

    Here’s another design consideration for AIR for TV applications. (This and other tips will be incorporated soon into Adobe online documentation).

    Use the following tips to make an AIR for TV application as responsive as possible.

    • Make the application’s initial SWF file as small as possible.

      In the initial SWF file, load only the necessary resources to start the application. For example, load only the application’s startup screen image.

      Although this recommendation is valid for desktop AIR applications, it is more important on AIR for TV devices. For example, AIR for TV devices do not have the equivalent processing power of desktop computers. Also, they store the application in flash memory, which is not as fast to access as hard disks on desktop computers.
    • Make the application run at a frame rate of at least 20 frames per second.

      Design your graphics to achieve this goal. The complexity of your graphics operations can affect your frames per second. For tips on improving rendering performance, see Optimizing Performance for the Adobe Flash Platform.

      Note that the graphics hardware on AIR for TV devices typically updates the screen at a rate of 60 Hz or 120 Hz (60 or 120 times per second). The hardware scans the stage for updates at, for example, 30 frames per second or 60 frames per second for display on the 60-Hz or 120-Hz screen. However, whether the user experiences these higher frame rates depends on the complexity of the application’s graphics operations.

      Stay tuned for an upcoming blog entry discussing what the graphics hardware accelerators on AIR for TV devices do well, and how to take advantage of them.

    • Update the screen within 100 – 200 milliseconds of user input.

      Users become impatient if updates take longer, often resulting in multiple keypresses.

    Managing focus in AIR for TV applications

    Here’s another design consideration for AIR for TV applications. (This and other tips will be incorporated soon into Adobe online documentation).

    When a user interface element has the focus in a desktop application, it is the target of user input events such as keyboard and mouse events. Furthermore, an application highlights the user interface element with the focus. Managing focus in an AIR for TV application is different from managing focus in a desktop application because:

    • Desktop applications often use the tab key to change focus to the next user interface element. Using the tab key doesn’t apply to AIR for TV applications. Remote control devices do not typically have a tab key. Therefore, managing focus with the tabEnabled property of a DisplayObject like on the desktop does not apply.
    • Desktop applications often expect the user to use the mouse to give focus to a user interface element.

    Therefore, in your application, do the following:

    • Add an event listener to the Stage that listens for Keyboard events such as
      KeyboardEvent.KEY_DOWN.
    • Provide application logic to determine which user interface element to highlight to the end user. Be sure to highlight a user interface element when the application starts.
    • Based on your application logic, dispatch the Keyboard event that the Stage received to the appropriate user interface element object.

      You can also use Stage.focus or Stage.assignFocus() to assign the focus to a user interface element. You can then add an event listener to that DisplayObject so that it receives keyboard events.

    Remote control input handling in AIR for TV apps

    And here’s yet another design consideration for AIR for TV applications.  (This and other tips will be incorporated soon into Adobe online documentation).

    Users typically interact with your AIR for TV application using a remote control. The good news is that the way you handle remote control key input is the same way you handle key input from a keyboard on a desktop application. Specifically, handle the event KeyboardEvent.KEY_DOWN.

    The keys on the remote control map to ActionScript constants. For example, the keys on the directional keypad on a remote control map as follows:

    Remote control’s directional keypad key
    ActionScript 3.0 constant
    Up Keyboard.UP
    Down Keyboard.DOWN
    Left Keyboard.LEFT
    Right Keyboard.RIGHT
    OK or Select Keyboard.ENTER

    AIR 2.5 added many other Keyboard constants to support remote control input. For a complete list, see the Keyboard class in the ActionScript 3.0 Reference for the Adobe Flash Platform.

    To ensure your application works on as many devices as possible, Adobe recommends the following:

    • Use only the directional keypad keys, if possible.

      Different remote control devices have different sets of keys. However, they typically always have the directional keypad keys.

      For example, a remote control for a Blu-ray player does not typically have a “channel up” and “channel down” key. Even keys for play, pause, and stop are not on all remote controls.

    • Use the Menu and Info keys if the application needs more than the directional keypad keys.

      The Menu and Info keys are the next most common keys on remote controls.

    • Consider the frequent usage of universal remote controls.

      Even if you are creating an application for a particular device, realize that many users do not use the remote control that comes with the device. Instead, they use a universal remote control. Also, users do not always program their universal remote control to match all the keys on the device’s remote control. Therefore, using only the most common keys is advisable.

    • Make sure that the user can always escape a situation using one of the directional keypad keys.

      Sometimes your application has a good reason to use a key that is not one of the most common keys on remote controls. Providing an escape route with one of the directional keypad keys makes your application behave gracefully on all devices.

    • Do not require mouse input.

      Obviously, a television doesn’t have a mouse. However, if you are converting desktop applications to run on televisions, make sure that you modify the application to not expect mouse input. These modifications include changes to event handling and changes to instructions to the user. For example, don’t overlook changing an application’s startup screen if it displays text that says “Click to start”.

    For more information on key input handling, see Capturing keyboard input in the ActionScript 3.0 Developer’s Guide. Continue reading…

    AIR for TV Stage property settings

    In my last blog entry discussing a TV’s safe viewing area, I mentioned the Stage.stageWidth and Stage.stageHeight properties of a full-screen application on a TV with a 1080p screen resolution.  Let’s look a little more at how to set these and other Stage properties with regard to AIR for TV apps.

    Stage.stageWidth and Stage.stageHeight

    If you are writing a full-screen AIR for TV application for a specific device, go ahead and  hard-code Stage.stageWidth and Stage.stageHeight to the device’s screen resolution. However, to write a full-screen application that runs on multiple devices, use the Capabilities.screenResolutionX and Capabilities.screenResolutionY properties to set your Stage dimensions. For example:

    stage.stageWidth = Capabilities.screenResolutionX;
    stage.stageHeight = Capabilities.screenResolutionY;

    Stage scale mode

    Set Stage.scaleMode to StageScaleMode.NO_SCALE, and listen for stage resize events.

    stage.scaleMode = StageScaleMode.NO_SCALE;
    stage.addEventListener(Event.RESIZE, layoutHandler);

    This scale mode setting results in the following:

    • When the application’s window changes size, the stage contents maintain their defined size. The runtime performs no automatic layout or scaling. Also, the runtime dispatches the Stage class’s resize event. Therefore, you have full control over how to adjust the application’s contents when the application begins and when the application window resizes.
    • You can use the stageWidth and stageHeight properties of the Stage class to determine the actual pixel dimensions of the application’s window. Therefore, in full-screen applications, these properties correspond to the screenResolutionX and screenResolutionY properties of the Capabilities class.

    Stage alignment

    Set Stage.align to StageAlign.TOP_LEFT:

    stage.align = StageAlign.TOP_LEFT;

    This alignment places the 0,0 coordinate in the upper-left corner of the screen, which is convenient for content placement using ActionScript. Therefore, this alignment works nicely with StageScaleMode.NO_SCALE, since your application is in charge of layout.

    Stage display state

    Set Stage.displayState in a full-screen AIR for TV application to StageDisplayState.FULL_SCREEN_INTERACTIVE:

    stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;

    This value sets the AIR application to expand the stage over the entire screen, with user input allowed.

    Stage quality

    You can set the Stage.quality property for an AIR for TV application to StageQuality.Best or StageQuality.High, specifying the rendering quality for all Stage objects. For example:

    stage.quality = StageQuality.High;

    AIR for TV applications and the “safe viewing area” (aka “title safe area”)

    Here’s another design consideration for AIR for TV applications.  (This and other tips will be incorporated soon into Adobe online documentation).

    When designing your user interface for an AIR for TV app, be sure to consider the safe viewing area. The safe viewing area on a TV is the area of the screen that the end-user can actually see. This area is also known as the title safe area. Overscan is the portion of the actual image area that falls outside the safe viewing area. The safe viewing area can vary depending on the device. This concept originated with analog televisions in which the television’s physical design sometimes hid the edges of the displayed image. However, it still often applies today.

    Adobe recommends an inset of 7.5% on each edge of the screen. For example, on a TV with a screen resolution of 1080p, a full-screen AIR application has a Stage.stageWidth of 1920 and Stage.stageHeight of 1080. The following figure shows the safe viewing area of the stage using 7.5%:

    I’ll leave it to you to do the math for 7.5% for other screen resolutions such as 540p and 720p (stage dimensions of 960 x 540 and 1280 x 720, respectively).

    Because of the safe viewing area, design your full-screen AIR for TV application as follows:

    • Use the entire stage dimensions for backgrounds, such as background images or background colors.
    • Use only the safe viewing area for critical application elements such as text, graphics, video, and user interface items such as buttons.

    Depending on the device on which your application runs, the safe viewing area sometimes doesn’t apply. But to be sure your critical application elements are never hidden, always design to accommodate the safe viewing area.

    Filesystem access in an AIR for TV app

    If you are writing or planning to write apps for AIR 2.5 for TV, you’ve probably already been looking at the documents and tutorials on http://www.adobe.com/devnet/devices/flash_platform_tv.html.

    More docs are in the works, but in the meantime I thought I’d use this blog to present some of that content.

    AIR for TV apps can access the device’s filesystem, but on a “living room” device it is critically important that an app cannot access the device’s system files or the files of other applications installed on the device. Users of TVs and associated devices do not expect or tolerate any device failures — they are watching TV, after all.

    Therefore, an AIR for TV application has a limited view of the device’s filesystem. Using ActionScript 3.0, your app can access only the following directories (and their subdirectories). But realize that these names are not the actual directory names on the device. This extra layer protects AIR for TV  applications from maliciously or inadvertently accessing local files that do not belong to them.

    • /app/ is the read-only application directory for the running AIR application.
    • /app-storage/ is the read-write application storage directory for the running AIR application.
    • /home/ is the read-write user directory.
    • /tmp/ is the read-write temporary directory for the running AIR application.
    • /volumes/ is the read-only directory containing zero or more read-write subdirectories that represent mounted volumes.

    If an app tries to access any other directory, the runtime throws an exception that the ActionScript code can catch.

    As with AIR applications targeting other devices, it’s a best practice to use the following File class properties rather than a directory name:

    • File.applicationDirectory maps to the application’s application-specific directory.  The File.nativePath value of File.applicationDirectory  is /app/ in AIR for TV.
    • File.applicationStorageDirectory maps to an application-specific directory within a user-specific directory.  Its File.nativePath value is /app-storage/ in AIR for TV.
    • File.desktopDirectory maps to an application-specific directory within a user-specific directory.  Its File.nativePath value is /home/ in AIR for TV.
    • File.userDirectory maps to an application-specific directory within a user-specific directory. Its File.nativePath value is /home/ in AIR for TV.
    • File.documentsDirectory maps to an application-specific directory within a user-specific directory. Its File.nativePath value is /home/ in AIR for TV.

    Note that File.desktopDirectory, File.userDirectory, and File.documentsDirectory all map to the same directory, which has the File.nativePath value  /home/.

    Also consider the behavior of the following methods on AIR for TV devices:

    • File.createTempDirectory() creates a directory with the File.nativePath value /tmp/. AIR for TV maps /tmp/ to a temporary directory on the device. AIR for TV deletes this directory and its contents when the AIR application exits.
    • File.createTempFile() creates a file in the /tmp/ directory.
    • File.getRootDirectories()returns an array with one File object. The File object’s nativePath property has the value /. This root directory contains the directories app, app-storage, home and tmp.
    • StorageVolumeInfo.storageVolumeInfo.getStorageVolumes() returns a Vector of StorageVolume objects. Each StorageVolume object’s rootDirectory property is a File object. The File object’s nativePath value begins with /volumes/. All applications and users have access to the /volumes/ directory.

    AIR for TV apps documentation available

    If you are developing AIR applications for Adobe AIR for TV, or want to be, check out this Adobe Developer Connection page:  Flash Platform for TV.  You’ll find FAQs, tutorials, demos, and documentation to get you going.

    A few documentation highlights include:

    The StageVideo class

    AIR for TV devices use hardware accelerators to decode and present video, which provide the end-user a great viewing experience while off-loading the device’s CPU.  To take advantage of this video hardware, use the StageVideo ActionScript class instead of the Video class in your application. Read more about the StageVideo class in:

    AIR for TV profile support

    A device profile defines the set of APIs and capabilities typically supported on a particular class of device.  Your AIR for TV applications will use either the tv or extendedTV profile.  To get an overview of what’s supported in these profiles, see Building Adobe AIR Applications — Device profiles.

    Packaging your AIR for TV application

    For information about how to package your AIR for TV app, see Developing AIR applications for television devices.