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?
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.
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.
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 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.
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!
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.
[+] [-] badlogic|11 years ago|reply
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
[+] [-] JonathonW|11 years ago|reply
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#).
[+] [-] edwinnathaniel|11 years ago|reply
[+] [-] eropple|11 years ago|reply
[+] [-] skybrian|11 years ago|reply
[1] https://code.google.com/p/playn/
[+] [-] microcolonel|11 years ago|reply
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...
[+] [-] PSeitz|11 years ago|reply
[+] [-] fidotron|11 years ago|reply
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|11 years ago|reply
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.
[+] [-] kyrra|11 years ago|reply
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/
[+] [-] terhechte|11 years ago|reply
[+] [-] 72deluxe|11 years ago|reply
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.
[+] [-] Zigurd|11 years ago|reply
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.
[+] [-] dweis|11 years ago|reply
[+] [-] msoad|11 years ago|reply
[+] [-] valisystem|11 years ago|reply
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.
[+] [-] Rygu|11 years ago|reply
[+] [-] ma2rten|11 years ago|reply
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.
[+] [-] dblohm7|11 years ago|reply
FTFY
[+] [-] pachydermic|11 years ago|reply
[+] [-] therealmarv|11 years ago|reply
[+] [-] sangnoir|11 years ago|reply
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|reply
[+] [-] scopendo|11 years ago|reply
[+] [-] trekkin|11 years ago|reply
[+] [-] mandeepj|11 years ago|reply
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|reply
[+] [-] dangoor|11 years ago|reply
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.
[+] [-] UberMouse|11 years ago|reply
[+] [-] mooreds|11 years ago|reply
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|11 years ago|reply
[+] [-] zackify|11 years ago|reply
[+] [-] cpursley|11 years ago|reply
[+] [-] georgiecasey|11 years ago|reply
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!
[+] [-] jdonaldson|11 years ago|reply
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|11 years ago|reply
[+] [-] mrinterweb|11 years ago|reply
[+] [-] okbake|11 years ago|reply
[+] [-] ed_blackburn|11 years ago|reply
[+] [-] wffurr|11 years ago|reply
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.
[+] [-] pm|11 years ago|reply
[+] [-] zodiakzz|11 years ago|reply
[+] [-] PSeitz|11 years ago|reply
[+] [-] sunasra|11 years ago|reply
[+] [-] mandeepj|11 years ago|reply
Zuck also mentioned about facebook working on cross-platform platorm in last year's f8 conf.
[+] [-] encoderer|11 years ago|reply
[+] [-] sova|11 years ago|reply
[+] [-] _random_|11 years ago|reply
[+] [-] chrisan|11 years ago|reply
[+] [-] _almosnow|11 years ago|reply