3 ms·
There's a tool called "scapix" that's popped up recently that fixes this and is really impressive. It's zero-boilerplate (IE, don't need to manually write bind
by gavinray 5y ago
There's a tool called "scapix" that's popped up recently that fixes this and is really impressive.
It's zero-boilerplate (IE, don't need to manually write bindings like most tools) bindings from C++ code for both Swift/ObjC and Java. The idea being you can write C++ code and then consume it on both mobile platforms, making your life easier.
https://github.com/scapix-com/scapix
It also is really useful if you want to use Java from C++. Manual JNI invocation and type translation is awful, this just smoothes over all of it.
https://github.com/scapix-com/scapix#java-link
Good usecase being when you want to extend a Java app with some native capabilities.
I've had a scenario where another app handed me the pointer to a window to render to, and so the only way to use it from JVM was to write some bridge code. Where C++ started the JVM & invoked my Java app's entrypoint, sending over the window pointer, and then from there I could render/paint into the window.
- iainmerrick 5y agoSounds great, I’ll check it out! I’ve always wondered why Google didn’t make something like this themselves. I assume the answer is that they just don’t care about native code, or at least native/Java interoperability.
- pjmlp 5y agoBecause as per Android team, you should only be writing C or C++ code for implementing Java native methods, Vulkan, real time audio, integrating native libraries from other platforms, or anything else game development related. But yes, not even caring about a better JNI tooling story is a big pain, specially given Android Java, they surely could have come up with a better FFI story.