Objective-C and Android

views:

2525

answers:

+7 Q:

Objective-C and Android

I've just finished a relatively large project for the Android, and it's left a bitter taste in my mouth with the knowledge that it will never run on one of the most ubiquitous handsets this side of the solar system (the one by that fruity little club).

So, for my next project, I want to write it in a way that makes most of the components easily transportable between the iPhone and Android platforms. The way I'm thinking of doing this is by coding most of it in Objective-C, and then adding the platform-specific parts in more Objective-C and Java respectively. On the Android side, this will require using the the NDK.

My knowledge of C is good, but my knowledge of Objective-C is close to zero, and I have no desire to learn C++. How sane is the approach above, and is there a better one? Is there any way I can code in Java and still reach the un-hacked iPhone market? And how likely is it that the people I know (iPhone users) will have an Android phone by next year?

+8 A:

My guess, which has no experience to back it up, is that you probably could write Obj-C with Google's NDK somehow, given that GCC exists for ARM, is open source, has an Obj-C compiler and a basic Obj-C runtime (which if it doesn't already probably could be hacked up to work on a new architecture), etc.

That might also be a lot of work for questionable benefit.

And of course "Obj-C" (without the NS classes) means something very different than "Cocoa", which is what most people really mean when they say "Obj-C". You might be able to re-use some of GNUstep for some that, but... Honestly, I doubt it. Sounds again like a lot of work.

So, yes, I think it is possible. It's also a lot of work and I don't think it's worth it.

Given what you've said, if I were attempting this, I would be tempted to write as much of your core logic as possible in C, then wrap it with two separate GUIs for each platform.

asveikau 2010-03-06 22:12:50

This is becoming my new mantra... model (and any services/libraries/shared code) in C, view/controller in the most appropriate platform language / library.

rcw3 2010-03-06 23:50:44

+6 A:

Objective-C without Cocoa is not so useful and won't bring you much closer to haveing a working iPhone codebase. You'd probably be better off writing your core in C with Core Foundation and using either Java or Objective-C for the platform specific parts. Apple has open sourced a large chunk of Core Foundation as CF-Lite, and it's toll-free bridged with Cocoa on OS X (i.e. you can use many CF classes interchangeably with their Cocoa counterparts).

Chuck 2010-03-06 22:57:09

Thanks for your answer. The reason I specifically mention Obj-C as the language I'd like to code the core in (as opposed to C/C++) is that it has been recommended to me as being a very good C-based OOP language. How unusable is Obj-C without Cocoa?

Tom R 2010-03-06 23:09:28

Objective-C looks to me to be a perfectly reasonable language without Cocoa. Hardly anybody ever uses it without Cocoa, because there are more popular languages on all the non-Mac platforms, but I see no reason not to use it. It is part of gcc, so it should be available on pretty much any Unix or Linux platform.

David Thornley 2010-03-06 23:29:16

He didn't say Objective-C was *unreasonable* without Cocoa, just not nearly as useful. Imagine Java without any java.* and javax.* class, C without the standard library, C# without .NET, etc. A language may be great, but the corresponding code library is what really adds value for most people. Cocoa dramatically cuts the work that the developer must do to the point that without it, Objective-C is reduced to just a really interesting language. By itself, "interesting" doesn't pay the bills. More specifically, an iPhone app without Cocoa will be rudimentary and difficult to write and maintain.

Quinn Taylor 2010-03-07 01:23:53

Obj-C is a good core language. If I were using it without Cocoa/GNUstep I think the things I would miss the most are `retain` and `release` from `NSObject`, as well as `NS{Mutable,}{Array,Dictionary}` and all the supporting classes. But if you wanted to rewrite those and whatever else yourself I guess you'd have a good foundation to work with.

asveikau 2010-03-07 02:53:01

Yeah, that's kinda the key. If you didn't have all those things, you'd have to write them yourself from scratch. I agree that the core language is good. However, without the parts I use every day, it would be just another programming language to me. There are many solid languages that nobody uses. Like Smalltalk, on which Objective-C was based. Plenty of others come to mind, but perhaps that's because I spent a fair chunk of time in academia studying CS. :-)

