3 ms·

I think it helps that C and C++ just work on iOS, so you can easily use or wrap existing code in those languages. Unless things have changed a lot recently, C/

I think it helps that C and C++ just work on iOS, so you can easily use or wrap existing code in those languages. Unless things have changed a lot recently, C/C++ sort-of-works on Android but it’s a pain to use and the tooling support is very weak.

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 ago
  Sounds 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 ago
    Because 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.
deleted 5y ago
[deleted]

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 ago
Sounds 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 ago
  Because 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.

deleted 5y ago

[deleted]