- ActionScript 3 is difficult to learnActionScript 3 is no more difficult to learn than any other programming or scripting language. If you are familiar with ActionScript 2, the language semantics are pretty much the same, although you will need to learn new ways of doing some common tasks. Because the ActionScript 3 APIs are more consistent, learning one new concept and API applies to multiple APIs, making it easier to use newly found knowledge to learn new features and functionality.
- ActionScript 3 is only for object-oriented programmersActionScript 3 can be used for both class-based, object-oriented programming, as well as timeline-based scripting. You can use it in whichever way is the most comfortable for you or makes the most sense for your project.
- Targeting ActionScript 3 reduces the Flash Player base that you can targetAs of December 2008, content targeted for Flash Player 9, the first version that supported ActionScript 3, can be viewed by 98.6% of computers on the Internet.
- You can’t write code on the timeline with ActionScript 3You can place code on the timeline just as you can with ActionScript 1 and 2.
- ActionScript 2 development is faster than ActionScript 3While some tasks can require more code in ActionScript 3 than in ActionScript 2, overall development and maintenance time should be the same or less than in ActionScript 2.0 due to improved debugging and better compile-time error catching. Basically, in some cases there may be more code, but it will be much easier to find errors
Monthly Archives: September 2011
Native extensions for Adobe AIR are a combination of ActionScript classes and native code that provide easy access to device-specific libraries and features that are not available in the built-in ActionScript classes.
Follow these steps to start building your first HTML/Ajax application on Adobe AIR:
- Download the Adobe AIR runtime. You need the runtime to launch AIR applications.
- Choose your preferred development environment:
Note: The AIR SDK includes all the tools you need to test and package AIR applications.
- Familiarize yourself with the core concepts of developing and deploying applications for the desktop:
- Dreamweaver users: Create your first HTML-based Adobe AIR application
- Adobe AIR SDK users: Create your first HTML-based Adobe AIR application
1. Keeping memory usage low
2. Reducing CPU usage
3. Storing sensitive data
4. Writing a “headless” application
5. Updating the dock and system tray icons
6. Handling network connectivity changes
7. Creating “debug” and “test” modes
8. Detecting when the user is idle
9. Managing secondary windows
10. Programming for different operating systems
1. Making an application platform specific
2. Not including update capability in an application
3. Changing the application ID after an app has been released
4. Not planning for offline support
5. Not thinking in AIR
6. Using custom chrome to create confusing interfaces
7. Not using the seamless install badge
8. Not encrypting sensitive data
9. Not preserving native interaction
10. Assuming performance doesn’t matter outside of the browser
The CameraRoll class lets you open an image browser so that the user can select a picture from the device media library. The CameraUI class lets you launch the device camera app so that the user can take a picture or video. In both cases the CameraRoll and CameraUI objects return the media via an event containing a media promise.
The options available for accessing the data in a media promise are different from one platform to another. For example, on Android, the media promise includes a
file property that references the source image file, but on iOS this property is always null—the source file is not accessible. The technique described in this article works on all platforms.
Getting the media promise
The first step is to request the image from either the CameraRoll or the CameraUI object. In both cases, you create the appropriate object, set up some event listeners, and then call the function that asks for the image. The runtime then returns the image in an event containing the media promise after the user has either chosen a picture from the device media library or taken a new picture with the camera.
The following code example sets up the event listeners necessary to handle the events that can be dispatched by a CameraRoll object and then calls the
browseForImage() method. When the user selects an image, the runtime calls an event handler function named,
This article focuses on the specifics of developing for Android, iOS, OS X, and Windows. Extensions are also supported on other platforms, including BlackBerry Tablet OS.
Extensions support three use cases: deep platform integration, legacy code reuse, and maximum performance.
Mobile devices offer an array of unique capabilities. Some are software, such as the sophisticated Android notification mechanism. Others are hardware, like the dual screens in the Sony S2 tablet.
While Adobe does not take a lowest common denominator approach when adding APIs to AIR, we do focus on creating APIs that can be used across multiple devices. Thus, it is unlikely that AIR will support a dual-screen API any time soon, since the API would be inoperable on nearly all devices.
Extensions can be used to add these capabilities to the runtime as needed. Extension authors can provide API mappings for platform-specific features, and can do so with as little, or as much, sophistication as they need.
Development shops with longer histories often have code from past projects that they would like to bring forward into new applications. In many cases, such code is even relatively portable, written in C or C++ and expecting POSIX APIs.
Regardless of the legacy code’s origin, the extensions mechanism allows the code to be wrapped up with an ActionScript API, and thus be used within an AIR application.
Extensions can be used to implement computationally intensive code that requires the highest possible level of optimization. Applications that leverage these compute kernels can implement them in extensions, and then invoke them from ActionScript.
Using native code enables several important optimizations. Firstly, and perhaps most obviously, the computationcan be coded in C or assembly for maximum performance. Second, native code can take advantage of multiple cores, which can provide a significant performance boost for parallelizable algorithms. Finally, native code may be able to take direct advantage of the GPU for off-loading certain calculations.
Two-tier application architecture
The introduction of extensions brings with it not just a new feature but a new way of writing applications.
Prior to extensions, applications have been written entirely in ActionScript. ActionScript is a capable language, well suited to user interface and core application logic. However, no language is well suited to all tasks, and ActionScript is no exception.
With extensions, applications can be written in two tiers: ActionScript on top, coordinating application and presentation logic, and native code below, providing deep integration, legacy code reuse, and performance.
This architecture is nothing new; applications have been written using this approach for decades, and with any number of languages used in combination. By enabling it in AIR, we allow its many benefits to be brought to bear on AIR application development.
Extensions as ActionScript libraries
An extension mechanism needs a model, that is, a methodology by which new APIs are bound into the runtime. AIR extensions are modeled as ActionScript libraries that contain native code.
This model allows the creation of a native extension to be separated from its consumption. Thus, extensions can be developed independently, published separately, licensed, sold, and so on as can any ActionScript library. Alternatively, they can be created and consumed by the same developer, possibly even for use with a single application.
While an extension necessarily includes native platform code, each extension is nonetheless intended to be useable across multiple platforms. That is, one need not build a separate extension to leverage a legacy library across each targeted platform. Rather, a single extension contains a platform-specific version of that library for each targeted platform.
Developing extensions in this model is a bit more work for the extension developer but enormously easier for the application developer. It allows an application developer to use a single, cross-platform ActionScript API throughout an application, and rely on the extension to provide the necessary platform-specific implementation. This, of course, is how the built-in ActionScript APIs work, and it’s this aspect of the extension model that makes them true extensions to the runtime.
Extensions separate creation and consumption of the extension. This separation makes it possible for developers to creative an extension not only for their own use, but also for others to use. This allows a developer to extend the runtime facilities for all other AIR developers. OEMs can also use this capability to extend the runtime in ways specific to their devices.
Before writing your own extension, it’s worth checking to see if the functionality you need is already available; perhaps someone else has done some of the work for you. Extensions created by other developers can be published through any of the normal means: code-sharing sites, blogs, and so on.
Note that access to device-specific capabilities implemented by device manufacturers will typically require obtaining the extension from the manufacturer itself. The manufacturer’s SDK or other developer information should contain the necessary information.
When acquiring an extension from external sources, think carefully about whether or not you trust that provider. As with externally sourced ActionScript code, the code in the extension becomes part of your application and runs with full application privileges. By incorporating an extension into your application, you take responsibility for any security issues that extension might contain.
On Android, two extension models are supported: Java archives for extensions developed with the Android SDK, and shared libraries for those developed with the Native Development Kit (NDK). Both are appropriate for some set of extensions; simply pick the one that best suits your use case. (One can, of course, use JNI to bridge between Java and native code on Android, should that also be necessary.)
On Android, resources such as images are compiled into each application and accessed via constants in the generated class R. This mechanism doesn’t support composition; there is only one instance of R available. Android extensions can include resources but, to work around this limitation, they must be accessed via an API provided by the runtime.
To include resources in your Android extension, first place them in the “res” subdirectory of the Android platform directory, using the same naming conventions and file structure as for a regular Android application. At packaging time, resources from all extensions are merged into the resources directory of the main application. In order to avoid name conflicts, extensions should use a unique prefix for their resources.
These resources will be merged, as will the code in the Java archive, into the compiled dex and resources files of the main application. They can then be accessed via the
FREContext.getResourceId() method, which takes the desired resource ID as an argument. In other words, instead of accessing an image as, for example, R.drawable.background_image, use
getResourceId( "drawable.background_image" ).
Note that this API is available only in Java, as the Android resource mechanism is a Java construct, not expected to be accessed by extensions using native Android development.
The Java FREContext class also provides, on Android only, a
getActivity() method that returns the main application Activity, which in turn is required by a variety of Android APIs.
iOS is a unique platform in that it does not permit applications to be composed of shared libraries. On iOS, extensions instead take the form of static libraries that are linked into the main executable at packaging time. (This has relatively little cost at packaging time, as AIR applications packaged for iOS are already compiled to ARM code and run through the linker.) This is why the static library (.a) that is in the extension package does not appear separately in the resulting application.
On the other hand, it’s conventional on iOS to keep resources, such as images, as external files that are separately loaded at runtime. Such resources can be bundled with the extension, at packaging time, will be copied into the standard application resources directory. This permits the regular NSBundle APIs to be used to load these resources, even from within the extension.
Note that the iOS implementation effectively flattens the namespaces used in both the executable (symbols in the static library) and in the file system (filenames of resources). As a result, extensions must take extra care to choose unique names in order to avoid conflicts. A prefix unique to the extension is typically sufficient. In particular, developers should take care not to use the default name Localizable.strings, as it would certainly conflict with the default Localizable.strings file used by the main application.