5 ms·

Nonsense. For Android it is NDK (which is why it is possible to build nice apps, like FB client) which is C[++], for iOS it is ObjC. Other platforms cannot be

Nonsense. For Android it is NDK (which is why it is possible to build nice apps, like FB client) which is C[++], for iOS it is ObjC. Other platforms cannot be considered seriously in 2014.

drdaeman 13y ago
Android NDK is primarily about native code, not language (except, possibly, for somehow language-related ABI like "C" calling convention or x86). As for languages - it's whatever you can compile.
Skinney 13y ago
The Android NDK is usually used for applications that don't use the Android API's (which are all Java). Most applications on Android is written in a JVM-based language. The sort of applications that would typically use the NDK are games, emulators, VMs (like Xamarin.Android) and the like. ObjC is also slow. Anytime you write something performance sensitive in ObjC, you usually drop down to pure C or pure C++. Luckily, since valid C is valid ObjC, this is rather easy. Javascript and HTML is actually a great fit for mobile, but there are two complications. 1) You will have to mimick the UI of the native platform. 2) Mobile platforms have sub-par JS engines. iOS don't allow JITs outside Safari (even when you use a webview in your ObjC app) which in turn makes JS-based apps in iOS slow. Android has in general had a pretty sucky webview, but that is getting fixed in 4.4 with chromium being the default engine. JS is getting better everyday on the mobile though, I would be surprised if not alot of people were using JS for apps in the coming years.
- dschiptsov 13y ago
  This is exactly what those marketing guys have said. In so-called objective reality 99% of apps people are using, such as FB, Adobe reader, Skype, WhatsApp, you name it, are NDK apps. 99% of TOP20 apps in each category are NDK apps, you like or not.
  - Skinney 13y ago
    All those apps uses the native GUI of the platform, which means they have to use the SDK. Why FB would even consider using the NDK is beyond me, as the FB app is simply a frontend over a web-api, and since you already have a HTTP library in the SDK, the NDK holds little value. The only app on the list that could benefit alot from the NDK would be Adobe reader, but even Adobe uses the native UI to a great extent, so it uses the SDK as well. The other apps are (I assume, as that would be easiest) simple clients to a backend server. There wouldn't be much benefit in using the NDK for these apps, as they mostly are a combination of UI and TCP/HTTP which are included in the SDK anyway. Btw, any source that these apps actually use the NDK?
    - dschiptsov 13y ago
      OK, I will try to explain. The problem with Java is that it doesn't actually fits for mobile development (or any sane development at all) being just a buzzword, a bubble inflated by corporate money. Consider the very basics of system architecture. There is something called ABI, which defines how syscalls are used and implemented. Android uses its own ABI which is a flavor of Linux ABI for ARM architecture (actually it supports different ARM chips and even x86, but it doesn't matter). According to these ABIs we perform syscall as it is in a Linux system. So, when we do Math we actually call procedures from libm.so, when we do crypto we call libssl.so (from OpenSSL) etc. It also has its own variant of libc.so and implementation of OpenGL ES, as one could guess, libGL.so. How does Java fits here? Well, according to original concept, it ought to be an isolated VM on top of any OS, which supposed to be run everywhere, and everything must be written (once) in pure Java. Because of that brilliant idea to simply ignore what an OS provides, they have re-implemented everything its own, proper way - famous Strings, Calendar, UTF-32, you name it. So-called reality, however, imposed some necessary corrections, and the kluge called JNI was added. It allows to break the purity and, using ugly and very inefficient mechanisms, dlload and call OS and third-party libraries. What we have in Android is, basically, a bunch of JNI calls to Android Runtime (libart.so, if I got it correctly) which is, not surprisingly, have nothing to do with Java. I am not an expert to tell how the bytecode translator (dx) works, but it doesn't really matter. Why do Android has Java at all? The answer is quite simple - because it is such a huge buzzword, such a great scam. It was the way to gain attention of ignorant masses^W^Wmillions of coders. "Wait, Java? Sounds familiar!" (The very same idea to play the Javascript card with WebOS have died, thank god.) So, the developers of complex (read: real-world) apps such as FB have realized that this unnecessary Java layer can't be used for anything but hello-words or http-get-post apps, and that it is much easier to avoid Java at all (what's the point to have the overhead of all that JNI calls), because, one could see, it is just an unnecessary, artificial layer which doesn't fit anywhere (except manager's presentations). I probably missed some details, but I am not an Android expert.

Nonsense. For Android it is NDK (which is why it is possible to build nice apps, like FB client) which is C[++], for iOS it is ObjC. Other platforms cannot be considered seriously in 2014.

drdaeman 13y ago

Android NDK is primarily about native code, not language (except, possibly, for somehow language-related ABI like "C" calling convention or x86). As for languages - it's whatever you can compile.

Skinney 13y ago

The Android NDK is usually used for applications that don't use the Android API's (which are all Java). Most applications on Android is written in a JVM-based language. The sort of applications that would typically use the NDK are games, emulators, VMs (like Xamarin.Android) and the like. ObjC is also slow. Anytime you write something performance sensitive in ObjC, you usually drop down to pure C or pure C++. Luckily, since valid C is valid ObjC, this is rather easy. Javascript and HTML is actually a great fit for mobile, but there are two complications. 1) You will have to mimick the UI of the native platform. 2) Mobile platforms have sub-par JS engines. iOS don't allow JITs outside Safari (even when you use a webview in your ObjC app) which in turn makes JS-based apps in iOS slow. Android has in general had a pretty sucky webview, but that is getting fixed in 4.4 with chromium being the default engine. JS is getting better everyday on the mobile though, I would be surprised if not alot of people were using JS for apps in the coming years.

