Introducing Adobe Flash Player 10.1 public prerelease
Modified
17 November 2009
At Adobe MAX 2009, Kevin Lynch introduced the next release of Adobe Flash Player on Adobe Labs. Flash Player 10.1 public prerelease is an exciting release for Adobe and for you as a content creator. You are already able to build powerful and creative experiences and reach your audience whether they are on Microsoft Windows, Apple Mac OS, Linux, or Solaris. Flash Player 10.1 takes our cross-platform promise even farther, making it possible for you to continue the conversation with your customer when the computer is turned off and the laptop is closed.
With this first realization of the Open Screen Project, we have been working internally and with our partners to produce Flash Player 10.1 for Palm webOS, Google Android, Nokia Symbian, and Microsoft Windows Mobile operating systems. On these devices, you will be able to install and update Flash Player and view SWF content in the browser, just as you would on the desktop.
While working on bringing the full version of Flash Player to mobile devices, we've also been hard at work producing new features that you will be able to exploit on the desktop and mobile devices. This article reviews these new features and provides some insight into how Adobe has optimized Flash Player to run well on mobile devices.
As you explore the features in this section, think about how they can enhance your applications. Instead of waiting for the player to get out to everyone, start working with the features as early as possible. To Flash Player, a SWF built for Flash Player 10 and Flash Player 10.1 look the same. If you use conditions to expose the new features only if a user has Flash Player 10.1, you can add enhancements without requiring that a user have the absolute latest version of the player.
Community input
Since creating the public Flash Player bug and issue management system just before the release of Flash Player 10, we've been thrilled to see the level of participation from the community! We've been even happier to be to address requests from the community.
Global error handling
Around the same time as the bugbase launch, three different users submitted the same feature request, and each request quickly became so popular that this one feature is not just the top request but also the second and third most voted-for feature. In Flash Player 10.1 you will be able to write a single global error handler that will catch each error that is otherwise uncaught.
The global error handler offers two major advantages to the developer. The primary benefit will be to your development process. It is now possible to write a single function that collects data on all errors. You can send the data back to your server, even when the app is running on your users' machine with a release version of the player. It should be a good way to collect information on bugs that may be hard to find in your testing process.
The other benefit of the global error handler is really more of a side effect, but a pretty nice one. Right now, for users who have the debug player installed, a pop-up message box appears whenever an uncaught error occurs. By adding a global error handler, you can guarantee that the pop-up message box never appears.
Microphone access
In Flash Player 10, in direct response to requests being made by the community for better ways to control audio in Flash Player, we added two new APIs to extract wave data from MP3 files in binary form and send equivalent binary data into the sound buffer. This was immediately rewarded with a lot of great work exploring these capabilities.
New requests started coming in pretty quickly with great ideas for how the microphone data could be used to make entertainment, communication, and productivity applications. In Flash Player 10.1, you will now have access to the same sort of data that you get from MP3 files today—but coming from the microphone. For right now, this new API will be available on desktop computers only.
Developer features
As Flash Player 10 has passed 90% penetration, most of you have moved from experimental projects using the new capabilities to actually producing commercial work that takes advantage of the new expressive capabilities, video and networking enhancements, and new text engine.
User interaction
Until recently, computer user interfaces hadn't changed a whole lot. You have a keyboard and a mouse, or something equivalent. The mobile industry has shaken things up a bit, exploring new ways of interacting with mobile devices. A lot of this learning has been slowly moving back to the desktop, and we are eager to encourage these innovations by helping bring them into the mainstream. This is also a case where expanding player support to mobile devices will have real benefits, even for users who are most interested in the desktop.
Multi-touch has been one of the most exciting user interface enhancements to emerge in the last few years. With support on many mobile devices, and through support in Windows 7, Flash Player will use multi-touch gestures and give you low-level touch information for you to work with on your own to make custom, multi-touch interactions possible.
The type of multi-touch you use really depends on the type of application you build. So far, I'm finding that just about any mouse-based application can benefit from gesture support. This is where the operating system recognizes certain movements, such as a pinch, and translates this into a corresponding action, such as a zoom. In Flash Player, you will see this action and receive the data to be able to perform a zoom or whatever effect you want. You can even ask Flash Player what gestures are supported on the current operating system so that your application knows what to expect.
You've probably heard from Adobe before that when we build features for Flash Player, we look at how to provide an easy-to-use system and frequently pair it with a more powerful low-level system to let you build whatever you want. We've done the same for multi-touch with touch–point events. If you so choose, you can turn gesture support off and enable events that are very similar to mouse events. For each finger touching the screen, you get a separate event with data about where the touch occurred and other data, such as the coordinates of the bounding box of the touch—or even the pressure level of the touch—that may be provided by particular operating systems.
While you can certainly build your own gestures with this information, I have found that touch–point events are most commonly used in situations where you could use a mouse, but you really need multiple points of interaction. Examples of this would be a piano keyboard, where you want to play more than one key at a time, or a finger-painting application, where each finger could be a different color or brush.
Another user interface feature that has become popular on mobile devices is the accelerometer. This is the ability to know how the phone is being tilted or shaken. We've seen this used already to improve usability by sensing how the device is being held and reacting accordingly, but there are also many examples of applications, such as games, using the accelerometer as the main user control in the application. We will be providing both in Flash Player 10.1. You can use the screen orientation APIs to know how the browser is being oriented on the screen so that your application can react differently if needed. You can also take the raw data from the accelerometer and use it to create whatever controls or shake gestures you want.
Even though many laptops have accelerometers in them, the desktop operating systems that Flash Player works with have not provided APIs to access this data. As a result, accelerometer access will be a mobile-only feature in Flash Player 10.1. Of course you can always add code for accelerometers to SWF files even if they are going to run on the desktop. When that SWF file runs on a desktop or on a device that does not have an accelerometer, the events just won't be called.
Text and globalization
When the new text engine was introduced in Flash Player 10.0, we talked about typography and support for many different language types. We've continued working on the text engine in Flash Player 10.1 to make it generally better and faster. You will take advantage of most improvements without even knowing it by using the Text Layout Framework libraries that we released with Flash Player 10—now available as open source on Adobe Open Source.
In addition to the text layout and rendering improvements, you will have access to new globalization APIs. When you work primarily in one language, it is easy to overlook how differently many other languages deal with information. For example, there are different ways to lay out dates, times, and currency information. When you sort a list alphabetically, you may want a different result based the rules of a particular language. With the new globalization capabilities, Flash Player can use the values chosen in the operating system preferences to process text and lists. Also, you can use a particular format even if it isn't the one currently preferred in the operating system.
It is important to note that nothing that you have currently produced will be affected by this new feature. To use the globalization APIs, you will need to actively make use of them. While globalization APIs allow you to lay out information tailored for your user, some applications may choose to stay with a single way of displaying information.
Media playback
Today around 75% of online video is played back through Flash Player. This success has come through supporting this rapidly evolving and growing industry with new codecs, deployment options, and quality-of-service enhancements. In Flash Player 10.1, we are continuing to accelerate our new media capabilities, focusing on content delivery, interactivity, and protection.
Content protection
With Adobe Flash Access 2, you will be able to encrypt media files to protect the integrity of premium video content delivered to Flash Player. You can set flexible usage rules to control access to the media, such as limiting viewing to a given rental period.
Using industry-standard cryptography, Flash Access 2 and Flash Player 10.1 will provide a robust environment to protect content so that it remains safe from tampering or capture throughout its lifecycle. Flash Player also supports output protection, enabling content providers to specify requirements for protection of analog and digital outputs, providing additional safeguards against unauthorized recording.
For Flash Player 10.1, Flash Access 2 protected content playback will be supported on Windows, Mac OS, and Linux.
Stream enhancements
Video playback in Flash Player started as streaming video in Flash Player 6 and became progressive video in Flash Player 7. In Flash Player 10.1, you will also be able to load video through HTTP Streaming, which lets you take a video and convert it into many fragments that Flash Player can download individually with the help of new components. These fragments can be stored on any web server and do not require a specialized server. This solution provides a greater amount of random access to the video than progressive loading does. For the most efficient video deployment, however, full streaming remains the best solution.
When streaming through Adobe Flash Media Server, two new enhancements will be available to help ensure that the user is always watching the video, not "buffering now..." messages. If a user loses the network connection or switches among different networks, Flash Media Server and Flash Player will renegotiate the stream while the video keeps playing from the buffer. When the connection is re-established, the new connection continues filling up the buffer right where it left off, meaning no interruption in the video experience.
To give users even more control, Flash Player 10.1 lets them seek within the existing buffer without causing the player to rebuffer the video. This includes a new trailing buffer that keeps the video you've just watched in memory so that going back to see something you missed doesn't mean having to wait.
Live media
In Flash Player 10, we added support for RTMFP, a new peer-based protocol that enables new collaborative applications that let users chat, speak, use their webcam, and send data to other participants. In Flash Player 10.1, this becomes more granular with groups. Now, rather than sending messages between two users, the developer can establish groups of users, including one-to-one communication through a direct peer connection. By using groups, you can use the network more efficiently and make sure that data goes only to those who need it.
Designed for mobile
Flash Player 10.1 includes many features that you will want to explore by creating content using the new APIs. The majority of improvements going into this release are ones that you will never directly reference, but from which you will benefit all the same.
As we expand Flash Player from desktop computers to netbooks and mobile devices, we move into technology with very limited memory and processing resources. To deliver on the promise of "there's only one web" and bringing the high level of consistency in Flash Player to all platforms, there was only one thing to do: Flash Player had to become as optimized as possible to get out of the way of your content. We reduced its memory allocations and found innovative ways of sharing memory and taking advantage of specialized hardware whenever possible—all with the goal of giving your content the most memory and processor availability we can. Your content may have been optimized with a desktop computer in mind, but we will do all we can to overcome the technology gap and run your app as close to desktop quality as we can.
For video content, this means hardware acceleration. Flash Player will now decode and play back H.264 and AAC media through hardware whenever possible. When other video formats such as Sorenson and On2 VP6 are played back through software, Flash Player will help manage the frame rate of the SWF file to prioritize video playback. For progressive video, where storing large videos in memory would not be feasible, a circular buffer will automatically be used to load video progressively and, after playing part of a video, remove it from memory while the video is still playing and downloading. This buffer will be used when the progressive buffer reaches 4 MB of memory.
For vectors and images, Flash Player is similarly going to take advantage of hardware capabilities on mobile devices whenever possible. Vector drawing will now be tessellated (divided into triangles) and sent to the GPU. Images will also be accelerated when possible, in addition to memory enhancements when dealing with loading and unloading many images.
We have made many more subtle improvements that are all geared to make your content run well, but there are going to be cases where we will run into the reality that some content simply needs more memory than a mobile device can deliver. No matter how well optimized the system is, Flash Player is still a platform that lets developers write whatever type of application they want. In the end, each data type consumes a certain amount of RAM that can't be changed. For complex applications, there simply may be a need for more memory than is available.
Flash Player 10.1 adds a few new features to help keep you from bumping into the resource ceiling—and when you do, to make sure that it is not a bad experience for your users. If you have a web page with many different SWF files on it, Flash Player will start up as many player instances for which it has resources. When available resources become too low, new player instances will not start up, but will show a play button allowing a user to activate them. Also, SWF files that are off-screen will be kept off by default, and Flash Player can put SWF files to sleep when they are not needed and resume them later.
While the operation of these features is automatic, we have added developer controls to provide hints as to which content is the highest priority to be loaded. If you specify the priority of one SWF as higher than another in the HTML, it will be the first to activate. All other SWFs will wait until the HTML page completely loads, and then figure out their priority at that point. Likewise, if you have a SWF that is likely to be off-screen—but is critical to be active—then giving that SWF a high priority will make sure it remains active.
After all of this, if the system runs out of memory, Flash Player will shut down player instances to free up memory and prevent the player or browser from crashing. In many situations, the SWF file that was shut down will be replaced with a play button so that the SWF can be started again. In other cases, though, especially those where shared memory is the issue, all player instances will have to be shut down to prevent the application from becoming unstable. Even then, the page is preserved, and a refresh of the page will bring your SWF files back.
Where to go from here
Flash Player 10.1 brings Flash Player to mobile devices while bringing innovations and optimizations to the desktop that are a direct result of the move to mobile. As we launch the public beta of Flash Player 10.1, I strongly encourage you to become familiar with the features and look for ways to incorporate it into your existing projects that target Flash Player 10.
As you start to consider mobile as another platform that your content can reach, you will want to look at ways of not only optimizing your code, but giving thought to how users interact with their devices. The strongest mobile experiences are the ones that provide consistency with their desktop counterparts and take advantage of the new setting to provide information in a way that can be even more meaningful.
For more information:
