In Java FREContext is a class that you extend, which serves as a middleman between ActionScript and your native Java code.
You have to implement two things for your FREContext class to be properly initialized.
The first one, of course, is the constructor. The second one is an implementation of getFunctions(): Continue Reading
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. Continue Reading
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. Continue Reading
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:
In this article we are focusing on number 3: how events are sent from Java to ActionScript. Continue Reading
When you make a native extension using the AIR C API, your native code tends to have two parts:
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... Continue Reading
Do you remember the three ways that native code can send data back to ActionScript? Here they are for a quick revision:
We have mentioned the Extension Context a few times already:
I reckon it's time to look at what actually an Extension Context is. Agreed? Continue Reading
Do you remember when we talked about what an Extension Initializer and Finalizer are and what happens if they don't have unique names? We also saw what they look like in C. Today we are contrasting that with their Java versions. Continue Reading
The Extension Initializer and Finalizer are the entry and exit points to your native extension. They are also two of the ingredients that make your extension known to the world and make it distinguishable from other extensions in an app. This is why they need to have unique names. Their signatures however need to be exactly as prescribed by AIR. Today we look at what these are in the AIR C API.
Continue ReadingIf you've ended up on this page, you are probably already familiar with what goes into an ANE for iOS and an ANE for Mac OS. You also know that one of the main ingredients for these is the AIR SDK and its interface for these two platforms: the AIR C API.
Now, when you try to include that in your iOS or Mac OS native library, Xcode helpfully asks you whether you want the API's header file, FlashRuntimeExtensions.h, copied into your project. What should you do?
