Updates are now available to Developing AIR applications for television devices in Building Adobe AIR Applications on Adobe.com.
These updates include:
- Design considerations. Remember all the entries on this blog that talked about various design considerations for AIR for TV apps? Now those tips plus others are available in the online documentation.
- How to use Adobe Flash Professional CS5 and Adobe Flash Builder 4.5 to develop your AIR for TV application. This information includes how to build an application that uses an ActionScript extension.
- How to use ADT to package an AIR for TV application that uses an ActionScript extension.
- How to use ADL to test an AIR for TV application that uses an ActionScript extension.
- General information on how to remotely debug an AIR for TV application running on the device. However, detailed steps depend on the device.
The prerelease ActionScript 3.0 Reference for Flash Player 10.3 (“Wasabi”) Beta is now available. You can find this documentation here.
The Wasabi project represents the convergence of Flash Player and AIR streams into a single quarterly update.
Highlights include the following new features and classes:
Acoustic echo cancellation (Flash Player)
Exclude unwanted echo artifacts from microphone audio captures.
Media measurement (Flash Player)
Implement media usage analysis on the Flash Player platform rather than as a player plugin. Collect stats independently of the video player being used.
HTMLLoader updates (AIR)
The HTMLLoader class now dispatches
locationChange events with a
LocationChangeEvent object as the payload.
Important! To see the beta classes, remember to set your Runtimes filter to include Flash Player 10.3 and earlier.
Please use the Comments area at the bottom of each page to give us feedback on this beta documentation.
And here’s one more design consideration for AIR for TV application development…
This one continues the discussion from the blog entry called Using Graphics Hardware Acceleration in AIR for TV Apps.
To perform the accelerated graphics operations, hardware accelerators use special graphics memory. If your
application uses all the graphics memory, the application runs more slowly because AIR for TV reverts to using
software for the graphics operations.
To manage your application’s use of graphics memory:
- When you are done using an image or other bitmap data, release its associated graphics memory. To do so, call the
dispose() method of the
bitmapData property of the Bitmap object. For example:
Note: Releasing the reference to the BitmapData object does not immediately free the graphics memory. The runtime’s garbage collector eventually frees the graphics memory, but calling dispose() gives your application more control.
- Use PerfMaster Deluxe, an AIR application that Adobe provides, to better understand the impact of hardware graphics acceleration on your target device. This application shows the frames per second to execute various operations. Use PerfMaster Deluxe to compare different implementations of the same operation. For example, compare moving a bitmap image versus moving a vector image. PerfMaster Deluxe is available with the Adobe® AIR® for TV MAX 2010 Hardware Developer Kit, and will soon be available at Flash Platform so you can use it with other devices, too.
And don’t forget: Do not keep bitmap objects, or any objects, on the display list when they are not visible. Whether software or hardware renders a display object, rendering it when it is not visible needlessly uses resources to render the object. If you have a good reason to hold onto a display object when it is not visible, remove the object from the display list. This best practice applies not only for AIR for TV apps, but AIR apps and Flash Player apps on all devices (mobile, desktop, tablet, and TVs).
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.
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.
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.
As of August 24, Adobe’s newest service for AIR application developers (codenamed Melrose) is available as a public beta. Go to http://labs.adobe.com/technologies/melrose/ to download the Melrose SDK and access the Melrose Portal to distribute your applications.
What (you may ask) is Melrose? In short, Melrose is a monetization service for developers and distributors of AIR applications. Using Adobe® Flex® Builder™ 3, Adobe® Flash Builder™ 4, or Adobe® Flash® Professional CS5, you can add try and buy functionality to your apps. You can then use Melrose to distribute your apps to multiple online stores. The Intel AppUp Center and the Adobe AIR Marketplace are the first two storefronts available in Melrose.
Melrose is a new addition to the Adobe® Flash® Platform Services, which together enable developers to add social and collaborative capabilities to applications, then distribute, track, and monetize them. See http://www.adobe.com/flashplatform/services/ for information.
Melrose helps AIR app developers with the following tasks:
Try and buy
When you are developing an AIR application, you embed the licensing SWC in your application, then enter code to specify the price and trial periods online. You can also add try and buy functionality to existing applications.
When customers purchase your applications, the Melrose service keeps track of the income from each of your applications. You are paid at regular intervals, typically once a month.
Reports are available online via the Melrose Portal. In this initial release you can view information regarding revenue, active trials, expired trials and downloads. These reports collect data from everywhere you distribute your application with Melrose–not just from apps that are downloaded from the Adobe AIR Marketplace.
Sound interesting? Go to http://labs.adobe.com/technologies/melrose/ to learn more and try it out for yourself.
The August edition of the Adobe Edge newsletter features a great article by ace Flash/Flex/ColdFusion developer Brian Rinaldi. It’s called Getting Started with Adobe AIR for Android. Here’s a quick excerpt from the piece that describes what it covers:
“In this article, I discuss the essential tools you need to start developing for AIR for Android using Adobe Flash Professional CS5. I walk you through getting AIR installed on your Android phone and configuring Flash software to develop for that platform. Then I show you how to build and deploy your first application.”
While we’re on the topic of Brian, the Flash Platform content and community team are very pleased to announce that Brian joined our team as Web Community Manager as of August 16. Brian will be working with Adobe to define and drive our community strategy and develop programs to promote community help.
Many of you may know Brian as an author, presenter and thought-leader within the Adobe developer community. He has more than 11 years of experience developing web applications in both small businesses and large enterprises including 10+ years with ColdFusion and SQL (he is an Adobe Certified Expert in ColdFusion) and 3+ years with Flex/AIR/ActionScript.
Brian has been an active organizer and volunteer for several years. He started his own conference in Boston – known first as Flex Camp Boston, now as RIA Unleashed. In addition to running the Boston ColdFusion User Group for the past five years, Brian was an Adobe Community Professional as well as an advisor to the Boston Flex User Group.
Brian blogs regularly at remotesynthesis.com and is an unapologetic Twitter addict under the handle @remotesynth. Check him out!
Flash Player 10.1 and AIR 2 are now available for download on adobe.com.
For more information about AIR, read the announcement on the AIR blog and check out the release notes for a list of new features.
For more information about Flash Player, read the announcement on the Flash Player blog.
The ActionScript 3.0 Reference for Flash Platform includes all the Flash Player 10.1 and AIR 2 APIs.
You can filter the ActionScript Reference to display APIs for specific runtimes:
Download the Flash Player 10.1 and AIR 2 mobile runtimes from Adobe Labs.