Calling native functions from ActionScript

So you have started writing an AIR Native Extension (ANE). You've got a pretty good idea of how AIR loads and unloads it from memory and know that you need an Extension Context to tell AIR about what functionality your native code exposes. The infographic in this article will show you the mechanism of making native function calls from ActionScript. Read More

Categories: AIR Native Extensions.

Loading your ANE – order of operations

A native extension that you app uses only gets loaded in memory if the app makes a call into it. We have so far covered a couple of steps that happen at that point: extension initialization and extension context initialization. Let us now look at the process of loading the ANE in terms of what order these calls are made in and which parts of the system make them. Below is a diagram that illustrates what happens when an iOS ANE is loaded in memory: Read More

Categories: AIR Native Extensions.

FREContextInitializer and FREContextFinalizer in C

So you already know that, in order to make calls from your AIR app into native code, you need an Extension Context. One of the Extension Context roles is to tell AIR what native functionality is available for calling from ActionScript and this happens during the Extension Context initialization. This post will show you how this is done in C - you can use that in your C, C++ or Objective-C code. Read More

Categories: AIR Native Extensions.

Native Extension Context Initializer and Finalizer

Do you remember the first call AIR makes when your AIR Native Extension is loaded in memory?

It's not a test. I'll even let you have a sneak peek, in case you've forgotten: when your ANE is first loaded, AIR calls its Extension Initializer: have a peek at what it looks like in C and in Java. Shortly after that the Extension Context is created. Read More

Categories: AIR Native Extensions.

How to send events from Java to ActionScript

When we looked at how native code and ActionScript communicate in a native extension, we saw that native code is mostly called and talked to and has a limited number of ways to respond or send data back. These are:

  1. Returning a FREResult object from a call to FREFunction.
  2. Using output parameters in a FREFunction.
  3. Sending an event to ActionScript.

In this article we are focusing on number 3: how events are sent from Java to ActionScript. Read More

Categories: AIR Native Extensions.

Keeping your C native code reusable and independent of AIR

When you make a native extension using the AIR C API, your native code tends to have two parts:

  • one that's concerned with exposing functionality in a way that AIR can call, in other words, dependent on the AIR C API;
  • functional part, which deals with the platform-specific stuff. This part of your code doesn't (and shouldn't) care about whether it's used in an AIR native extension, a purely native app or something else.

Ideally you want to keep the dependency between these two parts one-directional: the AIR-concerned part should depend on the functional part, but the functional part should not know about and depend on AIR. If you decide to reuse your, say camera or speech recognition functionality, in another project that's not AIR-related , you don't want to force that to include the AIR C API.

So, what happens if you need to dispatch an event from the functional part of your code? Say, the camera refused to start or the speech processor is ready with results and you want you alert AIR to this... Read More

Categories: AIR Native Extensions.