Hi,
I’m looking for building a native android lib from an openfl code.
I would like to create a new android application from Android Studio, import my library MyLib, create a component MyLib.Square that displays a pretty yellow square and control it with something like myInstance.doSomething()
Is it possible ?
How to configure my FlashDevelop projet to do that ?
Thanks
Hi!
In the “next” architecture for OpenFL, OpenFL itself is portable, and could be compiled to either C++ or Java for use as a module in a larger Android application.
OpenFL needs to run on Lime, and this is where the integration points for different architectures come in – currently Lime is assuming you will build an entire application (not a module), so it handles window creation, accessing a GL context and other features that may not be as appropriate nested within a larger project.
I think that the “cleanest” way to integrate OpenFL in this way might be to use Java, assuming the Haxe Java target is up-to-snuff (which I increasingly hear it is). It would not be difficult to add Java support to Lime.
Is this something you would be interested in helping with?
Mmmm, thank you Joshua.
So, where can i find the ‘next’ release ? 
I have 3 days to test OpenFL as a POC for Android and IOS.
If i understand Lime is using on top of Haxe to build and package app to IOS and Android, but cannot build module.
If can’t use Haxe to target c++ and java, i need something like NME or OpenFL.
Can i do it without using Lime ?
NME was used within a host iOS or Android application, I believe that functionality is still there in the project. With the Lime reboot, the primary test-case has been a full application, using SDL2 on the desktop and (planned) SDL2 on mobile as well.
Lime should be portable, it works over Flash and HTML5 in addition to native – Flash and HTML5 (obviously) do not require a C++ component. In a similar fashion, I expect it should be possible to allow Lime to compile to Java, and to work with extern classes to play nice with the JVM for the some of the same features.
For example, instead of getting OpenGL from a C++ binding or referencing WebGL APIs on HTML5, it could reference Java GL.