Posts in Category "Native Extensions"

Multiple ANEs and conflicting resources

AIR 4.0 and later supports packaging of multiple JAR files in an ANE. That allows packaging of third party libraries and their corresponding resources an ANE.

The resources bundled in an ANE or any other library in the ANE can be accessed by R* method, and this document provides all the details.

This post talks about a scenario where multiple ANEs are used in an app and if two or more of the ANEs use same JAR file as a dependency (packagedDependency).  It is not possible to create such an app, and the packager fails with following error -

unexpected failure: duplicate entry: /R.class

This is expected because when the packager picks up resources of all the ANEs, and finds that two or more ANEs are using a same resource, the step to convert *.java to *.class file fails with a duplicate entry error. This is something which the packager cannot resolve by itself, and the developer has to step in.

If you face this packaging error, you need to remove the common JAR from all of the ANEs but one, to ensure that the packager finds a single copy of every JAR file as input.

Here is an example -

Suppose there are two ANEs used in an app i.e. example1.ane and example2.ane. Both of them use a common library, say commonlibrary.jar, and its resources, say, common-lib-res. If you try to package the app with these ANEs, ADT throws an error -

unexpected failure: duplicate entry: com.common.example.lib/R.class

To resolve the issue, you need to follow these steps (eg. is for a Mac) -

1. Copy example1.ane in a temp folder.

2. Unzip example.ane (run command ‘unzip example1.ane‘)

3. Remove the commonlibrary.jar from the package (i.e. from unzipped content of the ANE).

4. Remove the corresponding resources of commonlibrary.jar (i.e. “common-lib-res“) from the package.

5. In platform.xml, delete the entry for commonlibrary.jar from the tag and delete the entry of the common-lib-res from the tag.

6. Zip back contents of package to ANE -

  • zip –r –D example1.zip META-INF catalog.xml library.swf mimetype
  • rm –rf example1.ane META-INF catalog.xml library.swf mimetype
  • mv example1.zip example1.ane

Use this new temp/example1.ane and existing example2.ane to package the APK file. You should not see any packaging or runtime error now.

Hope that helps! :)

Exception Support in iOS Native Extensions

Up to AIR 3.3, it was not possible to handle exceptions inside the Cocoatouch Static Library in an ANE. AIR 3.4 onwards, it is possible to use the Objective C @try-@catch-@finally syntax inside one’s native library. The native developer can now also use C++ try-catch blocks successfully. The only thing to keep in mind while using exceptions in native code on iOS is that the exceptions should be handled inside the ANE itself. The AIR runtime will not catch the exceptions thrown by extensions.

You can download the latest AIR SDK with support for handling exceptions in a Native Extension  from  http://labs.adobe.com/technologies/flashplatformruntimes/

AIR iOS app packaging with Flash Tooling and AIR 3.3

If you are using iOS Native Extensions with AIR 3.3, you may find that your application does not get packaged when using Flash Builder/Flash Pro. This is because, when using native extensions, linker warnings are not suppressed, and Flash Builder/Flash Pro are not able to handle such large number of warnings, specifically on Windows. This issue will be fixed in the upcoming release of Flash Builder and Flash Pro.

In order to overcome this issue, you can include the platform descriptor file (platform.xml) in your ANE, which contains the following linker option:

<option>-w</option>

A sample platform descriptor file will look like this:

<platform xmlns="http://ns.adobe.com/air/extension/3.1">
 <sdkVersion>5.0</sdkVersion> 
 <linkerOptions> 
 <option>-w</option> 
 </linkerOptions> 
</platform>

Then, at the time of packaging the ANE, include the ADT switch -platformoptions, providing the path to the platform descriptor file. For example,

Continue reading…

Commonly faced issues while developing Native Extensions for iOS

Developing  ‘Native Extensions for iOS’ requires knowledge of both native iOS code (C/C++/Objective C, XCode, static libraries etc) and AS3 code. So, it’s not unusual for developers to face issues. I have tried to list some of the most common roadblocks for native extension developers on this page.

1. extensionID

An extension is recognized by its extensionID. Thus, one should try to keep it as unique as possible, as an application developer might want to use more than 1 native extension in his application. Having the same name will create conflicts and the application won’t get packaged or work as expected.

a. Same extensionID should be used in the extension.xml, application.xml and the AS3 Class where ExtensionContext.createExtensionContext() function is called.

b. Using “nativeExtension” as the extensionID isn’t really a good idea. Prefixing the extensionID with com.developerName is probably the way to go.

Continue reading…