Hacker News new | comments | ask | show | jobs | submit login

> Generally speaking, the NDK makes sense only for a small percentage of apps, so in the general case Google advise against trying to write a whole Android app using the NDK.

Yep, it is easier to make languages target DEX than suffer the pain of the NDK.

They not only advise against it, they make it really uncomfortable for us to use it (vs iOS and WP experience).




> Yep, it is easier to make languages target DEX than suffer the pain of the NDK.

Why do you say that? Plenty of Android apps use non-trivial amounts of C/C++ code, and Dropbox has a tool called Djinni that can automatically generate JNI glue code. My guess is that if it's feasible to use pure Dex bytecode, then debugging is easier (because there's only one kind of call stack), memory can be managed more effectively (because the Dalvik/ART garbage collector can manage everything), and performance isn't impacted by the overhead of JNI. But I have nothing to back that up.


Yes there are plenty of apps that use a lot of C and C++, and we all join in the Anonymous NDK user group meetings.

- The bug tracker is full of NDK issues

- GDB works, eventually. If one has the right set of versions and mobile firmware

- Integration with the first official IDE (Eclipse CDT) kind of worked, after one turned off indexers, did a few plugin customizations, and even then not really

- When Android Studio was announced, silence ensued about NDK future. When Jetbrains announced CLion, there was the hope that it might came to Android Studio, still silent all the way up to Google IO 2015.

- No pre-defined templates for mixed code applications

- Even today Gradle support for NDK builds is flaky and not final. I am yet to be able to have the samples build out of the box.

- The set of official C++ libraries is quite limited, most game related APIs are exposed. Even C++ libraries used by the Java layers like Skia are not exposed to the NDK.

- By limiting NDK to a few basic POSIX APIs and Android game related APIs, everyone has to pack into their APK everything from JNI wrappers, image loaders, network access, the whole stuff.

Now compare this with using C++ in iOS with help of Objective-C++ or on Windows Phone with help of C++/CX.

First class tooling support, mixed debugging that works and no need to keep on writing wrappers.

Even Microsoft's tooling for Android NDK is looking better than what Google does for their own platform.

As for Djinni, I am yet to make it work on Windows.


> Yep, it is easier to make languages target DEX than suffer the pain of the NDK.

So what does this look like in practice? Genuinely curious :-)



By targeting DEX, which happens to be documented, there is at least the hope that for the Android tooling that Google cares about, it is just like Java running and there are less hurdles.

So, you get the same benefits of the languages that target other VMs like JVM, CLR, BEAM and so on.

As long as, the language semantics can map into the VM semantics, all the libraries and platform tooling are available without the need of writing wrappers.

True, that is a big "as long as", but it still is less problematic than going through the current state of the NDK.

That is the approach take by Elements for their tools (http://www.elementscompiler.com), for example.


It could still be used in order to share a module between iOS & Android. For something not related to UI, like persistence, it can make sense. In all the other cases, Kotlin is probably a better choice for Android.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: