phone gap vs monotouch for data intensive app

Crab Bucket picture Crab Bucket · Feb 8, 2012 · Viewed 12.8k times · Source

We are looking to develop a data intensive application for mobile devices. Our central problem is

  1. We will have to store quite a lot of data on the client
  2. The client wants the app to work offline
  3. Our skill set is very much web development C# ASP.Net. Definitely not Objective C

We have thought of three possibilities for dev

  1. Web application using HTML5 local storage leveraging the offline application cache. We are on a 5MB limit for local storage but this might be down to 2.5MB for certain browsers

  2. Web application through PhoneGap to create a native app. Big advantage here is that we can use the file system for storage. The down side is that it will have to go through App Store (for iOS especially) - 30% chuck of revenue for a subscription app to Apple

  3. We build out the app using MonoTouch for Android and iOS. Good - C# and .Net we can do this. Bad - no Blackberry

Question

I'm struggling to see any genuine advantages of using MonoTouch over PhoneGap in this instance. What are they? Are they any?

As an example in this instance it would be really useful to save data onto the file system but I believe that phone gap can do this through the File object. Obviously monoTouch would leverage System.IO.

Is there instances where there is definite additional functionality in MonoTouch - particularly functions that are useful to mobile dev e.g. Geolocation or camera type functions?. Or does phone gap pretty much have all these covered.

Cheeky Additional Questions

Is there any other options I have missed or any other major advantages/disadvantages for the three approaches I have outlined that I have forgotten about?

Thanks for everyone's expertise

Answer

Darbio picture Darbio · Feb 8, 2012

We have just finished a very data intensive app written in MonoTouch. The app accesses SAP data, through a middle tier, and exposes this on the app. It also allows direct updates from the app to SAP, again through the same middle tier.

We are in the process of porting this to Windows Phone and Android using MonoDroid.

It took me a while to convince the boss that MonoTouch was the way forwards, and we tried a few different products beforehand including jQuery mobile, ExtJS and Obj C.

The time I was trying to convince him was the time of the Attachmate acquisition and it looked, at times, like MonoTouch was doomed. Luckily for us (me), Xamarin rose like the proverbial Phoenix from the flames, and they have continued to develop Mono* to what it is today.

As a C# developer (and Mono enthusiast) the main win over Obj C or any of the HTML/JavaScript was the fact that I could use C# to get the job done. The documentation was very good, and when the doco didn't quite cut it (recently been updated) the community did.

The IRC channel is very active, with Xamarin employees and community evangelists always willing to help or provide insight into a problem. As are the mailing lists.

Another plus are the Eco-systems which are growing around MT. MT.Dialog makes developing Table based UI's an absolute breeze compared to the XCode equivalent. Couple with this the .Net BCL which is, admittedly a subset based on Silverlight, but it has everything from Serialization, Email to Cryptography etc... If .Net doesn't cover it, or there isn't a specific Mono* project, you can still use ObjC plugins with your MT code.

I disagree that MT has 'yet to prove itself' as a proven platform. We are using it, and whilst we are a relatively small company, there are lots of larger companies also using it. A few of the apps showcased by Apple in the TV ads here in Aus are, reportedly, written in MT.

In order to remain objective, the 2 'cons' of MonoTouch for me have been that you still need to be able to read ObjC (though, tbh, I don't see this as a con... As a 'C#' developer I have to be able to read and write a plethora of languages anyway) and the fact that, historically, MonoDevelop has been a bit buggy. The major bugs appear to have been squashed and, with it being an open source project, you can always fix them and help the rest of us!

To answer your concerns:

  1. We will have to store quite a lot of data on the client

Use the System.IO classes of .Net in C#. If you are unsure of these, MSDN has oodles of examples (MT hides the iOS implementation of file storage)

  1. The client wants the app to work offline

they can all do this, but a Native app is always going to feel better in my opinion.

  1. Our skill set is very much web development C# ASP.Net. Definitely not Objective C

MonoTouch is C# - play to your strengths and have an app in weeks, not months!

My 2 pennies! I would not hesitate to choose the same route again, again and again.