46

I'd consider myself pretty well versed in C#. It's my language of choice at the moment, and it's where basically all my professional experience lies.

Still, I'm puzzled by the existence of the MonoDroid project. My understanding has always been that C# and Java are very close. Like, if you know one, you can learn the other really quickly. So, as I've considered developing my first Android app, I just assumed I would familiarize myself with Java enough to get started and then just sort of learn as I go.

Wouldn't this make more sense than using MonoDroid, which is likely to be less feature-rich than the Java Android SDK, and requires learning its own API (albeit a .NET API) anyway? I just feel like it would be better to learn a new language (and an extremely popular one at that) and get some experience in it—when it's so close to what you already know anyway—rather than stick with a technology you're experienced with, without gaining any more valuable skills.

Maybe I'm grossly misrepresenting the average potential MonoDroid user. Maybe it's more for people who are experienced in Java and .NET and just prefer .NET. Or maybe (in fact it's likely) there are other factors I just haven't considered. I'm just wondering, why would you use MonoDroid instead of just developing for Android using Java?

Dan Tao
  • 1,201
  • 2
  • 10
  • 16
  • 11
    Google the phrase "is the new COBOL" and see what language google comes up with... – John Reynolds Jan 02 '11 at 13:07
  • 1
    @JohnReynolds Ironic then that the fastest growth right now is in mobile and Android, using "the new COBOL". Whatever way you slice it, even if you choose MonoDroid, if you're developing for Android, you are still relying on "the new COBOL". – Jason S Jan 04 '12 at 22:29
  • 1
    "the new COBOL" refers to the language, not the VM (be it JVM or Dalvik). So MonoDroid does not rely on "the new COBOL" and neither does Scala and Clojure or any other JVM language. – John Reynolds Jan 24 '12 at 16:18
  • There's a vast amount of the old COBOL still around, too. – Alan B Jul 05 '12 at 12:55
  • @JohnReynolds The ironic thing is that most of the code that is running today is COBOL; and most ironic is the fact that C# is a clone of Java (and a poor one since it cloned most of the wrong things also). – Random42 Mar 28 '13 at 09:39

5 Answers5

55

Any competent C# programmer should be able to quickly pick up enough Java to write an Android program, but that's not the point. It's a matter of code reuse.

Think about six months from now, when your Android program is popular and your users are asking for a version for iPhone and Windows Phone 7. If you had used MonoDroid, you can reuse most of your application logic with MonoTouch (Mono for iOS) and the Windows Phone SDK. Now they want a web-based version, so you include the same class libraries in an ASP.Net project. Desktop versions? No problem, that same class library works with .Net under Windows or Mono on Linux and OS X.

Other than C or C++, I can't think of any other languages that would let you reuse the same code on all of those targets.

Edit to address some concerns in the comments: .Net and Mono will not let you write a complete program and use that same program everywhere. They will let you share some code, and like all cross-platform programming the amount of shared code depends on the type of programs you're writing and how well you separate the UI and hardware code from the application logic.

However, if you write your Android app in Java, how much of that is reusable on iOS or Windows Phone? That's the point I was trying to make. I had existing C# libraries that were working on Mono for Android in much less time than it would have taken to reimplement them, even though I already knew Java. I have some code that is shared--unmodified--between a web site, desktop programs, and mobile apps on two different mobile platforms, thanks to Mono.

I didn't mean to imply, even indirectly, that Mono was the perfect tool for every mobile development situation. It's a tradeoff, but I firmly believe that there are situations when Mono is a much better choice.

Please see (and upvote!) Jason S's answer for another perspective.

Kevin
  • 666
  • 5
  • 5
  • 12
    And I thought that Java was the one with the slogan "write once run everywhere"! – Luciano Jan 19 '11 at 19:56
  • 3
    @Luciano - the same arguments *could* be applied if the OP had said he knew Java as was wondering whether to learn C#. The important bit is the code reuse, not the language. – ChrisF Jan 19 '11 at 19:58
  • These were all good answers, but I think this one's my favorite. – Dan Tao Feb 03 '11 at 21:41
  • 1
    Bingo, can't get a much better answer than this. We just invested heavily in Mono for Android at work for just this reason. – Nodey The Node Guy May 18 '11 at 18:27
  • 14
    Mono was chosen in house for this same reason. We needed to build a client in multiple platforms and all of the coders new c#. In theory, it was a great idea. In practice however, it has turned into a bit of a nightmare. We found many places where code that worked in a native .NET platform wouldn't work in a MacOS platform, so we had to make an exception; then that same code didn't work in LInux. Overall, mono seemed too unstable. In the end, we had to abandon the idea and go back to writing native code for the targeted OS. – Chu Jul 26 '11 at 21:34
  • given those reasons, you might as well use Appcelerator, PhoneGap or Webian (etc) instead of Monodroid. Sure, you have to write to a lowest-common-denominator to fully reuse your code across all supported platforms, but I think you'll find you end up having to do that anyway. – gbjbaanb Jul 27 '11 at 13:17
  • @Chu, I can sympathize, especially if you ran into your troubles after the Attachmate/Novell purchase but before the Attachmate/Xamarin agreement. That said, I still think in many cases code reuse will justify the hassles of Mono. – Kevin Jul 27 '11 at 15:26
  • @gbjbaanb, those are all suitable alternatives (although you do trade some platforms, C# gets you Xbox and Windows Phone while PhoneGap will get you BlackBerry and Symbian). I guess I'd say that the Mono products fill that same niche for people who prefer C# or, like me, have lots of existing C# code they'd like to reuse. – Kevin Jul 27 '11 at 15:30
  • 4
    Still, the only code that is re-usable is the business logic, **not** the UI code or code that interacts with the phone hardware. See [I have a MonoTouch or WindowsPhone 7 application, can I just rebuild it with Mono for Android and target Android?](http://support.xamarin.com/customer/portal/articles/142097-i-have-a-monotouch-or-windowsphone-7-application-can-i-just-rebuild-it-with-mono-for-android-and-target-android-) on the MonoDroid FAQ. – Jason S Oct 28 '11 at 03:47
  • @JasonS, some of the phone hardware code can be reusable once the new Xamarin.Mobile library is ready, but on the whole you're right that it's only the business logic that's reusable. I did mention "reuse most of your application logic" but perhaps I should have emphasized that more. – Kevin Nov 28 '11 at 18:28
  • You can edit your answer to clarify. The whole tone and wording of your post and comments makes me wonder if you have any commercial interests related to Mono, since it reads like a sales pitch, not the type of objective advice I come here for. It sounded all to good to be true so I had to search for the details which I posted as a comment. It seems other readers, like @Luciano think from your post that Mono is for mobile what Java is for desktops, when UI and phone control code is not portable in Mono. I would say that makes up "most" of the code in "most" mobile apps. – Jason S Dec 02 '11 at 01:32
  • 2
    @JasonS, I've updated my answer to address your comment. For the record, my only involvement with Xamarin and Mono is as a satisfied user. – Kevin Dec 02 '11 at 18:47
  • 1
    @Iceman Hey thanks for the disclosure. Sorry if I cast any doubt over your integrity. My apologies. Thanks for clarifying your post and recommending my post. It is good to know the points of difference that can help someone decide if it is worth trialling Mono for their situation. Glad it is working for you. Happy programming on Mono! – Jason S Dec 05 '11 at 20:54
18

This is a kind of supplementary answer, since one thing that seems to have been overlooked in answers so far, concerns what is actually cross-platform. According to Xamarin themselves that is basically your business logic, not your UI or any hardware control such as GPS, audio, address book and so on. Those will have to be written specifically for each platform. See their FAQ entry I have a MonoTouch or WindowsPhone 7 application, can I just rebuild it with Mono for Android and target Android?.

Using Mono, you can write your UI and phone control code using C# but it will not be portable to any platform. You will have to write the UI and phone control for each platform, even though you can write it in C#. Either way, you will still have to learn the specifics of UI controls on Android and how Android handles phone resources.

Using Mono, you'll have to learn the Mono API, that calls into the Android API. You'll also have to wait for Mono to implement new Android features and hope they implement all Android features. Even if C# is more powerful than Java, you'll not be able to do more than if you use the Android SDK directly (in Java).

If you're going straight from C# to Android, since C# is so syntactically similar to Java, then most of a C# developer's learning for Android will be learning the Android API.

Some considerations...

C# to Android

Need to Learn

  • Android API
  • Java API : String, Calendar and event handling etc.

Don't need to learn

  • Java syntax : C# is very similar syntax.

Other considerations

  • You won't be able to reuse code across platforms.
  • You won't have any dependencies between you and the Android SDK. You will get new Android features as they are released.
  • You will likely have greater support and examples for Android code than Mono.

C# to Mono

Need to Learn

  • Android : You still need to learn Android's UI and hardware control features.
  • Mono API : You have to learn how to call Mono's API to do stuff with Android's UI and hardware.

Don't need to learn

  • Java API and syntax : You can develop in C#

Other considerations

  • Reuse code : You can re-use C# code that is devoid of any UI or hardware control code and so is pure "business logic". Although ideal, having such a clean separation is not always easy. You will have to evaluate how much of your code will not have any UI or hardware control.
  • Dependencies : You are dependent on Mono implementing the Android API. There may be some lag from Android API releases or some Android features may never be implemented.
  • You may have less documentation and examples to choose from.
Jason S
  • 289
  • 2
  • 5
  • You've forgotten to mention P/Invoke. [A sample.](http://stackoverflow.com/questions/15707278/mono-for-android-and-mupdf-pinvoke) – Amir Karimi Mar 30 '13 at 20:48
  • -1: What do you mean `Learn the Mono API`? How much do you actually need to know to develop an Android app? And have you actually tried MonoDroid or are you guessing? – Jim G. Jul 22 '13 at 23:36
  • @JimG. By `Learn the Mono API`, I mean that you still need to learn the Android API that Mono replicates, in addition to the parts it doesn't. How much do you need to know? Depends on the app, depends on the person - that wasn't really the gist of the OP. Have I used MonoDroid? No. I have C#, Java and Objective C experience, so no need. I did consider Mono for portability. At the time I answered no-one had mentioned the limits on portability. I don't mind people disagreeing with me, but that in itself doesn't make my answer poor. – Jason S Jul 23 '13 at 10:00
13

I think a lot of it has to do with the resources that are available.

The syntax in C# and Java may be similar, but they offer very different things. For example, working with dates using standard Java libraries is a nightmare, while in C# it's quite pleasant.

Corey
  • 1,812
  • 1
  • 15
  • 18
  • 2
    Interesting—so the appeal is more about getting access to the .NET libraries. Do you happen to know if .NET offers a lot of convenient functionality, relevant to Android, that's more difficult to achieve with the Java Android APIs? – Dan Tao Jan 01 '11 at 19:17
  • 19
    +1 - Coming from C#, I find java to be... idiosyncratic at best... – Oded Jan 01 '11 at 19:18
  • 4
    I find that the similarities between C# and Java are not an advantage when switching between them. I can switch between C# and Python, Ruby or Lua without a blink, but the last time that I tried to do some Java coding, I ended up grinding my teeth and spinning my wheels. – Adam Crossland Jan 01 '11 at 19:59
  • 1
    @Dan Tao: the appeal isn't *more* about access to standard .Net. It's about both that and re-use. The benefit of re-use should be obvious. As for access to .Net, I look at it this way. I've used, say, XDocument 1000 and 1 times. If I need to write a mobile app that integrates XML data from a service I write it at the speed of thought. If I'm *learning* Java, I could easily take 4 to 8 times as long (or 10 or 12, who knows) bouncing back and forth between coding and reading docs. If the use is for business it is irresponsible to do a project while learning a language. – quentin-starin May 19 '11 at 06:44
9

It looks like a great opportunity for learning a new language, which I don't think you should pass up.

Going from C# to Java is a breeze as they are based on the same concepts. Java is like a subset of C#, so you'll have to unlearn some stuff (like properties and assemblies) and getting used to a some new conventions, but mostly it should be a no-brainer.

Martin Wickman
  • 13,305
  • 3
  • 31
  • 66
  • 10
    And figure out the differences between how generics work in each, and wonder why properties don't exist, and events and... – Oded Jan 01 '11 at 19:48
  • 5
    Minor differences. It's not like he has to learn Haskell. – Martin Wickman Jan 01 '11 at 20:03
  • 1
    +1 No harm in knowing a few different languages and having a real world project to work on is a great way of getting the hang of one if it's a similar kind of language to the ones you already know. – glenatron Jan 01 '11 at 20:33
  • Better make sure the person paying is ok paying for a learning experience. – quentin-starin May 19 '11 at 06:49
  • @qes Cost is always an issue so that goes without saying. But there are many benefits with learning more than one language for programmers. "If the only tool you have is a hammer, you will see every problem as a nail." – Martin Wickman May 19 '11 at 10:55
  • 1
    @qes - Learning something that is redundant is not enough of a reason to justify cost in most cases, but development of a complex app in its native environment is going to go more smoothly most of the time, and that could make the learning have more long term cost reductions. – Morgan Herlocker Jul 27 '11 at 12:58
  • @ironcode - I'd suggest you're underestimating the efficiency of C# vs. Objective-C, especially for a programmer experienced in C# and not in Objective-C, and not considering code reuse and cross-platform ability. Given the quality of MonoTouch, I still say the advantages dwarf any hiccups that might occur from not developing in the native environment. The design and breadth of Monotouch restricts the un-smooth parts to mostly deployment, ime. – quentin-starin Jul 27 '11 at 14:51
  • @qes The question is about MonoDroid, not MonoTouch. Java is arguably closer to C# than Objective C, certainly in syntax. ironcode's point is more about 'native' development vs development through an intermediate layer, than about platform battles (or which platform is more efficient and for whom). It is a valid point to consider. – Jason S Oct 28 '11 at 02:40
  • @MartinWickman Java and C# are both hammers I don't think the quote really applies here. If I know C# why would I learn the idiosyncrasies of Java? They both hammer the same kind of nail. If it was a question between Haskell or C# I might agree with the point you're trying to make. – Mike Cellini Dec 02 '11 at 19:58
3

Quick history lesson -- MonoDroid grew up out of MonoTouch. Made alot of sense at the time. Unfortunately, Novell got sold and the whole Mono team was laid off. Good news is that Miguel de Icaza secured funding and has started a new outfit to rebuild what was MonoTouch/MonoDroid. So you are kind of in limbo until they really launch.

July 2011 Update: Miguel's outfit has regained rights to the whole Mono* stack. Get it while it's hawt.

Wyatt Barnett
  • 20,685
  • 50
  • 69