AIR for Android using external jar files in an extension

If you use a third-party jar file (i.e. not part of the regular Android SDK), you have to merge that jar into your own extension jar file.

For example, suppose your main extension jar file is extension.jar and you are using code in external.jar. Then you can put the classes from external.jar into extension.jar using the Java jar tool:

jar -xf external.jar

This will extract the .class files into package folders. If the top-level package is "com", then you can add those to extension.jar with:

jar -uf extension.jar com 

Custom text entry in AIR for iOS

On Android, you can create your own text entry controls using the InteractiveObject class and the needsSoftKeyboard and requestSoftKeyBoard() APIs. This doesn't work on iOS for various reasons. However, with some recent changes to the runtime, it is now possible to fake it.

Instead of using an InteractiveObject, you use an off screen TextField object to control the soft keyboard and to get the text as it is typed.

Code below the break...

AIR extensions in Java -- FREBitmapData

The following function takes an FREBitmapData as an argument, creates a new copy and returns it. It isn't very useful, except how to demonstrate passing bitmap data back and forth.

Pay attention to the acquire() and release() calls on FREBitmapData objects. When you have called it on one object, you CANNOT call any methods that are backed by an ActionScript object of ANY object. This includes creating new FREObjects (including FREBitmapData, FREByteArray, and FREArray), getProperty(), setProperty(), or callMethod(). As the words in all caps indicate, I found this rather surprising. You might too. So acquire, do it, then release. If you fail to release, say you hit an exception, then the extension gets into an invalid state. Hence, I release the bitmaps in a finally block. I imagine that this can be inconvenient in more complex functions.

AIR extensions in Java for Android Part 5 -- debugging the Java code

I'm sure there's more than one way to do it. This is just one way, using Eclipse/Flash Builder and the Android DDMS plug-in. I've tried the following on a Mac, but haven't tried on a PC yet.

AIR extensions in Java Part 4 -- using the extension

To use the extension, you reference the ANE file the same way you reference a SWC. Flash Builder 4.5.6 lets you include ANE files using the project dialog (there's a new category for ANEs). So if you have 4.5.6, you are set. If not, you'll have to do it manually.

AIR extensions in Java for Android Part 1 -- Creating the Java code

To create the Java part of an AIR native extension, you implement the FREExtension interface, create a context class extending FREContext, and create one or more functions by implementing the FREFunction interface. Along the way, you'll become friendly with the FREObject class. Finally, you export the code as a Jar file.

AIR extensions in Java for Android Part 2 -- Creating the ActionScript part

Now that we have a JAR file containing the "native" Android code, we can create the ActionScript code that goes with it. The ActionScript part of the extension serves as a go-between between the Java code and the AIR application.

The ActionScript part of an extension is an ordinary library class. The only unique part of it is that to access the native code, it creates a ExtensionContext object. The library class uses this extension context object to call functions in the Java part of the extension.

In addition, to the Java JAR file and the ActionScript library, a native extension includes an extension descriptor file. This descriptor is used by the ExtensionContext code in the runtime to look up the proper Java classes.

AIR extensions in Java for Android Part 3 -- packaging the ANE

The AIR native extension is packaged in an ANE file. This is similar to an AIR file and is also created with the AIR ADT utility.

Depth and stencil testing in Flash 3D

Do scissor test – if fail discard output fragment and stop, else continue

Do depth test

If depth test passes

{

                If depthMask == true, then update depth buffer = source depth;

                Do stencil test

                if stencil test passes

                {

                                Update stencil buffer, according to actionOnBothPass  parameter, stencil reference setting

                                Send output color to blend function

                }

                else (stencil test fails)

                {

                                Update stencil buffer, according to actionOnDepthPassStencilFail parameter, stencil reference setting

                                Discard output color

                }

}

else //depth test fails

{

                Update stencil buffer, according to actionOnDepthFail parameter, stencil reference setting

                Discard output color

}

AGALMiniAssembler

Where can you find the AGALMiniAssembler and ProjectionMatrix3D classes?

Right here: https://github.com/flashplatformsdk/Flash-Platform-SDK

3D graphics in an HTML-based AIR application

You can use the Stage3D and Context3D classes to render graphics in an HTML-based AIR app. One issue, though, is that the rendering viewport is drawn below the Flash Display list. Well, the HTML display is part of that display list, so by default, your HTML display will obscure your rendering viewport.

There are a couple of solutions:
You can set the background of the HTML object to be transparent. This allows the rendered stuff to peek out from behind any text or other items on the page. See AIR docs.

The other thing you can do is to create a new NativeWindow to display the rendered content. Don't use HTMLLoader.createRootWindow(), since this will create a window that has an HTMLLoader in it. instead, use:
var renderwindow = new air.NativeWindow( new air.NativeWindowInitOptions() );

(Of course, you will want to set non-default window options in many cases.)

More on reading exif data

If you are displaying an image from the camera roll, it helps to read the orientation from the exif data. iOS stores the image in a standard way within the jpeg file and expects apps to read the orientation when displaying that image. Other media libraries orient the image in the file already and don't record orientation data. A third possibility exists, that the image encoder both orients the image and records orientation -- but I haven't checked that out yet. On my three Android devices, two didn't record an orientation. When I get a chance, I'm going to write something that will read the exif data and rotate the image appropriately.

Reading exif data on iOS (Adobe AIR)

When an AIR application gets an image from the CameraUI or CameraRoll class on iOS, the device returns a file that obeys the JPEG JFIF standard rather than the JPEG Exif defacto standard. While these standards are very similar, they each make one incompatible requirement -- that their format marker tag go first! In practice, at least for iOS images from the media library, this just means that you have to expect that the JFIF marker might be there when you are looking for the exif data.

At least one popular ActionScript exif reading library, jp.shichiseki.exif doesn't expect the JFIF marker and fails to find the exif data. The fix is easy, though.