Quinn Taylor 2010-03-07 04:33:58

+1 A:

I'm not sure about Android but with the iPhone you can essentially write straight C as long as you wrap it up in Objective-C classes.

James Raybould 2010-03-06 23:25:01

+12 A:

Step back and think about what in the end you will logically be able to share.

The UI models are fairly different, the components are different. In the end what you might be able to share is data object classes, possibly some algorithms. It's not even like you could realistically end up sharing network code as in the old days because you aren't directly using sockets, you are using HTTP libraries.

So will all of the effort you are putting into this really find a payoff in the end? It seems to me the end result will be a brittle mess that is hard to update, and is mediocre on both platforms instead of being great on either.

Why are you writing applications? To make life easier for you, or your users?

Kendall Helmstetter Gelner 2010-03-06 23:35:24

Is is too much to ask for both? :)

Tom R 2010-03-06 23:46:31

It is not too much to ask... but the universe is not prone to answering such requests very often!

Kendall Helmstetter Gelner 2010-03-07 02:41:18

It might surprise you, but even today, despite some people's best efforts, not all the world fits neatly into an HTTP request.

asveikau 2010-03-07 02:46:21

@asveikau That's a statement to print out and put up on a wall!

Giao 2010-03-07 05:14:36

I totally disagree with this comment. There is a large amount of behavior code that you can share across platform. Using an approach such as TDD would force you to separate the platform code from the business logic. Also there is a wide open market for consistent apps that work equally across handsets.

Cliff 2010-03-25 17:48:25

In my experience the behavior code is so marginal that it's not worth hamstringing the whole project to just share what amounts to a few pages of psudeocode. You can keep apps consistent without sharing code, even moreso if you are willing to front a lot of automated tests to ensure consistency.The reason to keep the code separate is one question: Do you want your application to be consistent, or great on whatever platform it runs on? You cannot have both. Apps that run the same across all platforms always have areas they could be improved.

Kendall Helmstetter Gelner 2010-03-26 05:19:15

+3 A:

Others have said basically this, but I'd like to make it more explicit. Your best bet is probably to write:

Cross-platform data models & core logic, using:
- bits of GNUstep (Obj-C), or
- CF-Lite (C), or
- Whatever you'd like, as long as it's cross-platform :P
iPhone-only interface code, using Cocoa Touch (Obj-C)
Android-only interface code, however they do it for the Android.

That's as close as you can get; any attempt to write cross-platform interface code will undoubtedly result in a mediocre app on both platforms. But making all the rest of your code portable and just wrapping a device-specific interface around it is done all the time and has been worked great for some iPhone developers.

andyvn22 2010-03-07 00:08:06

Best answer so far. This is very helpful for things like simple games, where a large amount of the code is game logic, and a far smaller amount accounts for rendering and UI.

Tom R 2010-03-07 00:21:02

I would disagree that CF-Lite is a good cross platform solution. Basically it's convenient for Mac programmers and no one else. I'd sooner suggest something like GLIB -- although that is a bit biased towards gtk+ programmers.

asveikau 2010-03-07 02:44:23

You're unlikely to find something that's convenient to use with both the iPhone code and the Android code; I figure why not choose something like CF-Lite that has toll-free bridging with NS classes? That way, at least ONE of your interfaces will be easy to write. :)

andyvn22 2010-03-07 04:18:40

+1 A:

... or simply focus on the Android version of your app. Soon it will be the shiny side of the solar system ;)

daliz 2010-03-07 00:40:06

... at least for definitions of "shiny" that ignore the degree to which most consumers prefer iPhone. Apple ain't perfect, but to ignore how well-orchestrated and successful the introduction and evolution of iPhone has been would be folly. Feel free to focus on the Android version, where you can attempt to sell to a smaller audience in a marketplace that strongly emphasizes free software (in both senses).

Quinn Taylor 2010-03-07 01:28:44

Why do I keep getting the feeling that Apple actually holds back consumer technology?

Tom R 2010-03-07 01:33:14

