Posts tagged "native extensions"

SWC and SWF files in native extensions

I’d like to highlight the role of your ActionScript library — a SWC file — in native extensions. And while I’m at it, I’d like to discuss the role of  the SWF files that the SWC file contains.

You’ve read it before: A native extension is made of two parts: The ActionScript side and the native code side. Here we are just talking about the ActionScript side.

You build the ActionScript side of your extension into an ActionScript library that is a SWC file. The SWC file is an archive file (think ZIP file) that contains your ActionScript classes and other resources, such as its images and strings.

Suppose your extension targets different platforms — for example, both iOS and Android. If  your extension requires a different ActionScript implementation for each platform, create a different SWC file for each platform. A best practice  is that all the ActionScript implementations have the same public interfaces. However, even if all the ActionScript implementations have the same public interfaces, what happens inside the implementation can vary by platform. If so,  you’ll have to create multiple SWC files.

The SWC file comes into play when you package your extension into an ANE file. To do the packaging, you use the ADT command-line tool. You specify a SWC file in the -swc option of the ADT packaging command. For example:

adt -package <signing options> -target ane MyExtension.ane MyExt.xml
    -swc MyExtension.swc
    -platform Android-ARM -C platform/Android .
    -platform iPhone-ARM -C platform/ios .
    -platform default -C platform/default library.swf

The SWC file contains a file called library.swf.  It is the main SWF file of your ActionScript library. ADT automatically puts the library.swf from the SWC file into the ANE file. When an AIR
application uses a native extension, it includes the extension’s ANE file in its library path so that the application can compile. In fact, the application compiles against the public interfaces in library.swf.

Let’s say, as discussed above, you have different SWC files for each platform, but they all share the same public interfaces. In this case, it doesn’t matter which of the platform-specific SWC files you use in the -swc option of the ADT command. It doesn’t matter because the library.swf file in the SWC file is used only for application compilation.

Application execution is another matter. Take a look again at the above ADT command.  Each platform directory (platform/android, platform/ios, and platform/default in this example) specifies the files to include in the ANE package. The -C option tells ADT to make the specified directory the current directory. ADT puts the files and directories that follow into the ANE package. Each platform directory has a library.swf file in it.  For the iOS and Android platform directories, the ‘.’ indicates that all the files in the current directory are to be packaged into the ANE. The files include the library.swf as well as native libraries.

Therefore, you must put the appropriate library.swf into each platform directory. When you have a different SWC file for each platform, get the library.swf from the appropriate SWC file. You can extract the library.swf from a SWC file with extraction tools such as WinZip.  When the application executes and calls your extension class, this is the library.swf file that runs.

Note the following about the library.swf file:

  • ADT requires that you provide a main SWF file named library.swf for each platform. When you create a SWC file, library.swf is the name of the main SWF file.
  • The library.swf file for each platform is different if your ActionScript side has platform dependencies.
  • The library.swf file for each platform is the same if the ActionScript side has no platform dependencies.
  • The library.swf for each platform can load other SWF files that you include in the platform-specific directory. These other SWF files can have any name.

Detailed documentation about creating extensions is at Developing native extensions for Adobe AIR.

For more information about using a native extension in your AIR application, see Using native extensions in AIR applications.

Jackie Levy, Content and Community Lead

New to AIR Native Extensions?

Looking to get started using Native extension? Here’s a quick primer with links to more resources. What the heck are AIR Native Extensions?

Using Flash Builder 4.5.1 to compile an AIR App that uses a native extension

To use a native extension in an AIR application, you have these three tasks to do:

  1. Declare the extension in your application descriptor file.
  2. Include the ANE file in your application’s library path.
  3. Package the application.

This post is about Step 2 with regard to Flash Builder 4.5.1 projects.

Native extensions are packaged in ANE files. To compile an AIR application that uses a native extension, include the ANE file in the Flash Builder project’s build path.

In Flash Builder 4.5.1, do the following steps:

  1. Change the filename extension of the ANE file from .ane to .swc.
  2. Select Project > Properties on your Flash Builder project.
  3. Select the Flex Build Path in the Properties dialog box.
  4. In the Library Path tab, select Add SWC….
  5. Browse to the SWC file and select Open.
  6. Select OK in the Add SWC… dialog box. The ANE file now appears in the Library Path tab in the Properties dialog box.
  7. Expand the SWC file entry. Double-click Link Type to open the Library Path Item Options dialog box.
  8. In the Library Path Item Options dialog box, change the Link Type to External.

Now you can compile your application using, for example, Project > Build Project.

The part about changing the ANE file’s file extension from .ane to .swc is not strictly necessary. In step 4 above, when you browse to find the file, in the “Choose a SWC file” dialog box, you can change the setting of the Files Of Type drop-down field. It is set by default to *.swc.  Change it to *.*.

Now you can choose the ANE file. Then, continue with step 5 above.

However, when you build your Flash Builder 4.5.1 project with an ANE file rather than a SWC file, you get compiler warnings. The first warning is on the import statement for the extension class, saying that the extension could not be found. Successive warnings occur when you use the extension’s classes.

But interestingly, the application still builds and runs successfully.

Note: Adobe recommends using the next version of Flash Builder for developing native extensions for Adobe AIR. Sign up now to get access to the prerelease of Flash Builder 4.6.

For more information about using a native extension in your AIR application, see Using native extensions in AIR applications.

Detailed documentation about creating extensions is at Developing native extensions for Adobe AIR.

Native extensions: When to call FREContext instance methods

Here’s a little tidbit about developing native extensions for Adobe AIR for Android devices using the native extension Java API.

