Native API

[google-ar]

Native API

[nathanmartz]

Thanks for your feedback on this issue. This is something we're looking at for the future. Given that you can use the JNI to do interop between the existing SDK and C, what are your main reasons for wanting a C API? Is it performance, ease of integration, something else?

[JeroMiya]

Ease of integration, mostly. We have a plugin system that allows extensible C modules to be dynamically loaded at runtime, access various VR-related devices, and surface them to applications in a consistent API across platforms. Usually with Java-only Android APIs we have to build up a bridge layer between the Java application and the plugin - that is, the Java application explicitly calls into the support library we provide. Then the data (typically poses, but also gestures, buttons, analog values, etc...) is pushed by the support library (JNI bridge) into a state queue which the plugin consumes and reports poses/analog values/buttons/etc... to the application.

The JNI bridges make it possible, but are cumbersome and cause the VR application to have to leak through the abstraction to get it working - that is, they have to have a Java support library and invoke it to get the data flowing. It's a little clunky and platform-specific, which we'd like to avoid if possible. Additionally, depending on the timing of when data is pushed to the state queue vs consumed by the plugin, this can sometimes add a little latency.

With a C++ API (that doesn't require references to the application, activity, view, etc... from the Java side, if possible), the plugin could be self-contained and the application that uses our middleware doesn't need to write platform specific code when porting their software to take advantage of ARCore. The plugin can also process data as it arrives, ensuring no latency overhead on our side.

[nathanmartz]

Thanks for the detailed feedback. I'll send this on to our core SDK team.

[inio]

Great news: ARCore Developer Preview 2 adds an NDK API!