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)

[ruby0x1]

Yea you wouldn't need to @NtrfAtZNS

I probably shouldn't link to outdated example, but note that this code is 7 months behind and not indicative of anything anymore. Since you can find this link on the gitter search, I will just link it for convenience of explaining

https://gist.github.com/underscorediscovery/3924191bb7c00ae69fa7

This was from when I first was exploring the idea of it being practical. That example is just calling from / to haxe, and calling "URLUtil" which is an android Java library compiled to jar directly from haxe code using the haxe java target. It's still similar enough that linking as an example can show the direction I am referring to.

@kevinresol I understand. As much as I would love to estimate, we gain nothing to try and bend reality, I prefer that the situation is just plain and clear.

luxe and snow are in alpha, and we work based on a current focus, or we'll never finish.

The plugin stuff, it's critical and I know this, but so is the engine. If the engine is only half done - it doesn't really mean much to be able to have achievements, to me. To me, timing is as relevant as the features themselves.

The plugins (and the support layers for them) are a joint effort, and have been ongoing because of things like Haxe 3.2 adding missing pieces we needed. This is the reason Westport released on snow alpha-2.0 before it was finished - because the pieces required to make it work in practice were coalescing and there was a bit of tailing happening.

The plugins are intended for more than just snow users, and we won't sacrifice doing these pieces right in the surrounding eco system - not for any reason. I don't think more false starts here is a benefit, and I don't think “promising” things that might not work out is all that helpful.

Like, what If the idea of "a mobile plugin for any hxcpp user" was just impractical? This is too big of an unknown for me to claim the goal until I know for sure. For this reason, I proof my designs and ideas in practice, and if they make sense, we lean in and make it work.

This has worked out really well for linc and all of the other snowkit stuff - so I feel good about it - but I won't feel comfortable with anything more than discussing it in this light until I know what it will look like in reality. We are in that phase now, of answering this last unknown. If the ideas translate well, the system will be opened much sooner than later, and everyone will be able to contribute and collaborate as usual.

I don't know exactly when we'll be done, but other devs have been busy proofing other things in this vein on iOS/Mac, and progress is steady.

p.s The fact that Westport had no trouble using platform services in a release should also be a hint that you're not prevented from doing it yourself really easily - just that a drop in solution is as well in the works.

[kevinresol]

@underscorediscovery Awesome. I really love the idea "a mobile plugin for any hxcpp user"!

[darmie]

How far with this? It will be very useful

[ruby0x1]

The linc libraries were a start to making this approach streamlined, the original sdk discussion was when snow was a c++ codebase. With haxe/hxcpp c++ workflow improving, linc was the evolution of this for people to share native libraries - since they are not necessarily framework specific. The step beyond that I haven't gotten much further with as my focus has been shifted.