
How Google Inbox shares 70% of its code across Android, iOS, and the Web - akrymski
http://arstechnica.com/information-technology/2014/11/how-google-inbox-shares-70-of-its-code-across-android-ios-and-the-web/
======
badlogic
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](http://github.com/libgdx/libgdx) [2]
[http://www.robovm.com](http://www.robovm.com)

~~~
edwinnathaniel
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?

~~~
badlogic
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/](http://docs.robovm.com/api/1.0.0-SNAPSHOT/)

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

[3] [https://github.com/robovm/robovm-
samples/blob/master/HelloWo...](https://github.com/robovm/robovm-
samples/blob/master/HelloWorld/src/org/robovm/samples/helloworld/HelloWorld.java)

[4] [https://github.com/robovm/robovm-
samples/blob/master/HelloWo...](https://github.com/robovm/robovm-
samples/blob/master/HelloWorld/src/org/robovm/samples/helloworld/viewcontrollers/MyViewController.java)

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

~~~
julianpye
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.

~~~
fidotron
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.

------
msoad
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
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
> It requires experience, vision and talent.

Also a team of solid engineers.

------
dblohm7
How Google Inbox shares 70% of its code across Android, iOS, and _Chrome_

FTFY

~~~
pachydermic
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.

~~~
cromwellian
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. :)

~~~
Touche
What are you doing that makes performance that bad? It sounds like GWT is
generating bad code...

~~~
cromwellian
It's nothing to do with JS code execution, the problem is in the rendering
engine, essentially too much repainting and rendering stalls, and too little
GPU accelerated animation paths.

Javascript is in a very good state these days in terms of cross browser
compatibility, and while CSS support has converged between browsers in terms
of correctness, CSS support has not converged on performance between browsers.
Safari, Chrome Firefox, and IE have wildly different animation performance
hazards on the same markup and debugging this often isn't trivial, for
example, finding out that the GPU is stalling on texture uploads deep inside
of the render loop.

One bright point, is that apps like Inbox are forcing these issues to the
front, as is libraries like Polymer/Material Design. As the issues are raised
and fixed, jank free rendering on mobile web platforms improves, hopefully
reducing the need for native apps.

~~~
AshleysBrain
Why is poor performance in one browser a reason to completely drop support for
that browser? If it works correctly albeit slowly, why not support it anyway?
Then the slow experience is motivation for the browser vendor to improve it as
well.

~~~
JshWright
Because users aren't going to blame the browser vendor for the poor
experience?

~~~
Touche
Users won't get to use the site at all.

------
therealmarv
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

~~~
sangnoir
> _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)

------
mandeepj
> 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
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".

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

~~~
wffurr
Source maps help a lot with that.

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

~~~
cpursley
Or perhaps their own projects like Angular and golang.

------
georgiecasey
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](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!

~~~
funkybro
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.

------
jdonaldson
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...](http://www.slashgear.com/tivo-on-xbox-one-and-fire-tv-
possible-after-adobe-ousted-11337096/)

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.

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

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

------
okbake
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?

------
ed_blackburn
I wonder if they considered Xamarin?

~~~
wffurr
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
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.

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

------
sunasra
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!

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

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

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

------
_random_
So, not Dart, not Go.

~~~
_almosnow
Eat your own dog food, they say.

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

------
jheriko
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
>I would not even be impressed by 95%, i'd just call that 'normal' probably,
if you don't develop UI stuff.

