Write Android apps in Google Go(github.com)
github.com
Write Android apps in Google Go
https://github.com/eliasnaur/goandroid
37 comments
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.
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.
>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.
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.
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!
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!
>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".
It sounds like you could do it a lot more easily by just having separate processes or threads for each activity/service/whatever.
>This isn't remotely the same thing as swapping out pages as is done by the kernel.
It seems to be almost identical to the OS sending SIGTERM and then SIGKILL to the process in question however.
>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).
Are you assuming the necessity of a one to one mapping between Java API functions and C API functions? I don't care about something "analogous" to libc, just give me libc and you don't have to do any work. That solves most of what's on your list and obviates the need for garbage collection or reference counting.
The real trouble is the UI API because there isn't anything to lift it from since Android has a totally independent UI from Desktop Linux. But that doesn't mean it isn't worth doing -- and even if that isn't worth doing, why can't I have the rest of it? If I'm trying to port a Linux daemon into a service then I don't much care about a lack of GUI functions but I most certainly could use a full POSIX implementation.
It sounds like you could do it a lot more easily by just having separate processes or threads for each activity/service/whatever.
>This isn't remotely the same thing as swapping out pages as is done by the kernel.
It seems to be almost identical to the OS sending SIGTERM and then SIGKILL to the process in question however.
>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).
Are you assuming the necessity of a one to one mapping between Java API functions and C API functions? I don't care about something "analogous" to libc, just give me libc and you don't have to do any work. That solves most of what's on your list and obviates the need for garbage collection or reference counting.
The real trouble is the UI API because there isn't anything to lift it from since Android has a totally independent UI from Desktop Linux. But that doesn't mean it isn't worth doing -- and even if that isn't worth doing, why can't I have the rest of it? If I'm trying to port a Linux daemon into a service then I don't much care about a lack of GUI functions but I most certainly could use a full POSIX implementation.
> It sounds like you could do it a lot more easily by just having separate processes or threads for each activity/service/whatever
Do you know much memory is used for a thread? Or for a process? The answer for either is not zero. In fact it is possible (but not used) for the same Dalvik process to host multiple apps.
> It seems to be almost identical to the OS sending SIGTERM and then SIGKILL to the process in question however.
Not even close. With swapping the kernel has to operate in units of 4kb pages. Dalvik can use a compacting garbage collector to reduce memory consumption. Signals are trivial. They are a single number, and not come even remotely close to interprocess resources. Think something closer to dbus, plus a bunch of code built on top of it.
> don't care about something "analogous" to libc, just give me libc and you don't have to do any work
Android already includes that (bionic). You can compile elf binaries that work just fine. Heck you'll even find 'ls' etc on the system done that way. But your binary won't be able to examine the clipboard.
Note the posting was about writing Android applications in Go, not about trivial binaries. Applications means all the crud you are dismissing.
> Are you assuming the necessity of a one to one mapping between Java API functions and C API functions?
Nope. But those functions only have a Dalvik hosted Java centric implementation. If you want to work with them then they all have to be reimplemented in a compatible manner, or you need to call from the native code back into Dalvik using JNI. Either way is a lot of work.
Your example of porting a Linux daemon to a service won't work as is. Being a service means the system has expectations of you - how you are started, how data is provided and returned and how it is stopped. (There is also other stuff such as permissions and process hosting.) The canonical way of doing this is to write the service front end in Java, and then use JNI to load native code you need. But it does mean your native code needs to play well with others in the same process - something that isn't Go's sweet spot.
In your scenario there are several SSH servers available. Most are delivered as a single "app", but behind the scenes consist of an sshd binary, plus Java authored code to provide a UI (start/stop/status/configuration) and manage lifecycle.
The desire from most folk is for Go authored apps to be first class citizens, and not require using any other language. That is what is a lot of duplicate work.
Do you know much memory is used for a thread? Or for a process? The answer for either is not zero. In fact it is possible (but not used) for the same Dalvik process to host multiple apps.
> It seems to be almost identical to the OS sending SIGTERM and then SIGKILL to the process in question however.
Not even close. With swapping the kernel has to operate in units of 4kb pages. Dalvik can use a compacting garbage collector to reduce memory consumption. Signals are trivial. They are a single number, and not come even remotely close to interprocess resources. Think something closer to dbus, plus a bunch of code built on top of it.
> don't care about something "analogous" to libc, just give me libc and you don't have to do any work
Android already includes that (bionic). You can compile elf binaries that work just fine. Heck you'll even find 'ls' etc on the system done that way. But your binary won't be able to examine the clipboard.
Note the posting was about writing Android applications in Go, not about trivial binaries. Applications means all the crud you are dismissing.
> Are you assuming the necessity of a one to one mapping between Java API functions and C API functions?
Nope. But those functions only have a Dalvik hosted Java centric implementation. If you want to work with them then they all have to be reimplemented in a compatible manner, or you need to call from the native code back into Dalvik using JNI. Either way is a lot of work.
Your example of porting a Linux daemon to a service won't work as is. Being a service means the system has expectations of you - how you are started, how data is provided and returned and how it is stopped. (There is also other stuff such as permissions and process hosting.) The canonical way of doing this is to write the service front end in Java, and then use JNI to load native code you need. But it does mean your native code needs to play well with others in the same process - something that isn't Go's sweet spot.
In your scenario there are several SSH servers available. Most are delivered as a single "app", but behind the scenes consist of an sshd binary, plus Java authored code to provide a UI (start/stop/status/configuration) and manage lifecycle.
The desire from most folk is for Go authored apps to be first class citizens, and not require using any other language. That is what is a lot of duplicate work.
> 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
Most bindings (on Linux) to bigger frameworks are custom made with glue code (vs direct ffi calls to C ABI), and require significant effort to maintain and often some clever metaprogramming. Look Python/Ruby/Perl bindings to Gnome or Win32. They're still "3rd party" status so they may break when the wrapped API changes in a way that they fail to model.
Most bindings (on Linux) to bigger frameworks are custom made with glue code (vs direct ffi calls to C ABI), and require significant effort to maintain and often some clever metaprogramming. Look Python/Ruby/Perl bindings to Gnome or Win32. They're still "3rd party" status so they may break when the wrapped API changes in a way that they fail to model.
You already can use official Android APIs with alternative languages as long as they are JVM-hosted, such as Clojure or Scala. Asking for API support from external runtimes would be a tall order and a major undertaking, with probably little benefit. I fail to see what the "charade" is.
Actually Clojure and some other JVM hosted languages don't work on android as is because they rely on JVM while android uses bytecode converted from jvm to dalvik.
Edit: clojure works on android now but it needed additional porting efforts
Edit: clojure works on android now but it needed additional porting efforts
This is complete misinformation. Even Java apps on Android are first compiled to JVM bytecode, and then converted to Dalvik bytecode using the dx tool. Clojure and Scala go through the exact same process that Java does in order to make Android apps.
According to http://stackoverflow.com/a/231284/116546 Dalvik does not allow runtime bytecode generation, which may prevent some languages (Jython in particular) from running on Android without some (presumably heavy) efforts.
Android apps are compiled to Java bytecode and then translated to Dalvik bytecode. Clojure should work. There are toolchain issues like interfacing Clojure and AIDL that I'm not aware of the state of development, but it should be very feasible to make Clojure a first class citizen in the Android software development world.
Looks to me like Clojure on Android works just fine.
http://clojure-android.blogspot.com/2013/06/state-of-clojure...
http://clojure-android.blogspot.com/2013/06/state-of-clojure...
Yeah, they definitely require work but it is possible. I had just gotten my Android+Scala setup completed before IO and am now looking into integrating Gradle+Android+Scala, which is proving more difficult.
Because of those issues, I learned long time ago (in the early 90's) to just use official SDK supported languages.
Too much time is spent on hacking an half working solution and in the end the vendor offers no support if the problem is to be found outside the SDK. Or even if it is in the SDK, non supported languages offer a nice excuse to avoid giving support.
Too much time is spent on hacking an half working solution and in the end the vendor offers no support if the problem is to be found outside the SDK. Or even if it is in the SDK, non supported languages offer a nice excuse to avoid giving support.
I'd love to see Google reset their Android efforts and start again because of Java issues (legal, technical), and fragmentation issues (majority still on Android 2.x), and also as you mention because having one binary API for the UI is painful. My wishlist for a revamped mobile platform:
A simple linux distribution as a base (as with Android), with posix. They could still lock-down app installation for normal users, have an app store, and all the other things that make current mobile platforms attractive to consumers.
Hooks for any popular languages to control the UI via simple glue libraries, all implementing the same API, with the ability to add more easily because the UI API could be really quite simple (and should remain so) if built off the work already done for the web. They could add C, C++, Golang, Java, C#, even ObjC to the mix this way. There's no chance they'll do this for their current API, so they'd need to have a radical rethink of just what a mobile OS should provide.
A web-based stack for the UI based on an improved webkit (a la webOS). Most apps have very simple needs (specify a UI, adjust the UI, listen for UI events) that could easily be dealt with by message passing between the view and app rather than binary interfaces. Webgl and css animations etc could be utilised for performance where required. Crucially this wouldn't tie developers into one complete stack from language to tools to UI - the UI should be separate and not tied intimately to the back-end language as it is currently on iOS and Android.
A base OS that is non-negotiable and non-modifiable by carriers/manufacturers, and upgrades from a central point (a consortium led by Google), that are not phone-specific. Carriers can add apps etc but there's no reason they have to adjust the base OS, and both should negotiate with Google for inclusion of new drivers, not hold up upgrades because they want to sell newer hardware/contracts.
Far stricter permissions for apps with far less access (more like web-apps), and individual prompts on first use of info like phone no, addresses etc. to discourage overuse.
It's a shame that our mobile devices are typically tied to one platform, one language, one UI, when they have so much potential as portable computing devices.
A simple linux distribution as a base (as with Android), with posix. They could still lock-down app installation for normal users, have an app store, and all the other things that make current mobile platforms attractive to consumers.
Hooks for any popular languages to control the UI via simple glue libraries, all implementing the same API, with the ability to add more easily because the UI API could be really quite simple (and should remain so) if built off the work already done for the web. They could add C, C++, Golang, Java, C#, even ObjC to the mix this way. There's no chance they'll do this for their current API, so they'd need to have a radical rethink of just what a mobile OS should provide.
A web-based stack for the UI based on an improved webkit (a la webOS). Most apps have very simple needs (specify a UI, adjust the UI, listen for UI events) that could easily be dealt with by message passing between the view and app rather than binary interfaces. Webgl and css animations etc could be utilised for performance where required. Crucially this wouldn't tie developers into one complete stack from language to tools to UI - the UI should be separate and not tied intimately to the back-end language as it is currently on iOS and Android.
A base OS that is non-negotiable and non-modifiable by carriers/manufacturers, and upgrades from a central point (a consortium led by Google), that are not phone-specific. Carriers can add apps etc but there's no reason they have to adjust the base OS, and both should negotiate with Google for inclusion of new drivers, not hold up upgrades because they want to sell newer hardware/contracts.
Far stricter permissions for apps with far less access (more like web-apps), and individual prompts on first use of info like phone no, addresses etc. to discourage overuse.
It's a shame that our mobile devices are typically tied to one platform, one language, one UI, when they have so much potential as portable computing devices.
Is that Ubuntu for phones you're talking about?
Quite possibly that covers a lot of it, haven't looked at that so will have a look, thanks for the tip. Not keen on using QML (yet another mark up language), but HTML seems to be an option there. Do you know of any hardware that can run this?
Ubuntu is trying it
>fragmentation issues (majority still on Android 2.x)
http://developer.android.com/about/dashboards/index.html and no, fragmentation's not an issue for anyone with the Play Store and the compatibility kit (and maybe sherlock).
I mean, are you not aware of Firefox OS which bootstrap(ed/s) itself on top of Android? Or that Ubuntu for Phones is coming out with phones to support it?
Or of the Nexus program? Or the pseudo-Nexus program with devices with unlocked bootloaders.
OH and webOS still exists, and is open source and runs on some Android devices.
What more do you want, sounds like your needs are being met. Take the android kernel and write a new UI. Then you can run it on one of the what, hundred different devices that CM supports?
>They could add C, C++, Golang, Java, C#, even ObjC to the mix this way.
lol, you think writing and supporting all of the Android APIs for all of those languages is feasible? Or you want some kind of bindings or what exactly?
>Carriers can add apps etc but there's no reason they have to adjust the base OS, and both should negotiate with Google for inclusion of new drivers
and you don't seem to actually know who controls the distribution of the drivers
http://developer.android.com/about/dashboards/index.html and no, fragmentation's not an issue for anyone with the Play Store and the compatibility kit (and maybe sherlock).
I mean, are you not aware of Firefox OS which bootstrap(ed/s) itself on top of Android? Or that Ubuntu for Phones is coming out with phones to support it?
Or of the Nexus program? Or the pseudo-Nexus program with devices with unlocked bootloaders.
OH and webOS still exists, and is open source and runs on some Android devices.
What more do you want, sounds like your needs are being met. Take the android kernel and write a new UI. Then you can run it on one of the what, hundred different devices that CM supports?
>They could add C, C++, Golang, Java, C#, even ObjC to the mix this way.
lol, you think writing and supporting all of the Android APIs for all of those languages is feasible? Or you want some kind of bindings or what exactly?
>Carriers can add apps etc but there's no reason they have to adjust the base OS, and both should negotiate with Google for inclusion of new drivers
and you don't seem to actually know who controls the distribution of the drivers
Thanks for the link to up to date stats, so 'majority' is no longer correct according to those graphs, that was misleading. However the fragmentation picture still isn't pretty, even if improving - more than 30% are still on Android 2.x. This compares really badly with iOS where > 90% are on the latest and < 1% on 2 versions behind, so that's one area I really feel Android is lagging Apple on - mostly because of their more open nature, customisation, and the upgrades not going through google exclusively.
Ubuntu OS looks interesting but has no traction right now, I'll be keeping an eye on that though. I'm afraid WebOS is dead at the moment - choice of which platforms to target is more political than technical unfortunately, which is why it'd be great to see Google pushing a more open system which lets people use any language they want for development. They have enough clout to make that happen and not many do. I'm aware it's very unlikely as I said in the post above - There's no chance they'll do this for their current API, so they'd need to have a radical rethink of just what a mobile OS should provide.
Please don't take this as some sort of attack on Google or Android.
What more do you want, sounds like your needs are being met. Take the android kernel and write a new UI. Then you can run it on one of the what, hundred different devices that CM supports?
That is of course a huge amount of work for one person and likely doomed to failure. To be clear that I'm not blaming Google or demanding that they change, just agreeing with the OP that I'd like to see more options, but pointing out that that requires a fundamental rethink of the entanglement between UI and API. I've written a few iOS apps which use HTML views extensively and make little use of the UI toolkits using urls etc to pass actions and move screen, so I'm well aware this is possible using the current system, but it's currently a pain to try to use another language as your core language for an app.
Ubuntu OS looks interesting but has no traction right now, I'll be keeping an eye on that though. I'm afraid WebOS is dead at the moment - choice of which platforms to target is more political than technical unfortunately, which is why it'd be great to see Google pushing a more open system which lets people use any language they want for development. They have enough clout to make that happen and not many do. I'm aware it's very unlikely as I said in the post above - There's no chance they'll do this for their current API, so they'd need to have a radical rethink of just what a mobile OS should provide.
Please don't take this as some sort of attack on Google or Android.
What more do you want, sounds like your needs are being met. Take the android kernel and write a new UI. Then you can run it on one of the what, hundred different devices that CM supports?
That is of course a huge amount of work for one person and likely doomed to failure. To be clear that I'm not blaming Google or demanding that they change, just agreeing with the OP that I'd like to see more options, but pointing out that that requires a fundamental rethink of the entanglement between UI and API. I've written a few iOS apps which use HTML views extensively and make little use of the UI toolkits using urls etc to pass actions and move screen, so I'm well aware this is possible using the current system, but it's currently a pain to try to use another language as your core language for an app.
Yeah, but what's it matter? Those people buy cheap Android phones. There are several options for up to date Android phones that are either Nexus, I mean, many of them if you're a GSM user. And many more if you want to use AOSP or CyanogenMod.
And devs get backporting of most apis via the Play Store so it's not like fragmentation is an issue very often at all.
The hardware is out there. The software is out there. You could port Firefox OS to the SGS4, you would have basically /everything/ on your checklist, and you can buy a 100% unlocked GSM SGS4 from Google and put Firefox OS, or port webOS, or whatever OS you want.
Are you simply lamenting that you can't walk into a store and buy that combo? I guess I don't care when I can follow the steps to do it myself (of course, now I'm starting to download stuff to play around with porting Firefox OS to my SGS4)
>requires a fundamental rethink of the entanglement between UI and API
Heh, I actually know of a platform that allows you to write web apps and from them invoke native code that conforms to their spec. And their vision is to have that platform spread across all device sizes. Do you know who it is? :)
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The...
Sadly, non-free. But yes, you can write projections for your own language. I've thought it would be cool to try to write one for Go.
And devs get backporting of most apis via the Play Store so it's not like fragmentation is an issue very often at all.
The hardware is out there. The software is out there. You could port Firefox OS to the SGS4, you would have basically /everything/ on your checklist, and you can buy a 100% unlocked GSM SGS4 from Google and put Firefox OS, or port webOS, or whatever OS you want.
Are you simply lamenting that you can't walk into a store and buy that combo? I guess I don't care when I can follow the steps to do it myself (of course, now I'm starting to download stuff to play around with porting Firefox OS to my SGS4)
>requires a fundamental rethink of the entanglement between UI and API
Heh, I actually know of a platform that allows you to write web apps and from them invoke native code that conforms to their spec. And their vision is to have that platform spread across all device sizes. Do you know who it is? :)
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The...
Sadly, non-free. But yes, you can write projections for your own language. I've thought it would be cool to try to write one for Go.
It's more that I'm lamenting that as a mobile app developer for commercial clients I am forced to use the platforms which have traction, which leaves me with the unenviable choice of iOS or Android, both of which have significant warts, and neither of which leave much choice for experimentation in languages for writing apps or UIs.
I don't want to justify lack of innovation or responsiveness to developers, but there are a few reasons why not, among them: Android has a large middleware layer written in Java and the Dalvik VM uses copy-on-write and fork to treat bytecode as if it were pure code - using only one copy.
In practice this means that apps that do not make use of the Dalvik runtime are limited to special purpose apps such as games written mostly on top of OpenGL. Even those might end up being wrapped in a Dalvik VM runtime app to access things like accounts, sharing, etc.
A realistic step would be to add one or more JVM languages as first class citizens of the toolchain. Clojure would be very welcome.
Android really is an OS with a very intimate relationship with a VM that implements Java semantics, though not Java bytecodes.
In practice this means that apps that do not make use of the Dalvik runtime are limited to special purpose apps such as games written mostly on top of OpenGL. Even those might end up being wrapped in a Dalvik VM runtime app to access things like accounts, sharing, etc.
A realistic step would be to add one or more JVM languages as first class citizens of the toolchain. Clojure would be very welcome.
Android really is an OS with a very intimate relationship with a VM that implements Java semantics, though not Java bytecodes.
If you do not call it AT&T C, please don't call it Google Go.
It is much easier to tell by context that you are talking about a programming language with C. Go is a common enough word that sometimes it is hard to tell. The full name reduces the chance of confusion.
I thought Golang was the safer term.
I completely agree with you, but for the sake of a title more people will understand "Google Go" than simply "Go" (and while Golang is great for search engines, it's not the actual name of the language).
With the contribution from samsung, one can also write Rust programs for android.
https://github.com/mozilla/rust/wiki/Doc-building-for-androi...
https://github.com/mozilla/rust/wiki/Doc-building-for-androi...
You can also use ATS with a few patches to the compiler:
http://sourceforge.net/mailarchive/message.php?msg_id=290363...
Quite a few languages are available for Android development now that the NDK allows native code.
http://sourceforge.net/mailarchive/message.php?msg_id=290363...
Quite a few languages are available for Android development now that the NDK allows native code.
(It should be pointed out that Android is not a tier-1 platform, and so gets broken fairly regularly. The Samsung people are normally pretty quick to debug and submit a fix though.)
Meanwhile this is still open with no changes since November 2012,
http://code.google.com/p/android/issues/detail?id=39482
If the Android team wanted to give proper support for Go, I think it would have done it already, instead of changing tooling between IDEs.
The same goes for disabling the Objective-C support on gcc and clang toolchains.
http://code.google.com/p/android/issues/detail?id=39482
If the Android team wanted to give proper support for Go, I think it would have done it already, instead of changing tooling between IDEs.
The same goes for disabling the Objective-C support on gcc and clang toolchains.
Last time I've tried (a few months ago) it was a question of modifying a Makefile to enable Fortran and Objective-C in a custom build toolchain for Android.
I know, but that is the main point, we are forced to use a custom build toolchain, when gcc and clang already offer support for them
And while I'm complaining about it, it sure would be nice if they would include POSIX support by default. It's not like the code to do it isn't largely already written and freely available.