How Google Inbox shares 70% of its code across Android, iOS, and the Web

http://arstechnica.com/information-technology/2014/11/how-google-inbox-shares-70-of-its-code-across-android-ios-and-the-web/

by akrymski • 11 years ago

266 78 11 years ago

arstechnica.com

dblohm72• 11 years ago

How Google Inbox shares 70% of its code across Android, iOS, and Chrome

FTFY

pachydermic• 11 years ago

I think the claim was that arrays were too slow on Firefox and that's why it's Chrome only right now. Take that for what you will, but I think that was their claim.

cromwellian2• 11 years ago

That was an easy example a gave of one of the minor hiccups, and it wasn't Arrays, but Sparse Arrays, which we were abusing. It's a case where using standard APIs, not proprietary APIs, leads to gotchas because of implementation differences between VMs, which normally don't manifest themselves in smaller apps, but do in large sophisticated apps.

The real blocking issue is very bad rendering performance, but that has been worked on for months now and you should see the results soonish. That's harder to illustrate in an HN thread. I've still got scars from the last discussion on this, so I'd advise people go read those old HN threads for insight. :)

sp3322• 11 years ago

It's not available on other Blink browsers, either. (Do other browsers use V8? My google-fu is weak!)

timo777• 11 years ago

It works fine on my Firefox when changing the user agent.

therealmarv• 11 years ago

Very interesting approach. I've read that people have the feeling that the web UI of Inbox is slow in comparison to the Android and iOS app. Maybe GWT is not that good?! Does somebody else have this experiences or can say that is not true? Thanks

trekkin• 11 years ago