The main point: The call that your extension’s ActionScript side makes to ExtensionContext.createExtensionContext()  must return before the native side of the extension can call methods of the instance of your class that extends the  FREContext class.

Let’s break that down.

The AIR runtime instantiates your FREExtension instance the first time the  ActionScript side of your extension calls ExtensionContext.createExtensionContext().

The sequence of calls to your Java implementation of the FREExtension class is:

  • FREExtension implementation class constructor
  • initialize()
  • createContext()

In createContext(), you return an instance of your class that extends the FREContext class.

But be careful. The FREContext object can only be considered fully constructed once the ExtensionContext.createExtensionContext() ActionScript method has returned.

Therefore, do not call any methods of your FREContext instance until after the ExtensionContext.createExtensionContext() ActionScript method has returned.

For example, you might be tempted to call your FREContext instance’s getActivity() method in its constructor. Don’t do it. You’ll get an IllegalStateException if you do.

Instead:

  • Provide an initialization method that the ActionScript side can call after ExtensionContext.createExtensionContext() returns.
  • In the initialization method, call your FREContext instance’s getActivity() method.

The Gyroscope and Vibration examples do exactly that. See them at http://www.adobe.com/devnet/air/native-extensions-for-air.html.

Detailed documentation about creating extensions is at Developing native extensions for Adobe AIR.

To use a native extension in your AIR application, see Using native extensions in AIR applications.

Pen tablet native extension example

Sean Fujiwara recently posted a native extension for Adobe AIR at AIR 3 Native Extension Example – PenTablet.

This extension lets an AIR application get the pressure sensitivity data from a Wacom Intuos 4 pen tablet on Windows 7.  It’s a good example of a Windows native extension that handles Windows messages and uses a native library — in this case, the pen tablet’s library.

Sean also provided another native extension for Windows that encodes a bitmap into BMP, JPEG, or PNG format using Microsoft .NET Framework 4.  See  AIR 3 Native Extension Example – ImageProcessor.

You can see more examples and tutorials of native extensions at the Adobe Developer Connection page http://www.adobe.com/devnet/air/native-extensions-for-air.html

Detailed documentation about creating extensions is at Developing native extensions for Adobe AIR.

To use a native extension in your AIR application, see Using native extensions in AIR applications.

Native JSON API released

The Flash Player 11/AIR 3.0 (Serrano) release fulfills a long-standing developer request by introducing a native ActionScript JSON API. With this API, you can import and export objects using JSON encoding. Native JSON functionality correlates closely with the ECMA-262 (5.1 Edition) specification for JSON. Because of this, its syntax is somewhat different from the third-party as3corelib JSON library. You can find out more about these differences in community member Todd Anderson’s blog posting at the Infrared5 company blog.

The API itself consists of a top-level class named JSON. This class provides two methods: stringify() for encoding, and parse() for decoding JSON strings. The JSON feature also supports toJSON() member functions in any class. Visit the official documentation at these locations:

ActionScript 3.0 Reference
ActionScript 3.0 Developer’s Guide

Native extension detailed documentation

With the announcement of AIR 3 and its new native extension feature, detailed documentation about using Native Extensions for Adobe AIR is available now at:

Developing native extensions for Adobe AIR

You’ll find:

– Overview and conceptual information

– How to use the C and Java native extension APIs, plus reference pages

– How to package your native extension using ADT

– Details on the Extension Descriptor file

– Information on using Android shared libraries, and using resources on Android and iOS

If you are using a native extension in your AIR application, see:

Using native extensions in AIR applications

For lots of examples and tutorials, see this Adobe Developer Connection page:

http://www.adobe.com/devnet/air/native-extensions-for-air.htm

 

 

iBattery native extension for Adobe AIR

Todd Anderson just posted “iBattery”,  a great example of a native extension for Adobe AIR on his blog.

His iBattery extension allows an AIR application to get the status of the battery of an iOS device — from ActionScript. Todd also gives a nice tutorial highlighting some of the details that go into creating a native extension.

You can see more examples of native extensions at the Adobe Developer Connection page http://www.adobe.com/devnet/air/native-extensions-for-air.html

Examples of Native extensions for Adobe AIR

Looking for some examples of native extensions for Adobe AIR?

Please see Native extensions for Adobe AIR on the Adobe Developer Connection.

This page lists three sample extensions developed by Adobe to help you learn how to create your own extensions. With native extensions, an AIR application developer, using ActionScript, can take advantage of platform-specific and device-specific native capabilities.

The examples include:

  • Vibration — From ActionScript, an AIR app can make an iOS or Android device vibrate.
  • Gyroscope — From ActionScript, an AIR app can access the gyroscope data of an iOS or Android device.
  • NetworkInfo — From ActionScript, an AIR app can get information about the network interfaces of an iOS device

Obviously, “from ActionScript” is the key. The extension’s ActionScript code interfaces with the extension’s native code, so that the AIR app developer only has to use ActionScript.

The ADC page also includes a link to a great example by Sean Fujiwara. His example uses .NET to efficiently  transcode BitmapData objects into .bmp, .jpg, and .png formats.  We hope to add more examples from the community soon.

 

Native extensions in AIR 3

The Adobe AIR 3 Release Candidate is available, and includes this new feature: Native extensions for Adobe AIR.

Until now, native extensions were available on AIR for TV, but not for AIR on desktop or mobile devices. Now you can create an ActionScript library that can execute native code on all these devices. This means an AIR application developer, using ActionScript, can take advantage of platform-specific and device-specific native capabilities.

We’ll blog here about documentation and examples as they become available. In the meantime, you can read more about it in this Adobe Developer Connection article:  Extending Adobe AIR.

And get the AIR 3 Release Candidate download to get started.