** Unpaid mini-ad (Oct 31st 2012): **
Check out Yeecco’s StellaSDK. From my experiments with Stella and from interaction with the company, they may be a good choice if you need an easy-to-use solution right now, with as little work as possible. The PDF has not been maintained, and I have not experimented with improving the procedure; it may be good for improving the understanding of the problems, but if you need something that’ll work right now, talk to Yeecco — especially if you want to easily port a Cocos2d game.
** End of mini-ad **
** Unpaid mini-ad #2 (May 27th 2013): **
Another company that provides an SDK for easier porting of iOS apps to Android is Apportable. They have a free starter SDK (check out their plans) — and that’s the extent of my familiarity with their product, for now 🙂
** End of mini ad #2 **
** Clang in Android NDK! (Mar 20th 2013): **
Android NDK is now shipping with Clang. Additionally, there’s also some work on getting GNUstep Base to build for Android. Sweet! I’ll update this post with a link to additional information once this is proven to work okay.
** Rebuilding GCC (Jan 8th 2013): **
Instead of downloading prebuilt GCC, try rebuilding it.
– Instructions blogpost (with various reference links)
– Great presentation by Jackie Gleason
** End of rebuilding GCC **
I’m no fan of Java, and in fact, I’m not a fan of Android. When I originally heard Google is working on a Linux phone, I rejoiced. When I heard that Java would be the base of the userland, and that no existing program for Linux would be directly supported, my heart sank. In the meantime I became a big fan of Objective-C, Cocoa, Cocoa Touch, Mac, and all related technologies and projects.
So, I want to keep working in Objective-C. I sat down and studied my options. We have the Android SDK, we have the Android NDK, and a third party offering called Android NDK GCC 4.2.1 with Objective-C support.
SMALL UPDATE, May 8th 2012: I have not tested this, but here’s the CrystaX .NET Improved Android NDK. Thanks to jeffamaphone for pointing it out. I did not test it, but r7 ships with GCC 4.6+.
Studying all this takes a while. Well, more than a while. I spent a day or two wrapping my head around all this, reading Android documentation. All this not counting stuff that I read, heard and discussed in previous months on this subject.
Android SDK is documented well enough, as long as you stick to Java. Android NDK is not particularly well documented, but solidly enough. Playing with the Objective-C is however a bit more complex, especially since Android NDK by itself does not come with Objective-C support turned on. Authors of the add-on compiler for Objective-C did not publicly document its proper use at all. Its use is nearly ungoogleable.
Since I’d hate to see you, my little lemon drops, spend as much time as I did on studying all this, here is something that will help you understand the complexities of the design of NDK, and how to combine all this with the Objective-C compiler.
Proficiency with GNU Make and Objective-C is highly recommended.
Proficiency with Java and Android is not required (I have none).
Not much in this article depends on Mac OS X apart from the paths, and the fact that there is no prebuilt Objective-C compiler for platforms other than Mac OS X. Parts that are about SDK and NDK should cleanly apply to Linux version of the Android SDK and NDK. It probably cannot easily apply to Windows.
Update on December 7, 2011: I just learned about a great presentation by Jackie Gleason (@LifeIsTooShort) on the same subject: Adding Objective-C Support to the Android NDK
If you wish to do so, you can donate me via PayPal for writing this PDF. Definitely not mandatory, though!
You can also send me other amounts directly via PayPal to address: ivucica@gmail.com
–
via blog.vucica.net
I have been trying to find a simple way to do AMF remoting calls on android. There does not seem to be a well suited way to do this other than flash/flex… CocoaAMF is very developed for Objective C world. I thought this may be a good solution (using your article), until I got to the bottom of your PDF doc and realized that CocoaAMF is based on Foundation Framework and I would have to port than to Cocotron or find someone else who had done that. AHHHHHH. This was very helpful, as you said, it was not very googlable.
Great post! I would love to see a port of GNUstep's base (Foundation) and gui (AppKit) made to this. It would be easiest to start with Foundation since it's non-graphical.
GC
Jackie Gleason is currently trying to do exactly that, and we're discussing this on the gnustep-dev mailing list 🙂
Would you explain why you prefer objective-C over Java?
1. Native code.
2. Native code, second time. Because native code means you can reuse existing C or C++-based libraries more easily.
3. It's C. (So, native code — third time.)
4. Doesn't have senseless limitations like the 'final' qualifier on classes.
5. Doesn't have senseless limitations like the one-class-per-file rule.
6. Doesn't depend on garbage collection — manual reference counting is available, performance is more easily fine tunable.
7. Far, far more lightweight. Look at how long it takes for Java web browser plugin to load. Sure, once it loads, there isn't much speed issues today. I still feel that the language itself is a big troublemaker.
8. I get the feeling that it's more portable. Sure, you need to get the compiler to target the target platform and the runtime to run on the target platform — but then, if you need just the language, you're done. If you need frameworks, there's more work, but still I personally get the feeling that getting Java to run is more involved.
9. In frameworks, class hierarchy and packages end up meaning just that you have to type more and think of more. Implementation of generics/templates/whateveryouwannacallit is more annoying than having an all-purpose type like id (a.k.a. 'warningless NSObject') used for all contents of an array.
Objective-C is conceptually a very thin layer above C. I like a lot of sensible framework-suggested coding conventions in Objective-C that improve code cleanliness, and improve self-documenting code. I dislike a lot of unnecessary language-enforced 'conventions' in Java, which are more of an imposed dictator-decrees than actual conventions. If I violate a widely-accepted convention in Objective-C, I'm an idiot; if I violate a senseless dictator's decree in Java, I get a compiler error which makes me feel someone wants me to get the hell out of there.
Since this post I've had Java as a class on university, which is one of the reasons why I can be more opinionated about it (e.g. about conventions and about 'final'). At the same time, it also increased my appreciation of the language. It isn't all that terrible; rather, it just feels very 'inspired' (shall we say) by NeXT's work and by Stroustrup's work, with a lot of rules splattered around that may have seemed sensible during language development, but in practice are bound to cause a lot of trouble. ('final' comes to mind.)
I absolutely love the fact that it isn't all that hard to understand how internals of Objective-C work — how inheritance works, what the memory layout of a class instance (an object) is, how to send a message through a C api, how to add language bridge with one's own scripting language, how to perform your own possibly better dynamic memory allocation in Foundation implementations that provide better support for NSZone…
I don't like the fact that internals of Java are pretty much something one does "not need to worry about" and are a black box.
Yep, I wrote a very subjective response, which depends a lot on tastes and may reveal my lack of knowledge of Java, but I suspect and hope you didn't expect anything different 🙂
Pingback: ObjC code in Android using ndk under Linux
Thank You.