GWT generates very performant code, even in high-CPU scenarios like hashing/encryption (and please don't spam the Matasano article about dangers of encryption in JS - it is not relevant here).

scopendo• 11 years ago

I don't know about GWT, but certainly Inbox in Chrome desktop feels much more sluggish than the app on my Android phone.

sangnoir• 11 years ago

Google wants developers to write the logic once in Java, transpile it to other platforms, and then make the UI natively using the SDK for each platform. That way the apps look and feel native to the platform they're on, and the UI should run a lot more smoothly.

The article seems to suggest that GWT is being (should be?) used for logic only. If the Web UI is sluggish, it probably isn't GWT's fault (disclaimer: I'm not a Googler & I have never looked at the Inbox code)

MarkMc• 11 years ago

It's not just GWT - I get the feeling that web apps in general are noticeably slower than native apps when they attempt the same level of animation and full-page transitions.

_random_• 11 years ago

So, not Dart, not Go.

_almosnow2• 11 years ago

Eat your own dog food, they say.

orbitur• 11 years ago

They do. The problem (or solution?) is that they make a variety of dog foods.

_almosnow2• 11 years ago

[Two downvotes from Google]

chrisan• 11 years ago

were you expecting Go to have a large role in code shared by ios/android/web?

encoderer• 11 years ago

Hopefully they will add iPad to that list soon. I hate having to use gmail on my ipad still.

msoad• 11 years ago

I always get amazed when I see software architectures like this. How one learns the skills required to architect such huge project? Where you learn all that?!

valisystem• 11 years ago

Break it down to small, high level abstractions for properly crafted, high yield components.

It requires experience, vision and talent. It's perceived as very difficult because it's basically the same approach as academic research, but instead of being applied to general problems, it's a general approach for a set of very specific technical constraints.

Oh, and most people screw it up badly on most occasions.

zeroxfe• 11 years ago

It requires experience, vision and talent.

Also a team of solid engineers.

Rygu• 11 years ago

You gotta be a little insane in a particularly good way.

ma2rten• 11 years ago

Doesn't seem very difficult to me actually if you look at it from a high level. There are two parts to this:

1. Translate Java to ObjectiveC: generate an abstract syntax tree, transform the syntax tree, generate ObjectiveC.

2. Provide compatible APIs.

Don't get me wrong it's a lot of work, but shouldn't be more difficult than writing a compiler in general.

sigmaml• 11 years ago

I have worked on at least three very large projects that required cross-platform and cross-language compatibility. In all cases, the high-level view is similar to what you wrote above.

In all cases, though, the devil was certainly in the details! APIs, in particular, can surprise and harass the developers.

ed_blackburn• 11 years ago

I wonder if they considered Xamarin?

wffurr2• 11 years ago

Google doesn't write a lot of C# code, but they do write a lot of Java. This is a case where they looked at Xamarin and said "we want that" and built their own, only for Java.

Another big language at Google is C++, which also has a cool cross-platform client story. Emscripten for web, Android NDK, iOS can use C++ libraries directly.

pjmlp• 11 years ago

Android NDK is a world of pain.

I do get the security part, I also like how both Android and Windows Phone 7/8 share architecture ideas with IBM i.

However, it would be nice to also expose the framework to the NDK without forcing everyone to write their own bindings.

Or at very least, expose other Android internal C++ libraries like SKIA, as part of the public NDK APIs.

zodiakzz• 11 years ago

Does it run on the Web?

pm• 11 years ago

Cross-platform work is pain enough without making it torture with Xamarin.

mooreds• 11 years ago

Nice to see GWT making an appearance. I used that a lot, in exactly the wrong way, but this use of it, to build backend 'model' code that can be shared, is right in line with its sweet spot.

I always worry about transpilers like this, though, because when there are issues, you get to debug in three places (original code, derived code, and translation code).

wffurr2• 11 years ago

Source maps help a lot with that.

zackify• 11 years ago

Could have just used React Native if it was out already ;)

cpursley• 11 years ago

Or perhaps their own projects like Angular and golang.

georgiecasey2• 11 years ago

I tried to use j2objc and I thought it was the biggest POS. The ObjC code it generated was so strange and hacky that debugging it must be a nightmare. I was pretty new to ObjC back then and I knew I wouldn't learn anything using it, or get anything to work. And of course it can't be used for any UI stuff.

Any opinions from anyone else who tried using it?

I checked StackOverflow and there's only 21 questions with the tag (http://stackoverflow.com/questions/tagged/j2objc) so that put in the nail in the coffin for me. As an aside, that's how I make most of my decisions between frameworks and libraries, I just pick the one the highest amount of SO tags!

georgiecasey2• 11 years ago

so has anyone actually used it?

funkybro• 11 years ago

Why do you care if the generated objC is "hacky"? Correctness and performance is all that matters surely?

I've stuck to using GWT generated JS in a hidden webview on iOS, rather than J2ObjC.

I've found the process of compiling code on J2ObjC to be difficult and laborious. It may have improved but on initial investigation I ended up hacking a script to try and generate the correct command line for my project. Not to mention downloading and unpacking each library jar by hand.

GWT on the other hand integrates easily with Maven, pulls in all your dependencies and filters out unused methods.

Additionally, the code can be run anywhere else JS is available, in our case Windows Phone and Xbox One.

Zigurd2• 11 years ago

I tried to use j2objc and I thought it was the biggest POS.

GWT was also an idea whose time had not yet come. I'm sure that the success of InBox makes the developers forget some of the blood, sweat and tears it probably took to toolsmith a cross-platform architecture. But they took a conservative approach, sticking to networking, sync, and local persistence. They picked parts of the app that would be using similar-enough APIs on all platforms that the abstractions don't get out of hand, and the learning curve for maintainers isn't too steep.

If I was looking at a big-enough project to justify the toolsmithing, I would be looking at how they did this.

fidotron2• 11 years ago

The part of cross-platform mobile dev that increasingly drives me insane is duplicating the persistent data model code across platforms. I'd be very interested if the Inbox people can share how they approached this (hint!).

Generally the SQLite approach feels quite lowest common denominator, mainly because on Android the SQLite wrapper is so clunky. Get over that and you're into raw files territory, which has made me consider things like building LevelDB for bundling in.

terhechte• 11 years ago

What about Realm (http://realm.io/)? I've only briefly touched it, but I've heard good stuff about it. I wouldn't know how easy it is to access it from Java for cross-platform development, but at least there's full iOS & Android support.

julianpye• 11 years ago

The way how I do this is by having written a code-generator that takes a simple YAML like file with a data model description and generates SQL models/NOSQL models for backend storage, POJO access code to that and POJO access for a rest API; then an angular backend that accesses the api and locally stores it and directives to display it; then an android sqlite local database wrapped in a content provider to access it, async task helpers to retrieve the content via sync providers and adapters to display them. I haven't yet started with iOS.

Any wellfunctioning code that I have written I pack into my content generator and give access to via the YAML. The whole thing has gotten really ugly and desperately needs refactoring (it's in Perl and I am rewriting it in Stringtemplate) but it does help me with:

- the changes in the model that cascade down the frontends

- fixing a bug in one application that needs fixing in several others

- the fact that multi-platform model really is stressful since the brain needs to switch rapidly between different languages and platform APIs and this allows me to write code once and perpetuate data model changes on to all platforms.

So I think, take code of yours that works and wrap a codegenerator around it. It's better than using a framework where you don't know what's underneath. All the code is something you know and built.

fidotron2• 11 years ago

I've considered extending protocol buffers to do it. If you already have protobufs for on the wire (it tends to be what I use) then it should be possible to auto-generate a schema and all the code for keeping the same data inside a DB. Have annotations in the proto files which do things like hint about primary keys, indexing etc.

kyrra• 11 years ago

How Google Inbox does it: Java and GWT

There was a presentation at GWTCreate where Ray Cromwell laid out some of the magic on how they used GWT to handle this. The slides for the talk are here[0]. One of the key pieces here is that coding in Java gets you the web (with GWT), Android, and iOS using j2objc[1]. They posted a demo app showing this off[2].

The videos aren't up for the talks yet, but the Keynote from GWTCreate is posted (Ray gave that talk as well)[3].

[0] http://goo.gl/5zNFEm

[1] https://github.com/google/j2objc

[2] https://github.com/Sfeir/jhybrid

[3] http://gwtcreate.com/videos/

Tobu• 11 years ago

The cross-compilation stuff is already addressed in the article. The jhybrid demo is a calculator and doesn't do storage.

dweis• 11 years ago

We use LevelDB.

72deluxe• 11 years ago

I never found the Android SQLite interface to be too clunky unless you try to use the helper functions. I always just used SQLiteDatabase.rawQuery() - what did you use?

All the helper functions felt like the ODBC abstractions that used to be all the rage, where you ended up typing 400x more code to abstract it than just writing some SQL.

Zigurd2• 11 years ago

mainly because on Android the SQLite wrapper is so clunky

Go straight for a ContentProvider, even if you are not sharing access to the data in SQLite. That makes it easier to build an observer pattern in Android. You can then build a SyncAdapter on the "back side" of this ContentProvider. Et voila, a synch'ed app.

mrinterweb• 11 years ago

I would imagine that something like this could be done with ruby using RubyMotion (builds native iOS and Android apps) and opal (compile to JavaScript).

badlogic3• 11 years ago

We've been using a similar approach for libGDX [1] with great success for the past 3 years. HotSpot on Windows/Linux/Mac OS X, Dalvik on Android, RoboVM [2] on iOS and GWT on the web. We had to add quite a bit of functionality to GWT to make things work, like (very hacky) reflection. You can now share 100% of your code across all these platforms with minor restrictions due to GWT (threads, missing JRE classes/packages). Without the web, all platforms work pretty much the same. Many smaller and bigger studios have used this approach quite successfully.

I wonder if the Google folks ever looked into RoboVM as a replacement for j2objc. It's a full AOT compiler, sharing the class library with Android with access to all iOS APIs (think Xamarin for Java/JVM languages). I tested j2objc when itmwas published as a potential way to get our libGDX stuff working on iOS, but it was extremely limited in its capabilities. Kinda reminded me of Oracle's terrible ADF.

[1] http://github.com/libgdx/libgdx [2] http://www.robovm.com

eropple• 11 years ago

Mario's not hiding any "well, kinda" bits when he says libGDX will run everywhere he mentioned--there are no second-class citizens in their world and it really benefits from that approach. RoboVM really is killer, and libGDX is too. Those guys certainly don't need me to validate their work, it speaks for itself, but anybody who is comfortable on the JVM and wants to make a game for the platforms libGDX supports should check it out.

edwinnathaniel• 11 years ago

It seems to me that RoboVM+libgdx is utilized heavily for the game industry. Correct me if I'm wrong, most games don't use UI components (most of the time it's a full-screen game) the way regular apps do so I'm wondering if RoboVM is a good fit for Rich-UI mobile apps?

badlogic3• 11 years ago

That's correct, most games will never touch the native APIs, except for things like IAP or Facebook/Game Center/Google Play Games Service integration.

RoboVM gives you full access to all iOS native APIs in idiomatic Java. Have a look at the Javadocs [1] to get a feel for how that looks like. Currently not wired up to the Apple docs, but that's on our roadmap. We have quite a few ports of official Apple demo apps [2], a simple hello world looks like this [3].

You can even extend ObjC classes as if they were Java classes and/or implement Protocols. Binding of native APIs (C, ObjC) is accomplished via something called Bro, which is annotation-based and a lot simpler and faster than using JNI.

So, yes, i think RoboVM is a good fit for Rich-UI mobile apps. Performance is great (we use LLVM), and the bindings are pretty complete. We currently lack interface builder integration, but that's on the short term road map (and for anything other than a quick prototype you don't use IB anyways).

[1] http://docs.robovm.com/api/1.0.0-SNAPSHOT/

[2] https://github.com/robovm/robovm-samples

[3] https://github.com/robovm/robovm-samples/blob/master/HelloWo...

[4] https://github.com/robovm/robovm-samples/blob/master/HelloWo...

microcolonel• 11 years ago

Yeah, I've played with it through OpenScienceMap[0], it's buttery smooth on everything, zero compromise.

I especially like the web browser support, it feels good to step entirely around the browser.

[0] http://opensciencemap.org/map/#&scale=16&rot=-18&tilt=46&lat...

skybrian• 11 years ago

How does this compare to PlayN? [1] Any relationship?

[1] https://code.google.com/p/playn/

badlogic3• 11 years ago

PlayN is more of a 2D engine, whereas libGDX is a framework you pick and chose functionality from. There's a lot of cross polinatiom between the two projects: we steal a lot of code from each other :)

JonathonW• 11 years ago

At least one team at Google has used libGDX (on top of RoboVM): Ingress uses libGDX for their iOS and Android clients.

RoboVM is a very cool project. We ended up on Xamarin for the cross-platform project we were working on here internally, but, had RoboVM been a little more mature when we were evaluating cross-platform projects (this was around April of last year), it would've most likely been our first choice instead (we have a lot more in-house Java expertise than C#).

PSeitz2• 11 years ago

I moved from J2ObjC to libGDX because of the ui layer, which is fully integrated in libGDX. Splendid work for the engine!

marpalmin• 11 years ago

What about something the other way around. Swift to Java?

mandeepj2• 11 years ago

Google Inbox shares 70% of its code across Android, iOS, and Chrome

In case you are starting now with a new app then i think the best bet would be to use React native where you would get to reuse 100%[1] code across the platforms.

Google wrote separate UI code for each platform but react native does that conversion also by itself and leaves you with even lesser work\code

[1] - as claimed by react team

notduncansmith• 11 years ago

I don't believe this was claimed by the React team. In fact, I distinctly remember Tom emphasizing that they're going for "learn-once, write-anywhere" rather than chasing the pipe dream of "write-once, run-anywhere".

UberMouse• 11 years ago

With React Native you still need to write the UI for each platform. But you can share the models/business logic between platforms because it's all Javascript.

dangoor• 11 years ago

React Native provides the React way of managing the UI and provides a bridge to Objective-C (and Java, once they've released the Android version). It doesn't provide JS bindings to all of the host APIs in a cross-platform way, so you can't just build a full featured app in JS and run it elsewhere.

Plus, the React people stress that you should use custom UI on each platform. The key is that you get to build the UI using the techniques that work so well for the web.

jdonaldson• 11 years ago

There seems to be solid success cases for implementing cross platform apps. Tivo recently redid its entire UI codebase in Haxe, and it's opened up a whole bunch of new platforms for them. http://www.slashgear.com/tivo-on-xbox-one-and-fire-tv-possib...

I'm sure it's a painful process, and it might slow down development for a while. But, the ability to push changes across the incredibly fractured mobile/web/native front end landscape seems like an incredible advantage.

mandeepj2• 11 years ago

can anyone point to resources to refer in case I like to write my own c# to objective C converter? looks like this is the next big wave in cross platform computing. It is truly amazing, Saves you ton of time.

Zuck also mentioned about facebook working on cross-platform platorm in last year's f8 conf.

okbake• 11 years ago

Does anyone know if theres a particular reason that I must activate my invitation with the mobile app in order to use Inbox on the web? I was looking forward to trying it out but its incompatible with all of my devices. Is Google just trying to push people with invites to try out the mobile application or is there some technical reason behind it?

PSeitz2• 11 years ago

J2ObjC is actually open source for years, they just moved the project to github.

sunasra• 11 years ago

This is big time problem when you are developing product which should support cross platform. The day will be awesome when we will say "Code once Deploy Anywhere with Native Experience!

jheriko• 11 years ago

70% is impressive?

where is this perception that proper cross platform development is an unsolved problem coming from? well written software has a platform layer which is usually small unless your product is trivial.

you also don't have to pay through the teeth with towering technology stacks.

maybe its connected to the fear of low level programming, or the fact that Google seem to not like using the established cross platform technologies, and made some pretty questionable decisions about the android development platform - like not giving a C/C++ compiler through the NDK for a long time despite the fact that everything they did was built on a foundation made with one so they obviously had it.

maybe they need a lot of platform specific code, but tbh i find that 70% a very unimpressive number. i would not even be impressed by 95%, i'd just call that 'normal'.

maybe this makes more sense of you are constrained to rapid application development, but given my experience with that a lot of the rational there is fallacious... i don't think i could build a cross platform app in a week without dropping down to C++/ObjC/Java and minimising the amount of Obj-C and Java as far as possible.

i suppose an important argument is that targetting the web with server side native stuff rather than client side java scripting things is a bit of a nightmare and lots of people don't even realise its an option...

D_Guidi• 11 years ago

I would not even be impressed by 95%, i'd just call that 'normal' probably, if you don't develop UI stuff.

sova• 11 years ago

wi h eventy per ent o t e code one c n re lly do a ot.

How Google Inbox shares 70% of its code across Android, iOS, and the Web

Related Stories