4 ms·

You can write them in whatever language you like, but the problem is they have to interface to the system. With Linux ultimately you only need the system call

You can write them in whatever language you like, but the problem is they have to interface to the system. With Linux ultimately you only need the system call interface, and the communication back from the kernel is signals. A mobile app has a far richer interface, and needs to interact with the system in more deep and meaningful ways. Memory is tight and application lifecycles can be hectic. Heck on Android there isn't such a thing as an Application in the traditional sense - ie there is no entry point/main function. Instead the "application" is actually a mashup of components such as Activities (screens/ui), services (processing), content providers (data) and broadcast receivers (async updates)[1]. The Android system itself is then a mashup of those. Again there is a lot of scaffolding to make the different parts of the different apps all work together with bidirectional communication. Using a different language means all that scaffolding has to be duplicated in each language. That is a heck of a lot of work and then requires ongoing maintenance. Dalvik essentially provides all that for Java like bytecode with JNI for calling out to native code. You'd need to duplicate what is in Dalvik to do a good language environment for Android. (Or generate Dalvik bytecode ahead of time.) [1] That is how a well written app is structured for Android. You can ignore all that and put everything into a single Activity (iOS ports often do this) but it won't interoperate well with the system, and users will notice. With the increasing RAM and CPU these days you are increasingly likely to get away with it. The first Android phone had 192MB of RAM.

AnthonyMouse 13y ago
>A mobile app has a far richer interface, and needs to interact with the system in more deep and meaningful ways. Memory is tight and application lifecycles can be hectic. I'm not clear how this is different than it is for the variety of embedded Linux devices that natively support multiple languages. You can run Debian (sans X-Windows) with under 64MB of RAM. >Using a different language means all that scaffolding has to be duplicated in each language. Not really. I would be plenty happy if they would just provide a native C API like GNU/Linux does, which manages to support most of the major languages because almost everything has near-seamless support for calling C API functions.
- rogerbinns 13y ago
  I apologise for not being clear enough. The "mashup" style also happens between apps/processes as well as within them. There are resources tracking counter parties. For example the canonical way to structure a music app would be an activity (gui) for visuals, a content provider to provide the library and a service to play the actual audio. There is no requirement for these to be in the same app/process and it is pretty much immaterial to the code. But if your activity is communicating with the service (eg to send play/pause/next in one direction and getting the current play position and file in the other) then Android does housekeeping to make sure the right thing happens such as what happens when either side crashes or exits. Android can do memory management within a process - for example if you switch to your email app, the music playing service can keep going, and the activity can be terminated (it is usually told). This isn't remotely the same thing as swapping out pages as is done by the kernel. Additionally a whole bunch of the pieces have no kernel representation (eg a content provider). There is an IPC mechanism (binder) that has both kernel and user space components working in harmony. To have something analogous in C, your "app" would be a large number of shared libraries (dozens), and they would be dynamically loaded and unloaded. They would talk to each other and shared libraries in other processes. There would be garbage collection, lifetime management and possibly reference counting. Calls into them could be asynchronous, as well as calls out. Managing all that would be non-trivial "scaffolding". > ... almost everything has near-seamless support for calling C API functions Dalvik already has that - using JNI. The pattern is to implement your interface to Android in Java and then call through to C when you need to. The problem with Go is that it isn't designed to play well with others. It doesn't support dynamically linking, and expects to own the process - being in charge. The work the posting is about is some toolchain hacks that make it so a dynamically loadable binary is produced instead of an executable. There is then work to make the Android API available which is non-trivial, and Java flavoured. > I would be plenty happy if they would just provide a native C API like GNU/Linux does The "native" API it would provide would need to be analogous to libc, glib, X (and extensions like xrandr), gnome, systemd/udev, dbus, sdl, ibus, garbage collection, shm, reference counting etc all combined (in addition to whatever I forgot). There is no "just providing" that!
  - AnthonyMouse 13y ago

AnthonyMouse 13y ago

>A mobile app has a far richer interface, and needs to interact with the system in more deep and meaningful ways. Memory is tight and application lifecycles can be hectic. I'm not clear how this is different than it is for the variety of embedded Linux devices that natively support multiple languages. You can run Debian (sans X-Windows) with under 64MB of RAM. >Using a different language means all that scaffolding has to be duplicated in each language. Not really. I would be plenty happy if they would just provide a native C API like GNU/Linux does, which manages to support most of the major languages because almost everything has near-seamless support for calling C API functions.

rogerbinns 13y ago
I apologise for not being clear enough. The "mashup" style also happens between apps/processes as well as within them. There are resources tracking counter parties. For example the canonical way to structure a music app would be an activity (gui) for visuals, a content provider to provide the library and a service to play the actual audio. There is no requirement for these to be in the same app/process and it is pretty much immaterial to the code. But if your activity is communicating with the service (eg to send play/pause/next in one direction and getting the current play position and file in the other) then Android does housekeeping to make sure the right thing happens such as what happens when either side crashes or exits. Android can do memory management within a process - for example if you switch to your email app, the music playing service can keep going, and the activity can be terminated (it is usually told). This isn't remotely the same thing as swapping out pages as is done by the kernel. Additionally a whole bunch of the pieces have no kernel representation (eg a content provider). There is an IPC mechanism (binder) that has both kernel and user space components working in harmony. To have something analogous in C, your "app" would be a large number of shared libraries (dozens), and they would be dynamically loaded and unloaded. They would talk to each other and shared libraries in other processes. There would be garbage collection, lifetime management and possibly reference counting. Calls into them could be asynchronous, as well as calls out. Managing all that would be non-trivial "scaffolding". > ... almost everything has near-seamless support for calling C API functions Dalvik already has that - using JNI. The pattern is to implement your interface to Android in Java and then call through to C when you need to. The problem with Go is that it isn't designed to play well with others. It doesn't support dynamically linking, and expects to own the process - being in charge. The work the posting is about is some toolchain hacks that make it so a dynamically loadable binary is produced instead of an executable. There is then work to make the Android API available which is non-trivial, and Java flavoured. > I would be plenty happy if they would just provide a native C API like GNU/Linux does The "native" API it would provide would need to be analogous to libc, glib, X (and extensions like xrandr), gnome, systemd/udev, dbus, sdl, ibus, garbage collection, shm, reference counting etc all combined (in addition to whatever I forgot). There is no "just providing" that!
- AnthonyMouse 13y ago