8 ms·

Google offers tool to bridge Android and iOS app dev

85 points by iProject 14y ago

Evbn 14y ago
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 14y ago
  > 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 14y ago
    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 14y ago
      That sounds like too much logic is in your UI.
raverbashing 14y ago
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.
- watty 14y ago
  Or it's a free tool that will save time for some developers who aren't "pro" Obj-C developers. Not much to complain about.
- stusmall 14y ago
  How so? Looks like an opportunity to have some common code between the two platforms to me. Write your view layers twice. If you have a large amount of business logic write it once in Java and then part of the build or checkout process for iOS can be to translate this code to objective-c. I've recently been diving into mobile dev and the short list of good options on having a common code base between the platforms seems so strange to me.
  - cromwellian 14y ago
    Actually common code on 4 platforms. We share Java code between the server, the web (via GWT), Android (already runs Java natively), and now iOS (via j2objc). That's basically the reason for this. We have huge amounts of Java libraries, and we want to create and ship out features on 3 platforms simultaneously. Not having to write, say, an Operational Transform library 3 different times (JS, Java, and Objective-C) and keep them constantly in sync will go a long way.
- tomjen3 14y ago
  Actually this has nothing to do with Java developers, as much as people here likes to look down on them. This has to do with calling a single command and blasting out an app for IOS once you have already written an app for Android. If you note carefully Google could have done it the other way around, by implementing IOS shims on top of Android. This would have been easier (as Google controls Android) and because Objective C code is low level code that is easier to port to high level Java code. And it would have given an incentive to those who have already written IOS apps to port them to Android. So why not do it that way? Because then everybody would develop for IOS first and Android second and few people would use the Android specific features. By going from Android to IOS, Android is the primary system, but Google still lover the cost of development of Android apps by having the IOS market articficially subsidise it. It is the classing Jole post (http://www.joelonsoftware.com/articles/StrategyLetterV.html http://www.joelonsoftware.com/articles/StrategyLetterV.html) with the twist that Google is lower the price of the complements to its complements (ie. smart phones are complements to Google ads and apps are complements to smart phones).
rburhum 14y ago
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.
- kvnn 14y ago
  This is the first I've heard of this approach and I want to hear more. Do you have any code you can share? Are there any resources in general I should check out?
  - 54mf 14y ago
    Seconding this. Any books or articles worth reading?
    - rburhum 14y ago
      The Android jni documentation shows how to call C++ and is the only doc I have glanced through. If you stick to passing ints,doubles and strings through it it is really easy. For iOS is way simpler, since your wrapper is just a file that ends with ".mm". Google it. If there is enough interest I can create a small article describing the process and post a starter project on github.
dhconnelly 14y ago
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.
- saurik 14y ago
  Yeah... I developed a bridge (not a native compiler) from Java to Objective-C for the iPhone (called JocStrap: Java/Objective-C bootstrap, for use with the JamVM, which I also ported) back when the device first came out, and I had a ton of people who would contact me because they thought it would make it so they didn't have to learn Objective-C, or that that would be the only reason to want it... I then had to keep explaining to these developers that "in fact, to use this kind of bridge, you will need to be both an expert at Objective-C and an expert in Java, or you will likely run into some horrible semantic mismatch between how your code at the boundary operates and what the two runtimes each require"; it seems like the same is true of your J2ObjC (especially with regards to memory management).
- prof_hobart 14y ago
  My guess would be that the goal was to encourage cross-platform developers to work on the Android version first. Am I close?
  - georgemcbay 14y ago
    I would guess at least part of the goal would be to minimize dependence on the NDK for cross-platform "business logic". One of the more common ways to share code between Android and iOS now is to have a library written in C/C++ which is linked via NDK on Android and wrapped in ObjC/ObjC++ on iOS. In an all plain-ARM world this is no big deal, but the more CPU types you add the more of a pain this becomes on the Android side despite some support in the SDK for "fat binaries" (you still have to anticipate and compile for all those arches, whereas Java/Dalvik code will "just work" regardless of underlying CPU). Given Intel's recent push into Android along with the continued divergence of ARM into lots of branches with different features, different SIMD instructions, etc, this seems like a pretty useful solution to that problem. Either way, this was a Summer of Code project. I doubt Google gave a ton of thought to how it fits into their overall global strategy for Android development as many bloggers seem to be theorizing about.
mrwilliamchang 14y ago
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 14y ago
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 14y ago
Can someone sum up how it does the conversion?
- dhconnelly 14y ago
  http://code.google.com/p/j2objc/wiki/DesignNotes http://code.google.com/p/j2objc/wiki/DesignNotes

85 points by iProject 14y ago

Evbn 14y ago

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 14y ago
> 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 14y ago
  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 14y ago
    That sounds like too much logic is in your UI.

raverbashing 14y ago

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.

watty 14y ago
Or it's a free tool that will save time for some developers who aren't "pro" Obj-C developers. Not much to complain about.
stusmall 14y ago
How so? Looks like an opportunity to have some common code between the two platforms to me. Write your view layers twice. If you have a large amount of business logic write it once in Java and then part of the build or checkout process for iOS can be to translate this code to objective-c. I've recently been diving into mobile dev and the short list of good options on having a common code base between the platforms seems so strange to me.
- cromwellian 14y ago
  Actually common code on 4 platforms. We share Java code between the server, the web (via GWT), Android (already runs Java natively), and now iOS (via j2objc). That's basically the reason for this. We have huge amounts of Java libraries, and we want to create and ship out features on 3 platforms simultaneously. Not having to write, say, an Operational Transform library 3 different times (JS, Java, and Objective-C) and keep them constantly in sync will go a long way.
tomjen3 14y ago
Actually this has nothing to do with Java developers, as much as people here likes to look down on them. This has to do with calling a single command and blasting out an app for IOS once you have already written an app for Android. If you note carefully Google could have done it the other way around, by implementing IOS shims on top of Android. This would have been easier (as Google controls Android) and because Objective C code is low level code that is easier to port to high level Java code. And it would have given an incentive to those who have already written IOS apps to port them to Android. So why not do it that way? Because then everybody would develop for IOS first and Android second and few people would use the Android specific features. By going from Android to IOS, Android is the primary system, but Google still lover the cost of development of Android apps by having the IOS market articficially subsidise it. It is the classing Jole post (http://www.joelonsoftware.com/articles/StrategyLetterV.html http://www.joelonsoftware.com/articles/StrategyLetterV.html) with the twist that Google is lower the price of the complements to its complements (ie. smart phones are complements to Google ads and apps are complements to smart phones).

rburhum 14y ago

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.

kvnn 14y ago
This is the first I've heard of this approach and I want to hear more. Do you have any code you can share? Are there any resources in general I should check out?
- 54mf 14y ago
  Seconding this. Any books or articles worth reading?
  - rburhum 14y ago
    The Android jni documentation shows how to call C++ and is the only doc I have glanced through. If you stick to passing ints,doubles and strings through it it is really easy. For iOS is way simpler, since your wrapper is just a file that ends with ".mm". Google it. If there is enough interest I can create a small article describing the process and post a starter project on github.

dhconnelly 14y ago

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.

saurik 14y ago
Yeah... I developed a bridge (not a native compiler) from Java to Objective-C for the iPhone (called JocStrap: Java/Objective-C bootstrap, for use with the JamVM, which I also ported) back when the device first came out, and I had a ton of people who would contact me because they thought it would make it so they didn't have to learn Objective-C, or that that would be the only reason to want it... I then had to keep explaining to these developers that "in fact, to use this kind of bridge, you will need to be both an expert at Objective-C and an expert in Java, or you will likely run into some horrible semantic mismatch between how your code at the boundary operates and what the two runtimes each require"; it seems like the same is true of your J2ObjC (especially with regards to memory management).
prof_hobart 14y ago
My guess would be that the goal was to encourage cross-platform developers to work on the Android version first. Am I close?
- georgemcbay 14y ago
  I would guess at least part of the goal would be to minimize dependence on the NDK for cross-platform "business logic". One of the more common ways to share code between Android and iOS now is to have a library written in C/C++ which is linked via NDK on Android and wrapped in ObjC/ObjC++ on iOS. In an all plain-ARM world this is no big deal, but the more CPU types you add the more of a pain this becomes on the Android side despite some support in the SDK for "fat binaries" (you still have to anticipate and compile for all those arches, whereas Java/Dalvik code will "just work" regardless of underlying CPU). Given Intel's recent push into Android along with the continued divergence of ARM into lots of branches with different features, different SIMD instructions, etc, this seems like a pretty useful solution to that problem. Either way, this was a Summer of Code project. I doubt Google gave a ton of thought to how it fits into their overall global strategy for Android development as many bloggers seem to be theorizing about.

mrwilliamchang 14y ago

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 14y ago

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 14y ago

Can someone sum up how it does the conversion?

dhconnelly 14y ago
http://code.google.com/p/j2objc/wiki/DesignNotes http://code.google.com/p/j2objc/wiki/DesignNotes