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.
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#).
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?
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).
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.
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 :)
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.
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.
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.
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].
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.
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.
> 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.
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?!
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.
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.
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.
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. :)
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.
Extremely interesting! Would love to see blog posts on debugging GPU stalling during browser render loops, but I suppose you are all probably too busy actually doing that really hard stuff to be writing blog posts about it!
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.
You can spoof the user agent in Firefox and see for yourself. It's _really bad_, bordering on completely unusable (at least, it was at launch). Inbox uses a lot of animation, and having that animation run at a couple frames per second makes an exceptionally poor user experience.
If I worked on Inbox, I wouldn't feel comfortable releasing anything like that on Firefox either, even if it was gated with a disclaimer. It wouldn't reflect well on Google or Mozilla.
That would require them to file bugs against the browser. In the case of the sparse array issue, nobody had filed anything until a Mozillian read about the issue here on HN. It was fixed in Nightly the same day.
Inbox is a showcase for Material design, which makes heavy use of animations. If you don't need the animations, you can just use the gmail.com page anyway.
for me it keeps spinning on their own loading widget (the main UI shows up, but the loading bubble at lower left never goes away), and I cannot open any of the emails. This is with firefox 36 beta 6.
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
> 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)
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.
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).
> 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
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".
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.
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.
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).
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!
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.
> 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.
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.
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).
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?
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.
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!
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.
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...
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