24

Today it is possible to use C# programming for multiple mobile platforms such as:

(feel free to edit if I missed some) Of course, it is still programming effort for UI, but main libraries of app can be shared.

We can all thank to a team gathered around Mono project and superhero Miguel de Icaza whose effort is priceless.

What bothers me is, what are the benefits of these options? Is it cost of maintaining one app across multiple mobile platforms less impediment then having to code each library separately for better performance. Learning curve of each language? Being Jack of All trades vs .NET Ninja

Or knowing that binaries of app programmed in native environment are less in size, maybe even optimized better and not to forget that you have to wait support of new platform os updates.

UPDATE: Obviously there is one more thing to consider and that is support. Since Novell is bought by Attachmate Group, all Mono team is laid off. However the core member of the team lead by Miguel De Icaza founded new company Xamarin which will reinvent Mono Mobile development tools from the scratch.

nemke
  • 2,440
  • 3
  • 37
  • 57

8 Answers8

19

In my opinion, the big pro of using one single environment (i.e. C#/.NET) is code portability. And cool things like LINQ that, once you get used to it, you can't live without. However, the few mobile OS's (iOS, Android, WP7) are quite different with regards to UI.

And, if I am not mistaken about your application, it's got a fair share of UI interactions if it is to run on a mobile device. Most mobile apps are like 80% UI code.

Therefore, you'll end up writing a separate set of UI code for each platform anyway -- for example, you'll be writing in Silverlight WP7 (and all the WPF goodness), you'll be writing a completely different set of code for iOS in Cocoa (IB, Views, controllers and stuff), you'll be writing yet a completely different set of code for Android.

My experience has always been that it take a lot of experience to write good UI code on any platform -- e.g. learning WPF/SL is already the nightmare that is, throw in Cocoa Touch and the whole Android mess. Of course you can write three sets of UI that look and feel reasonably similar, but chances are that you'll be trying so hard to reuse code and have common data structures that your UI's will end up sub-par when compared to dedicated apps -- and in this cut-throat world of mobile apps today, a non-super (not to mention sub-par) UI experience means death to your app.

Also, all three mobile environments have different connectivity paradigms, as well as multimedia paradigms. You end up writing three versions, and learning three environments, albeit writing in one language you're familiar with.

The most you're going to reuse is back-end modules. Decision engines, search routines, data-management etc. And even these are going to be problematic because you'll be force to have compromises in your data structures just to enable easy integration with three different sets of UI code working on three different UI paradigms. For example, do you use DependencyObjects for use to bind to Silverlight views in an MVVM model? If you do, it won't work with Cocoa's MVC model, and you have to code those bindings separately.

And since not all mobile environments enable you to use the full set of functionalities -- for example, MonoTouch for iOS does not generic constructs that cannot be determined at compile time. You're essentially using a very small subset of .NET (and must constant be reminding yourself what functionality can be used where) just so that you can run them all on three different platforms without significant changes.

Now image having all these limitations when you are writing for the WP7 platform, which supports the entire .NET features set. I don't know about you, but I'll go crazy. And your WP7 app is never going to be even close to being competitive with other apps out there.

In my opinion, the pain and the compromises are not worth it. You'll end up with three so-so apps, which people in neither of the platforms are going to like.

Unless all the goodness lies in your app's back-end logic, and it is so good that people are going to ignore UI issues just to get to your app's back-end functionalities. In my experience, this almost never happens.

Geoff Norton
  • 5,056
  • 1
  • 19
  • 17
Stephen Chung
  • 14,497
  • 1
  • 35
  • 48
  • 2
    +1 for a good answer. However, while it may be difficult to get a good UI on all 3 platforms with only one language, a developer doesn't have unlimited time to spend on perfecting a program written separately in 2-3 different languages. Especially if the internal or "business" logic is a major feature of the program, it may not be worth the effort to rewrite it over and over. – Qwertie Mar 23 '11 at 20:04
  • One could consider porting UpdateControls to Android and iPhone. (http://updatecontrols.net) This library changes the way you write your "ViewModel" (the central part of MVVM) so that it is not tied to a particular GUI. UpdateControls currently supports WinForms and WPF; with some work (maybe lots of work!) I expect it could support other GUIs. UpdateControls also tends to reduce the total amount of code you write. – Qwertie Mar 23 '11 at 20:12
  • Good points, @Qwertie. However, I am still of the opinion that a highly-polished UI experience is critical for today's mobile apps just to get noticed (unless the internal business logic is very very good). It is really not worth saving some time on porting core logic code to another language by sacraficing UI goodness. In my experience, a poor program with a pretty UI still gets used more than a great program with poor UI... unfortunately... – Stephen Chung Mar 24 '11 at 02:00
  • Great answer, depending on the backends complexity though it might be worth building it in monotouch as a library completely separate from UI. Then create native UI projects for each platform using the library. I am assuming that is possible with Monotouch since it pre-compiles the .NET code to native. In the end I think it's a judgement call on how complex your app is going to get. – PeteT Mar 25 '11 at 04:05
  • 2
    I've edited your answer to remove gross misinformation, MonoTouch certainly does support reflection. You have a large amount of other misinformation (ie; small subset of .net, we support the portable library project, and more than WP7 does) with respect to MonoTouch. The only constraints compared to WP7 are around jitting, which is a platform restriction from apple. – Geoff Norton Mar 27 '11 at 01:25
  • @Geoff Norton, does it support reflection? I thought it doesn't -- guess I was wrong. I see it now in the FAQ -- it doesn't support Reflection.Emit, but does support Reflection. My mistake. Also, from the FAQ it does support only a limited subset of .NET, but it probably contains most of the core assemblies that are relevant to the iPhone anyway... – Stephen Chung Mar 27 '11 at 04:16
  • 3
    @Geoff, would you like to write up an answer regarding Mono-Touch? That would be greatly beneficial to people reading this :-) Of course the opinions in my answer are just that -- my own personal opinions -- and I stick with my opinions, but would love to be proven wrong though... – Stephen Chung Mar 27 '11 at 04:18
  • There's a perspective that is seldom discussed when talking about mobile app development, the perspective of developing enterprise applications to be deployed within companies, and not destined for the huddled masses. User interface, while still important, takes a back seat to functionality, time to market and ROI. Enterprise application developers can make great use of cross platform tools like Mono, MonoTouch, etc. – Larry Silverman Dec 02 '11 at 16:04
2

Since the accepted answer had been written in 2011, a couple of different frameworks have emerged, which bring MVC and MVVM patterns to Mono for Android and MonoTouch, which helps quite a lot when developing applications for these targets.

For MVC check out the project called MonoCross

For MVVM check out Stuart Lodge's MvvmCross

The latter contains a lot of code for opening images on the three platforms, composing e-mails, opening webbrowsers, playing sounds and much more. It aslo handles navigation between ViewModels.

Community
  • 1
  • 1
Cheesebaron
  • 24,131
  • 15
  • 66
  • 118
2

The biggest advantage for me is the ability use reuse the business logic and communications code between mobile platforms. Yes, I have to write the UI over and over again, and it takes time to get your head around that, but at least my base platform is reusable.

In my experience when moving to a new platform, it takes me a lot longer to learn the UI framework than to learn a new language.

vlad259
  • 1,236
  • 10
  • 24
  • UI is the name of the game apparently. I totally agree, especially since I'm not much of a designer and I would wager to guess that would be the case for a great many programmers. – Terrance Apr 28 '11 at 19:42
  • Is this still an approach you find viable? I want to have portable biz logic, comms and data storage, then re-write the UI on each platform to make it sweet. – tobinharris Sep 24 '13 at 18:35
  • Yes, it's still working for us. We have apps in the Apple and Android stores that have used this approach, and have another one coming out for iPad. All three use the same comms, business logic and models. – vlad259 Sep 25 '13 at 10:58
0

Cross-platform solution only works if your application is simple and straightforward. If you require complex features such as local data store with complex object graphs, go native or expect to spend months to debug problems

ｊｉｎ
  • 114
  • 2
  • 12
  • I disagree with that. Using the Sqlite.Net Nuget package and a PCL for shared code, local data storage seems pretty straightforward. I think that the time that you will spend writing and maintaining multiple large, complex applications will be far greater than the time to get it to work cross-platform. I don't think it would take *months* to debug problems. – valdetero Mar 07 '14 at 15:46
  • Local storage aside. Native apps will always run faster and produce fewer bugs. Like I said, unless your app is simple, always write in code native to the platform you are targeting. Facebook tried that cross-platform idea with their html5 app, they failed and had to rewrite everything from scratch using native code. Cross-platform coding will only work if your app is simply you don't care about performance. – ｊｉｎ Mar 10 '14 at 21:48
  • Facebook tried a html5 web app which did have severe performance problems. This is however not a hybrid web app. You cannot simply lump all cross-platform solutions together when they have drastically different implementations. Apps written with Mono *can* be just as performant as their 100% native counter-part. Have you actually used any cross-platform tools? Have you even tried the Mono tools that the OP is talking about? – valdetero Mar 10 '14 at 22:21
0

a big advantage is certainly the reusability of code / class libraries across the platforms. With that in mind you`re able to port/develop applications even faster, which in turn reduces the costs.

Also, because of the reusability of code, it will reduce maintenance expenses.

cordellcp3
  • 3,557
  • 1
  • 17
  • 14
  • But do you know how big is deployment of .net binaries for android or iphone, not so small. – nemke Mar 17 '11 at 07:00
  • 1
    What do you mean with "how big" the deployment is? If your using MonoDroid within VS2010 you can easily deploy your app to a physical device or emulator with just two clicks. Maybe this article http://visualstudiomagazine.com/Articles/2011/02/01/Introducing-MonoDroid.aspx?Page=1 helps. – cordellcp3 Mar 17 '11 at 07:12
  • For example native app could be big 200kb .vs mono 20mb. Same app,same features different framework – nemke Mar 17 '11 at 07:23
  • 1
    @nemke Application size depends upon the number of features. MonoTouch and Mono for Android apps start at ~5MB and grow from there, but you're not necessarily looking at a 20MB Mono* app unless you're using 20MB worth of features and/or including lots of resources (which would prevent a 200KB native app as well). – jonp Mar 17 '11 at 19:36
0

There are certain drawbacks to the Monotouch/Droid-libraries. There is a little speed setback (about 5%, so neglectable in most of the cases).

In my experience, the size does not differ that much. Much of the size is in the resources (data resources, packed images and alike - not processor usage), and most apps don't carry that much resources with them (because of loading times and the availability of much default controls on mobile platforms).

I don't think you should use the frameworks on games however. I don't have much experience in mobile game development, but the pretty different frameworks you're using in game development (XNA, Android's NDK..) and the need for system resources (processor usage, memory etc.) make them pretty useless imho.

vstrien
  • 2,547
  • 3
  • 27
  • 47
0

Advantages:

  • Code all in same language and (mostly) usable on each platform
  • Reduced development time
  • Cheaper

Disadvantages:

  • Including needed libraries increases minimum application size quite significantly - if you're app is going to be large then the difference is not so significant
  • Performance overhead

If you have the money and the people it's always better to have some people focused on the iPhone and Objective-C, some Android and Java etc. That way your programmers will have an intimate knowledge of the platform you are targeting and will be able to make sure your application takes full advantage of the platform's features -- an app should not be exactly the same (except perhaps games) across all platforms, you need to play to their strengths and weaknesses: an iPhone app should look and function like an iPhone app etc.

That said, if you don't have the people or the money, using a single language together with several frameworks is certainly cheaper and faster, and may give you better results than the result of strained attempt to develop for each platform individually.

Joseph Earl
  • 23,351
  • 11
  • 76
  • 89
0

Another way to look at this is you could port an existing .NET/C# application to a variety of mobile clients (both native and non-native) relatively easy using WebORB integration server. On the client side you would have to code in either the native language or you could create an Adobe AIR application that is fairly portable across different mobile OS' such as iOS, Android and BlackBerry PlayBook.

Kathleen Erickson
  • 46
  • 4