Write Android apps in Google Go

by SamWhited • 13 years ago

98 37 13 years ago

axaxs• 13 years ago

If you do not call it AT&T C, please don't call it Google Go.

Lerc• 13 years ago

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.

hayksaakian• 13 years ago

I thought Golang was the safer term.

SamWhited• 13 years ago

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).

AnthonyMouse3• 13 years ago

This is nice and everything, but why can't they just give up the charade and let people write applications for mobile devices in whatever language they like without having to jump through hoops like this? I should be able to write applications in Go (or C or whatever) and be able to use the official APIs in an officially supported way and without having to waste time screwing with shims and JNI.

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.

gw2• 13 years ago

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.

deniska• 13 years ago

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

rogerbinns3• 13 years ago

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.

AnthonyMouse3• 13 years 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.

grey-area4• 13 years ago

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.

dotmanish• 13 years ago

Is that Ubuntu for phones you're talking about?

drivebyacct22• 13 years ago

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

amalag• 13 years ago

Ubuntu is trying it

Zigurd2• 13 years ago

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.

pjmlp3• 13 years ago

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.

octopus• 13 years ago

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.

pjmlp3• 13 years ago

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

z3phyr• 13 years ago

With the contribution from samsung, one can also write Rust programs for android.

https://github.com/mozilla/rust/wiki/Doc-building-for-androi...

doublec• 13 years ago

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.

dbaupp• 13 years ago

(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.)

Write Android apps in Google Go

Related Stories