Beats me, but that's an interesting question, and one I'd like to actually see a convincing argument for. (I'd wager that most people who have watched the industry for at least the last decade would have the opposite opinion of Apple's effect on consumer technology. Apple is actually intensely focused on consumer experience, of which technology is *one* important part.) For example, few people remember that pre-iPhone, Android used to only live on devices with relatively small screens and physical keyboards. Android wouldn't be what it is today without iPhone, and vice versa.

Quinn Taylor 2010-03-07 04:29:46

Mr. Taylor's claim is false. iPhone (1st hardware, June 2007) predates Android (1st hardware, October 2008). There never was a time when "Android used to only live on devices with relatively small screens and physical keyboards". About the only mobile OS that would fit that description would be Blackberry, and perhaps Symbian.

CommonsWare 2010-03-07 13:50:48

@CommonsWare: I believe Quinn is talking about prototypes. There was a leak of an early Android phone prototype from HTC and it looked very much like those up-to-your-neck-in-buttons designs that were endemic to smartphones at the time.

Chuck 2010-03-25 17:59:13

That's possible -- I haven't seen any such prototypes. The only pre-1.0 devices I saw were your typical Android touchscreen-and-a-couple-of-buttons models.

CommonsWare 2010-03-25 18:13:35

+1 A:

Coming at this from a different angle... I know that you said you wanted to try and stick with Java, but if you know C# then you could go with the MonoTouch framework for the iPhone. Mono is essentially and open source implementation of the .Net stack. The Mono team is working on bringing Mono to the Android so you could basically write a shared C# library for your business logic and have different Views/Controllers per platform. This would all be in C# of course and it is a bit more expensive, but it does solve the problem of writing everything in different languages.

I believe it is called MonoTouch on the iPhone and MonoDroid on Android.

Ryan Ferretti 2010-03-07 01:17:25

Go with this, and get your store blocked from the AppStore. Apple doesn't want you going this way. The original question asker apparently already knew that too, and that's why he thought of the "okay, so we'll use Objective C everywhere" idea, which is also unworkable. Apple's restriction requires that your app be written "originally" in some combination of C, C++, and Objective C. Since C libraries are allowed, I don't see why the original asker would care at all about using ObjectiveC anywhere other than iPhone. Thus the question is a bit of an unusual one.

Warren P 2010-04-26 12:34:34

The Objective-C runtime has not been ported to Android yet. It shouldn't be too much work, but still, without a working knowledge of the language I doubt you'll have an easy time porting it.

What you are trying to do is going to be hard for a generic application, but should be possible for games, if you choose to develop the game in plain C (which is supported by both the Android NDK and the iPhone). You'd have to write up some glue code to pass input events from the Obj-C and Java environments into your C code, but that shouldn't be much of a problem - Objective-C allows you to directly call into your C code and there are plenty of example projects which do exactly this for Android.

wvdschel 2010-03-13 01:11:41

+1 A:

Cheap, Good, Fast... the universe only let's you pick two.

Brock Woolf 2010-03-13 04:48:31

I haven't tried this myself or finished watching the talk yet, but there is a Google Tech Talk on Developing iPhone Applications using Java up on YouTube that looks pretty promising.

Yanik Magnan 2010-03-13 16:40:11

If you can wait until later this year (exact amount of time unknown), Adobe will have AIR for Android and a compiler to iPhone. Thus you can write an app in AIR for the Android and use most of the same code to compile to the iPhone.

http://labs.adobe.com/technologies/flashcs5/appsfor_iphone/

Even if you can't wait see: http://www.insideria.com/2008/12/actionscript-to-cocoa---protot.html where it explains the similarities between ActionScript and Cocoa.

Also check out: http://labs.adobe.com/technologies/air2/ for the AIR version capable of using the touch screen.

So you can soon write once and deploy to Android and iPhone using ActionScript 3.

Todd Moses 2010-03-25 17:41:52

XMLVM is a project which is capable of translating (some) Android applications to the iPhone. For more infromation, visit http://xmlvm.org/android/

wvdschel 2010-03-26 12:26:11

ansaurus

tags:

views:

answers:

Objective-C and Android

related questions