SDK; native library sdk api

[ruby0x1]

I have been designing and implementing a way to use native code on mobile and desktop platforms. For a few of the native features that are in the core (like this) they will instead be used to test the sdk at first.

The SDK will support Android jar/NDK plugins and iOS native objc/c++ plugins.
Part of the system is already in place (in fact this is how snow is loaded on mobile!) but there are things to consider for making the SDK easy to use.

The basic approach is simply including a snow_sdk.h file in your plugin, and it will give you all snow system events, and allow you to dispatch events, etc.

[kevinresol]

Are there any updates or ETA for this?

[ruby0x1]

A large part of the need for this is replaced by the fact there is no longer a native backend in snow, and the native externs from hxcpp existing since haxe 3.2. See for instance linc_icloud.

With regards to the "snow plugin SDK" specifically: it could be viewed as 3 things in one name. The native sdk header to get access to snow internals (no longer necessary), control over the snow api from native (no longer necessary), and a way to handle plugins in general. One part was implemented in snow alpha-2.0 recently (the extensions stuff, it's a work in progress so I can't document it right now), and the second part is underway which relates more to hxcpp native plugins in general.

The goal is not to create snow specific versions of all the common plugins but to better serve all of the haxe/hxcpp users, which has been the goal of snowkit as a collective all along. The first primary test of how that might work in practice was done in Westport, which had both Game Center and Google Play services in the game just using hxcpp externs - the tricky parts being the framework specifics (especially on android). We are taking this practical information backwards into something more useful for everyone.

We are working on this atm, and since it affects more than just snow, doing it right is quite important. Just so it's clear, it's definitely being resolved in a neat way, just that I don't think any (more) false starts on native mobile extensions (which I guess is why you're asking?) is of any good to anyone just yet. I'd rather it be done well once and carry forward with it a complete solution.

[kevinresol]

Yes I am asking for native extensions for mobile and especially Android. Because with linc I think any c++ based platforms would be fine (mac, windows, linux, even ios). But the trickiest part is Android, since most SDKs are written in Java instead of NDK. So in Westport did they use the NDK version of Google Play or Java? But anyway, I am glad to hear that this feature is at least not being abandoned. Keep up the good work, thanks!

Edit: I just found that I missed the words "just using hxcpp externs" regarding Google Play.

[ruby0x1]

Actually it uses the Java lib via gradle dependency! I tried the gpg-sdk (and got pretty close) but it was crashing randomly somewhere inside their code and I was pressed for time. the gpg-sdk is actually feasible if it would work correctly. I think the issue related to thread safety, but I haven't looked into it yet.
The java one also uses a different type of JNI extern with macro magic, which is something else that will come soon along with the other stuff.

For iOS you just need a handle to the view controller for game center, which is easy to get from SDL or your own windowing manager.

[kevinresol]

Java?! That is interesting. Does that mean snow is providing some (maybe undocumented?) APIs to communicate with Java (JNI that kind)?

[ruby0x1]

Yes the plugin specific services have a way to deal with JNI, as well as ObjC in fact. It's a lot of stuff to elaborate on and it's best done in the right context, and when I post about the libraries it will be described at length :)

[ntrf]

I our previous game (which was written in C++) we used a special build step, that generated C++ wrapper classes based on compiled .dex file. This made interacting with Java code from C++ much easier. Some third-party libs were too hard to integrate directly and we wrote some helper objects in Java. It also provided a place to store project specific configuration like api keys.

I belive that the same functionality can be achived by haxe macros. The only problem - you need to build Java code before building native code. In our case gradle was a primary build system calling cmake for native parts.

[ruby0x1]

Android with snow uses gradle as the build system, and calls flow to build the native lib part from hxcpp. The rest you can do whatever you want from Android studio, so the documentation on "how to add Google Play services" on their site is 1:1 with how you do it in snow atm, the question then becomes "how do I call a project level java function from Haxe code without manual c++ externs" is what my macro solution answers, and it also answers "how do I call my haxe function from JNI" through the use of macros and hxcpp magic. I've posted about it before actually I think!

[ntrf]

Does this means we won't have to mess with jni function declarations (like "(Ljava/lang/String;[II[Lcom/company/lib/CallbackDelegate;)B") ?

[kevinresol]

Thanks Sven, snowkit and the Westport team. I look forward to the polished API.

But in current reality, I still struggle if I should use snow/luxe for my next serious production app, or I should use Unity or OpenFL for better native extension support 😕 ... (and that's why I asked the first question for ETA)