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.
You need an Extension Context
Your native code and AIR communicate through an Extension Context. Before your ANE makes any calls into native code, it needs to create one of these. You can have more than one context instance at a time, but the minimum you need is one.
Initializing the Extension Context
When the Extension Context springs to life, the first thing AIR usually needs to know from it is:
“How many functions are you making available to me? And I need names, Sir!”
A bit stern, but that’s the context intialization in a nutshell. The implementation of that looks different, depending on which native language you are using:
- In C you have a single function to implement: FREContextInitializer.
- In Java, it’s a class constructor and a special method, sternly called getFunctions().
Disposing of (finalizing) the Extension Context
There is usually less work to do when your Extension Context is being destroyed. You still need to provide the necessary implementations: FREContextFinalizer in C and a class destructor in Java. This is your chance to tidy up any context-related data or resources you might have allocated during the initialization phase.
Next, we’ll have a look at the Java equivalent of the context initialization and finalization.
Then we’ll attempt to put some order in this bunch of initializers and see a graphic of how this happens and who calls who.
After that it will be the finalization’s turn: we’ll look at the order of calls when an extension is unloaded.
Over to you
OK, let us settle this once and for all: C or Java? Java or C?
Give your vote and arguments below.