Hacker News Reader

Comment by haneefmubarak | Hacker News Reader

To do that, all they'd really need to do is have a mechanism to build native apps in C, after which various language communities would be able to write simple wrappers that would allow them to use said C API.

To an extent, that partially exists in the form of Android NDK, but that's not really a full solution. If and when Google makes it possible to easily create your entire app natively (with a clean C API), then you ought to see a surge of libraries/toolkits/frameworks coming out that will enable you to write Android apps in most common languages (Rust likely included).

View on HN

It won't happen.

The last years the NDK support has always been seen as something to help bring "legacy" code from other platforms, be consumed from Java to help speed up some algorithms, games.

In fact, apparently they are now closing down the door to rogue developers that used to link to unofficial platform libraries.

If you look at the Tango SDK, apparently they have a C API to some platform APIs, however when one digs into them, they are wrappers to functionality implemented in Java.

It's easy to run other languages on Android (see Go binaries). It would be a huge effort (and some would say a distraction) to port the Android SDK to another language. It would also fragment the developer ecosystem if that language was not compatible with Java libraries (reducing your choices to Scala, Clojure, etc).

While the NDK is hard to use, it is enough to enable alternate modes of Android development. For instance with Unity you can develop and Android app using C# and the Unity graphical editor. That's a very powerful option for certain classes of apps.

OTOH, that same fragmentation also means competition. Allowing for multiple independent languages to run on the platform means a plethora of developers to whom the platform is now accessible.

Having an API that is easy to use would really open up the ecosystem. Also, having much faster, machine targeted code (ie: compiled with CPU architecture and model specific optimizations and instructions) in C, C++, Rust, Go, etc. would mean better performance and less battery usage in some apps, which overall would translate to a superior user experience.

> which overall would translate to a superior user experience.

Only for users of devices that the dev bothered to put out binaries for. I guarantee you most devs that use the NDK are not building for all 8 ABIs that the NDK supports. ARMv7-neon may be the most common arch but it is far, far from the only one.

Since the compilation to native code takes place at installation time, supposedly ART would take advantage of the CPU specific features.

Also they could in theory do escape analysis to do stack allocation.

And assuming Google does indeed keep up with Java versions, eventually value types will be supported.

The only way they are going to move away from all the framework code they have invested in Java (the language) is if they create a common runtime like WinRT or Objective-C runtime.

However, it is quite telling that the Android team doesn't even bother to add Go or Dart support to the NDK.

Nobody has a problem with jvm - it is one if the fastest platforms around.

It's java the language we are talking about. Basically kotlin or dart targeting the jvm.

> Nobody has a problem with jvm [citation needed]

Qt has already been ported to Android via the NDK. Nothing stops other UI frameworks from doing the same.

Having used the 4.3 version I wouldn't recommend it, specially since looking at the web site it seems anything has hardly changed in that area since my attempt.

It adds very little value over Java + NDK on Android.

The Android native widgets aren't supported, rather emulated via QML and only the most well known ones.

For the majority of Android APIs no support is provided, offering no advantage over we having to write our own JNI wrappers.

Also iOS and Windows Phone support are even worse than Android.

That's a strange complaint. The whole premise of putting QML, or any other UI toolkit for that matter, on Android is to use those instead of native Android widgets. In that sense, it adds a lot of value.

The premise of a portable framework is to allow me to write my code in a portable way across multiple operating systems.

If I have to spend time writing bindings to OS APIs and faking UI widgets for each OS I am targeting, then the framework is not doing anything to help me, rather on the contrary.

As extra info, on 5.3 some of the C++ widgets render on Android as if it was a desktop. Just try to use a Qr file selector on your phone.

Apparently this has worked so well that 5.6 is going to have yet another re-write of the controls.

The purpose of porting alternative UI toolkits is to let developers use their preferred programming language. Users don't want to see UI widgets that look out of place. Ideally there should be no perceivable difference in the end result.

Reply on news.ycombinator.com