Google offers tool to bridge Android and iOS app dev(theregister.co.uk)
theregister.co.uk
Google offers tool to bridge Android and iOS app dev
http://www.theregister.co.uk/2012/09/15/google_j2objc_tool/
7 comments
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).
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).
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.
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.
My guess would be that the goal was to encourage cross-platform developers to work on the Android version first. Am I close?
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.
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.
This was not a summer of code project. It was sponsored by several major Google projects with multiple contributors from their teams. I worked on the project as an intern.
How are you handling translation of exceptions to ObjC given that none of the OS frameworks are themselves exception-safe?
Right now it's just using Objective-C exceptions. Your iOS code that calls into the J2ObjC-translated Java code will have to handle the exceptions.
Does j2objc ensure that internal exceptions never bubble through framework stack frames? Also, I believe arc itself is not exception-safe.
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.
Toss in lua(jit) and you have a nice dev environment. I wrote a lua->java bridge and modified LTC (lua tiny cocoa, a lua objective c bridge) and with those you can write nearly your entire cross-platform app (ui, too) in C / Lua.
And with luajit's FFI support, it's almost a better C than C.
And with luajit's FFI support, it's almost a better C than C.
Interesting. I do like to use the native gui Api for each platform to get the native look/feel. Does lua/jit have its own implementation of buttons, tableviews and such or does it use the native controls of the system?
Well, that's the point of the java and objective-c bridge: it lets you call out to native APIs, so you have all native components.
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/
[1] https://webkeks.org/objfw/
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.
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.
"the gcc they include in the NDK has Objective C disabled for seemingly no reason" - I wonder how heavily they modified gcc to cope with security models etc. Quite possibly there's a very good reason. It might have been a ton of work to get it working properly.
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?
Do you have any code you can share? Are there any resources in general I should check out?
Seconding this. Any books or articles worth reading?
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.
> If there is enough interest I can create a small article describing the process and post a starter project on github.
I think you'd find a lot of interested for that. I'd appreciate it a lot.
I think you'd find a lot of interested for that. I'd appreciate it a lot.
If you're doing game development, check out cocos-2dx. It's a c++ port of the cocos2d-iphone framework. Here's some more info: http://www.cocos2d-x.org/projects/cocos2d-x/wiki
There you go - cross platform iOS / Android / Mac / Linux / Windows development.
The only thing missing is...the browser.
We're doing the same thing, but with JavaScript as the application code, and unique front-ends for HTML5 browsers, older browsers, Android, iOS, mobile browsers, etc.
It's trivial to get a JavaScript VM running on any given platform.
The only thing missing is...the browser.
We're doing the same thing, but with JavaScript as the application code, and unique front-ends for HTML5 browsers, older browsers, Android, iOS, mobile browsers, etc.
It's trivial to get a JavaScript VM running on any given platform.
Why do you say the browser is missing? My app, in certain parts, uses the native OS's Webkit views for rendering all kinds dynamically generated mustache forms. In fact, there are all kinds of javascript hooks that call native OpenGL code.
I am afraid that debugging your c++ code on Android will be a lot of pain.
It is a pain to debug C++ on Android even if gdb comes with the ndk. Practically speaking, it turns out debugging C++ code can be done on any platform (Xcode on Mac, codeblocks on Linux, whatever). My entry point C++ class has a unit test that tests all the components... I have yet to find a significant bug that was not reproducible on another platform one way or another. For the record, if you dont want to figure out the NDK gdb setup mess, printf outputs to logcat.
The NDK includes gdb.
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"
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"
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.
"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.
Can someone sum up how it does the conversion?
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.
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.
> 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.
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.
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.
That and the demotion of native code in Android (native code there calls Java libraries) really make me question a lot of things.
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.
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.
[deleted]
[deleted]
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.
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.
But some (most Java devs?) devs look like they are "only Java" right now.
This is a Google project. I'm refuting the idea that we're loaded with "java developers" who can't step outside their skillset.
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) 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).
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) 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).
While there's a ton of Android apps, I'm pretty sure there's already a large part that targets iOS first simply because of how long iOS/app store has been around compared to Android.
Not to mention the iOS SDK is much nicer.
I think this is debatable. It's lamentable seeing it said as a truism without supporting information.
Speaking as someone who has developed on both platforms, it's definitely my experience. And that includes starting with an Android app and porting it to iOS - half of the stuff I had to add to Android to make it usable I discovered they had already built into iOS. Not to mention the poor choice of defaults, coping with device fragmentation, and the difficulty making Android apps look attractive via-a-vis iOS.
I haven't built ICS apps, though, so perhaps it's getting better.
I haven't built ICS apps, though, so perhaps it's getting better.
It will be so much better to have Objective C Runtime on Android. I haven't seen any java based Android apps that run smoother than Google Chrome on Android, which I highly suspect that it was built using C/C++ instead of Java.
Learning ObjC is a one-time cost I've already paid. The problem is being continually confronted with all the compromises it made against safety and readability just to rush out semi-usable implementations thirty years ago. It's no longer necessary to regress to C and risk crashes and random misbehavior from unchecked pointer arithmetic and integer overflow and uninitialized memory, and debugging that (while sometimes fascinating) has long been a poor use of hackers' time.
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.
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.
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.
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.
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.
- 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.