Well, good for you! For one, it’s a lot more straightforward to debug the native part of your ANE code on Windows than on the other platforms. I’ll show you how in a future post.
For now, let’s focus on what you have to work with and what you need to do.
The two components that you have to make yourself are:
- an AIR library, compiled as a .swf file;
- a native C, or C++ library, compiled as a .dll (Dynamic-link library).
The third component is provided for you and it helps your two libraries talk to one another:
- the AIR C API for Windows.
The AIR library
Your AIR library is a Flex library project, which contains an instance of flash.external.ExtensionContext. ExtensionContext is the class that provides an ActionScript interface for you to make calls to and receive messages from your DLL.
The AIR C API
The AIR C API is the layer that sits between your ActionScript and C/C++ code. It translates the ActionScript calls you make to ExtensionContext into C and allows you to send events and data from C back to ActionScript.
The AIR C API is part of Adobe’s AIR SDK and is implemented as a static library: FlashRuntimeExtensions.lib. This and FlashRuntimeExtensions.h header are the two files you will have to include in your native library (see below).
The native library
Your native library will be a DLL that uses the AIR C API, which I’ve put in red on the diagram below. It can also include any number of Windows SDK or third party libraries.
The ANE package
Once you have an AIR library and a DLL which uses the AIR C API, you package them together into an .ANE file, using Adobe’s ADT tool. I’ll show you how in a future post.
- What goes into an ANE for iOS?
- What goes into an ANE for Android?
- What goes into an ANE for Mac OS?
- Prepare your ANE to be used in an app
Over to you
Are you a seasoned Windows developer who is looking into Adobe AIR and cross-platform programming? Or are you an ActionScript fan who would like to dig deeper on Windows?
What would be useful for you to learn next? Tell us in the comments below.