Creating a native extension library for OpenFL (Haxe)

Foreword

If you are thinking about creating mobile applications, but do not know where to start, you have enough time to experiment and learn new things, then let me recommend you to choose the haxe programming language as a tool. You may have already heard about him and you may have heard of him as a substitute for Flash. This is not entirely true, and you can even say quite differently.

Yes, the haxe standard library has a subset of classes and functions that are organizationally similar to the actionscript 3 standard library. But this does not prevent the creation of applications for native platforms, such as Linux, Windows, Android, Mac, iOS.

When creating applications for native platforms, the capabilities of the standard library are not enough and you have to search for third-party libraries or develop your own. I went the second way and for the current project (a small game similar to TripleTown in mechanics) I developed a library for working with Flurry, Localytics, GooglePlay Game Services and some other services.
')
In the translation below, it describes how to begin if you want to create an extension library for haxe and the OpenFL framework (formerly NME ), in particular. The author of the original article Laurent Bédubourg.

Creating a simple extension for OpenFL

Until recently, I used Adobov tools for publishing applications on iOS and Android.

OpenFL is gaining momentum and seems to have reached a sufficient level of maturity, so I decided to use it for my next project.

Using high-level libraries is cool, but sometimes native functions are needed, which are described in the documentation, but are not available from libraries. To solve this problem, there is Adob's ANE and he, I must say, does it well.

But how do we get the same features in OpenFL? Below I will describe my attempts to cope with this task.

As follows, using the template from OpenFL, you can create an extension:

$ openfl create extension TestExtension $ cd TestExtension $ ls -1 TestExtension.hx #    haxe    haxelib.json #    haxelib include.xml #  , openfl     #    ndll/ #         #  project/ #    

After compiling the extension for all supported platforms, the corresponding native libraries will appear in the ndll / directory.

 cd project/ haxelib run hxcpp Build.xml haxelib run hxcpp Build.xml -Dandroid haxelib run hxcpp Build.xml -Diphoneos -DHXCPP_ARMV7 haxelib run hxcpp Build.xml -Diphonesim 

Now we need to register our extension in haxelib:

 cd .. haxelib dev TestExtension `pwd` 

To make sure that the creation of the extension was successful, do the following:

 mkdir TestApp cd TestApp 

Create project.xml:

 <?xml version="1.0" encoding="utf-8"?> <project> <meta title="TestApp" package="me.labe.testapp" version="1.0.0" company="Laurent Bedubourg" /> <app main="Main" path="Export" file="TestApp" /> <source path="." /> <haxelib name="openfl" /> <haxelib name="TestExtension" /> </project> 

Main.hx:

 class Main { public static function main(){ var t = new flash.text.TextField(); t.text = Std.string(TestExtension.sampleMethod(16)); flash.Lib.current.addChild(t); } } 

Compile and test as follows:

 openfl test project.xml cpp openfl test project.xml android openfl test project.xml ios -simulator openfl test project.xml ios 

Everything works great on Mac and on Android.

I still need to figure out how to use external libraries, how to structure source code for various platforms, but this is already a good start: creating an extension for OpenFL is simpler than an extension for Adobe Air (ANE).

Unfortunately, I still have linking errors for iOS, and when I deal with them, I will update this article.

In my repository on github I posted the source code of the example from the article. And in Joshua Granik's blog, you can find an article on creating extensions.

Addition : It seems that my problems with linking under iOS are related to the mismatch between the registers of the names of the imported functions. Once this error is corrected, you can experiment with lower case extensions without any problems (as is supposed under iOS).

Addition : Definitely, this is a problem of the mismatch of the names of imported functions. The OpenFL repository contains a description of the error, so that you can independently track when it is fixed.

Addition : Joshua Granik has fixed the extension pattern, so now everything will work fine out of the box *.

* from the translator - I left all the additions in the translation with the intention that they could be useful to someone in case of such errors.