
Google offers tool to bridge Android and iOS app dev - iProject
http://www.theregister.co.uk/2012/09/15/google_j2objc_tool/
======
dhconnelly
I worked on this project this summer at Google, and I've been cracking up at
the news coverage and HN/Reddit comment threads for a couple of days now.
Here's why:

\- People love to spout off about why Google does this or that. I guarantee
you that the goal of this project is NOT to help "lazy developers" avoid
learning Objective-C. Effective use of J2ObjC _requires_ you to use
Objective-C and Xcode.

\- Many developers seem to think that application architectures from their
particular domains of expertise are universal or most important. There are
many apps for which "core business logic", and not UI code, dominates.

\- Small-team/single-platform/large-team/multi-platform developers seem to
have trouble imagining what it's like to be on the other side.

\- Reading non-technical articles about a technical project that you've worked
on is bizarre.

~~~
RealCasually
Thanks for posting here. How does this project relate to XMLVM (from Google
employees)? We used that in order to bridge an Android app to iOS and found it
to be pretty impressive. Is this based on that foundation, or a purely new
effort? The main difference I see from XMLVM is that it tried to also bridge
some aspects of UI, as well as was a bit more generic to attempt to bridge to
C and C# as well.

~~~
dhconnelly
This is a new effort. The tool produces Objective-C output that is
"reasonably" close to what a human might write, so that the sources can be
more easily integrated with other Objective-C code in an iOS app and debugged,
whereas XMLVM output looks like bytecode.

------
rburhum
Yeah, I already write cross-platform code with C++ and it is really not as bad
as anyone leads you to believe. Create one single C++ entry point object that
drives everything else. Use sqlite for storage, jsonc for
serializing/deserializing json, pthreads for threading and curl for making
network requests. Your main c++ class has to also receive the events (like
touch) and forward as appropriate. You can leverage STL and boost if you wish.
For iOS, you end up dragging and dropping the entire project to XCode - valid
C++ code is valid Objective C++. For Android, you just use the ndk to create a
simple Java class that mirrors your entry point C++ class and the
implementation is just JNI calls to the C++ class. It is common to have a
secondary "utilities" class that does hardware specific things if you wish.
Your GuI is quickly put together using the standard OS tools - but as long as
you stick to forwarding the work to the main C++ class, all that GUI code
tends to be minimal (except for really fancy platform specefic GuI code like
transitions). Oh, and I use OpenGL for drawing most cool things, so I get to
reuse that, too - not to mention all my code is _really_ fast. There you go -
cross platform iOS / Android / Mac / Linux / Windows development.

~~~
jrajav
I've tried using the NDK too, specifically to compile the Objective C
framework ObjFW [1] on one of the few platforms where it's not yet confirmed
working. Unfortunately, the gcc they include in the NDK has Objective C
disabled for seemingly no reason, and bootstrapping your own gcc or clang
toolchain is pretty tough. I'm sure you don't see as much of a need with C++,
but have you ever tried replacing parts of the toolchain?

[1] <https://webkeks.org/objfw/>

~~~
kkowalczyk
There is a very good reason for disabling Objective C in NDK.

Objective C, the syntax, has very little value without Objective C
runtime/standard library and Objective C runtime/stdlib is huge (compared to C
and C++ standard libraries).

NDK has a very specific goal: if the code would be too slow when compiled to
Dalvik VM, you can get speed with NDK, writing in C/C++, but at the cost of
loosing access to almost all of the APIs that Android provides. This tradeoff
more or less makes sense only for games.

Implementing Objective C runtime and standard library would be huge
undertaking and the code, when used, would occupy more memory. Also, this code
would mostly duplicate C++ standard library, just with a different syntax.

It doesn't make sense to allow people using Objective C in NDK.

------
mrwilliamchang
I love this quote from the article. "Several Google projects rely on [J2ObjC],
but when new projects first start working with it, they usually find new bugs
to be fixed,"

And also "If you'd like to join the bug hunt, the full source code for J2ObjC
is available now under the Apache open source license"

------
weej
I'm not opposed to bridge software; however, I'm always skeptical when I hear
things like this.

"Google says J2ObjC works with most build tools, including Xcode and Make, and
that the translation from Java to Objective-C is totally automated. No
additional editing of the Objective-C source code output by the tool is
necessary."

The proof is in the pudding. I guess I'll have to check it out.

------
mitchellmckenna
Can someone sum up how it does the conversion?

~~~
dhconnelly
<http://code.google.com/p/j2objc/wiki/DesignNotes>

------
Evbn
Technically cute, but works only for non-UI modules, which comprise
approximately 4% of a mobile app.

Anything with a large backend is likely an intensive game, and aren't those
cores written in native C/C++ anyway?.

Someone please take an app in Objective C, convert it to JS with route 66,
convert to Java with (?) And convert back to Obj C with this tool, and share.

~~~
flatline3
> _Technically cute, but works only for non-UI modules, which comprise
> approximately 4% of a mobile app._

Where on earth did you get that number?

UI code in a well-structured application is a thin-shim on composed, testable
backend code. It should be the least of the code, by far.

~~~
jkubicek
This is highly dependent on the app. All iOS projects I've worked on have been
50-80% UI code sitting on top of a pretty thin set of persistance and
networking classes.

~~~
flatline3
That sounds like too much logic is in your UI.

------
raverbashing
Looks like lots of time wasted in pro of "java developers" who can't be
bothered to leave their confort zone and learn something else.

That and the demotion of native code in Android (native code there calls Java
libraries) really make me question a lot of things.

~~~
jrockway
There are a lot more Java libraries than Objective-C libraries. Especially at
Google.

We write a lot of Java at Google, but I wouldn't call anyone a "Java
programmer". We're just programmers. And like all programmers, if we can save
time by writing a tool and letting the computer do some work, we will.
Laziness, impatience, hubris, and all that.

~~~
adgar
My 5-engineer team at Google all write java day-to-day. But we've all needed
to write python, especially scripts, and have it properly checked in and
maintained. Not sure how you could get by most places in the company without
being able to do that. Besides, skill in other languages is an asset; I've
written C++ client library code to push for broader adoption of my project.

~~~
raverbashing
Well, Google is a different game, and I'm sure most programmers there are
versed in at least a couple of languages.

But some (most Java devs?) devs look like they are "only Java" right now.

~~~
adgar
This is a Google project. I'm refuting the idea that we're loaded with "java
developers" who can't step outside their skillset.