dschiptsov 13y ago
This is exactly what those marketing guys have said. In so-called objective reality 99% of apps people are using, such as FB, Adobe reader, Skype, WhatsApp, you name it, are NDK apps. 99% of TOP20 apps in each category are NDK apps, you like or not.
- Skinney 13y ago
  All those apps uses the native GUI of the platform, which means they have to use the SDK. Why FB would even consider using the NDK is beyond me, as the FB app is simply a frontend over a web-api, and since you already have a HTTP library in the SDK, the NDK holds little value. The only app on the list that could benefit alot from the NDK would be Adobe reader, but even Adobe uses the native UI to a great extent, so it uses the SDK as well. The other apps are (I assume, as that would be easiest) simple clients to a backend server. There wouldn't be much benefit in using the NDK for these apps, as they mostly are a combination of UI and TCP/HTTP which are included in the SDK anyway. Btw, any source that these apps actually use the NDK?
  - dschiptsov 13y ago
    OK, I will try to explain. The problem with Java is that it doesn't actually fits for mobile development (or any sane development at all) being just a buzzword, a bubble inflated by corporate money. Consider the very basics of system architecture. There is something called ABI, which defines how syscalls are used and implemented. Android uses its own ABI which is a flavor of Linux ABI for ARM architecture (actually it supports different ARM chips and even x86, but it doesn't matter). According to these ABIs we perform syscall as it is in a Linux system. So, when we do Math we actually call procedures from libm.so, when we do crypto we call libssl.so (from OpenSSL) etc. It also has its own variant of libc.so and implementation of OpenGL ES, as one could guess, libGL.so. How does Java fits here? Well, according to original concept, it ought to be an isolated VM on top of any OS, which supposed to be run everywhere, and everything must be written (once) in pure Java. Because of that brilliant idea to simply ignore what an OS provides, they have re-implemented everything its own, proper way - famous Strings, Calendar, UTF-32, you name it. So-called reality, however, imposed some necessary corrections, and the kluge called JNI was added. It allows to break the purity and, using ugly and very inefficient mechanisms, dlload and call OS and third-party libraries. What we have in Android is, basically, a bunch of JNI calls to Android Runtime (libart.so, if I got it correctly) which is, not surprisingly, have nothing to do with Java. I am not an expert to tell how the bytecode translator (dx) works, but it doesn't really matter. Why do Android has Java at all? The answer is quite simple - because it is such a huge buzzword, such a great scam. It was the way to gain attention of ignorant masses^W^Wmillions of coders. "Wait, Java? Sounds familiar!" (The very same idea to play the Javascript card with WebOS have died, thank god.) So, the developers of complex (read: real-world) apps such as FB have realized that this unnecessary Java layer can't be used for anything but hello-words or http-get-post apps, and that it is much easier to avoid Java at all (what's the point to have the overhead of all that JNI calls), because, one could see, it is just an unnecessary, artificial layer which doesn't fit anywhere (except manager's presentations). I probably missed some details, but I am not an Android expert.