Hacker News Reader

Comment by akhilcacharya | Hacker News Reader

Is it really that beneficial to do this? Your system API's are still in Java/Obj-C/Swift, so all you can really share is business logic.

Has anybody had any real benefit from doing this in the past? I know Facebook did it with moments, but the image processing code could at least be shared here.

View on HN

Google does it with Inbox. They have Java business logic that they cross-compile to Javascript on the web, ObjC on iOS, and run as-is on Android. The respective UIs are done natively on the respective platforms. (Surprisingly, they do not use GWT for the web UI.)

I guess there is a lot of complex logic in there, the GWT chunk is a good megabyte or so, if I remember right. I think it's all syncing and conflict resolution stuff, but it's hard to tell for sure. (GWT code is optimized/compacted enough that I only have the string constants to go on.)

It's possible to have significant amounts of business logic. Google is able to share 70% of it's code (written in Java) for the Google Inbox apps[0][1].

[0]: http://gmailblog.blogspot.ca/2014/11/going-under-hood-of-inb...

[1]: http://arstechnica.com/information-technology/2014/11/how-go...

Depending on how you structure your application, "business logic" may include persistence, network code, and everything that's not UI.

If you're writing games, you aren't using those Java/Obj-C/Swift APIs; you're using the C API.

That's the use case they're targeting. They want Go to be a viable language for mobile games, not mobile apps.

is that still correct after the Dalvik -> ART move ? I always thought a long term strategy around ART was to move away from the jvm dependency.

Just in time for all the Oracle lawsuits confirming that Java apis are patent encumbered.

ART still uses dalvik bytecode.

from my understanding, it uses dalvik bytecode (dex) as input format. but the resultant .oat files are binary/ELF [1]

[1] http://newandroidbook.com/files/Andevcon-ART.pdf

Nothing official but after all these efforts with ART and jack&Jill both of which are not tied to java, it seems likely that Google is at least experimenting with another language.

What else would Google use? Android dev is pretty reliant on the OO model.

Well, that's an open question...

IMO, moving to another language should be taken as an opportunity to fix the oversights of the Framework. Things like the atrocious Activity lifecycle or the backstack handling.

There are several contenders :

-Dart : Google controls this language and the Dart Team is openly experimenting with their own Android fralewirj. The results are extremely underwhelming so far though.

-Kotlin : A better Java. I doubt that it would solve Android legal troubles though.

-Rust : the language has so many interesting ideas. I don't know if its complexity is warranted in Android's context though.

-a new language inspired by Kotlin, Rust, Go, Swift,... . Why not ? It would need a serious value proposition in order to be interesting though.

-insert your pet language here : everyone seems to want to develop Android apps in their most familiar language ...

Again, the official word from the Android team is that Java is the language of the platform for the time being. I just hope that if they are indeed planning a switch to another language, it will be discussed in the open beforehand. Such a debate is not always constructive, but it could be very important in Android's context.

And even 99% of the business logic these days is pushed server side.

I've worked on about 20 enterprise apps and they are nothing more than pretty API wrappers with some trivial functionality implemented on the phone.

Reply on news.ycombinator.com