Phone break and monotone for data intensive application

We are committed to developing an application that uses data intensively for mobile devices. Our central problem is

  • We will need to store quite a lot of data on the client
  • The client wants the application to work offline
  • Our skill set is a lot of C # ASP.Net web development. Definitely not Goal C

We thought about the three possibilities dev

  • Web application using local HTML5 storage using offline application cache. We are at the limit of 5 MB for local storage, but it can be up to 2.5 MB for some browsers.

  • Web application via PhoneGap to create your own application. The big advantage here is that we can use the file system for storage. The downside is that he will have to go through the App Store (especially for iOS) - a 30% patch for the Apple subscription application.

  • We are creating an application using MonoTouch for Android and iOS. Good - C # and .Net we can do this. Bad - No Blackberry

Question

I try my best to see any real benefits of using MonoTouch on top of PhoneGap in this case. Who are they? Are there any

As an example, in this case it would be really useful to save the data in the file system, but I believe that a break in the phone can do this through the File object . Obviously monoTouch will use System.IO.

Are there any cases when MonoTouch has certain additional functions - especially functions that are useful for mobile devs, for example. Geolocation features or camera type ?. Or phone calls pretty much cover it all.

Cheeky Additional Questions

Are there any other options that I missed, or any other main advantages / disadvantages for the three approaches that I have outlined that I forgot about?

Thanks for every experience.

+45
c # html5 mobile cordova
Feb 08 2018-12-12T00:
source share
3 answers

We just finished a very intensive application written in MonoTouch. The application accesses SAP data through the middle tier and provides this in the application. It also allows you to receive direct updates from an application in SAP again through the same middle tier.

We port this to Windows Phone and Android using MonoDroid.

It took me a while to convince the boss that MonoTouch is the way forward, and we pre-tried several different products, including jQuery mobile, ExtJS and Obj C.

The time I tried to convince him was the time to acquire Attachmate, and it looked, at times, how MonoTouch was doomed. Fortunately for us (me), Khamarin rose as the notorious Phoenix from the flame, and they continued to develop Mono * to what he is today.

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

The IRC channel is very active, and Xamarin staff and community evangelists are always ready to help or give an idea of โ€‹โ€‹the problem. Like the mailing lists.

Another plus is the eco-systems that grow around MT. MT.Dialog makes the development of the UI table interface an absolute breeze compared to the Xcode equivalent. Coupled with this .Net BCL, which is admittedly a subset based on Silverlight, but it has everything from Serialization, Email to cryptography, etc. If .Net does not cover it, or if there is no specific Mono * project, you can still use ObjC plugins with your MT code.

I do not agree that MT "until it proves itself" as a proven platform. We use it, and although we are a relatively small company, there are many large companies that also use it. Some of the applications Apple presented in television ads here on Aus are reportedly written in MT.

To stay objective, the 2 minuses of MonoTouch for me were that you still need to read ObjC (although, tbh, I see nothing in common ... As a 'C #' developer, I should be able to read and write many languages โ€‹โ€‹anyway) and the fact that MonoDevelop has historically been a bit of a mistake.The main mistakes seem to have been crushed, and with his open source project you can always fix them and help the rest of us!

To answer your questions:

  • We will need to store quite a lot of data on the client

Use the System.IO.Net classes in C #. If you are not sure about this, there are examples of examples in MSDN (MT hides the implementation of the iOS file storage)

  • The client wants the application to work offline

they can do all this, but in my opinion, the Native app will always be better.

  • Our skill set is a lot of C # ASP.Net web development. Definitely not Goal C

MonoTouch is C # - play your strengths and you have the app in a few weeks, not months!

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

+40
Feb 08 2018-12-12T00:
source share

I used PhoneGap for a while (on WP7) but did not use MonoTouch, however I am an experienced C # / Silverlight developer.

Several advantages of MonoTouch:

  • As a result of the code, a custom user interface is created that provides the best experience on all platforms.
  • C # is the "entrepreneurial power" programming language. It is well suited for developing data intensive applications.
  • Your current skill sets will serve you here.
  • Numerous apps written with MonoTouch are available through the app store.

A few disadvantages of MonoTouch:

  • You write the iPhone C # API code again, so for the Android port you will need a separate layer of user interface for MonoDroid.

PhoneGap Benefits:

  • It begins to look like a completely mature structure, numerous applications written using PhoneGap , in the entire range of supported OS.
  • There is good support for the PhoneGap community
  • It uses HTML5, which many consider the technology of the future. This is a fairly broad expression, but most major players (Microsoft, Adobe, ...) support it.

Disadvantages PhoneGap:

  • It uses JavaScript, perhaps the most misunderstood language in wide use !
  • The user interface is written in HTML format. Despite the best efforts of structures like jQuery Mobile , it will never seem native.
  • Since it has a platform-specific โ€œshimโ€ code to provide a consistent API, you will find platform-related problems. However, I found that the PhoneGap team fixes them pretty quickly.

In conclusion, a tough choice!

Personally, I would go to PhoneGap, but Iโ€™m not trying to imitate the appearance of any particular OS, and not create my own user interface that works well for your application and uses it on all platforms.

+14
Feb 08 2018-12-12T00:
source share

There appeared a new MonoTouch release, which was released yesterday (February 8, 2012) - 5.2. Many new features that simplify and speed up the development of applications for iOS. Details on this can be obtained here: http://blog.xamarin.com/

One thing that makes MonoTouch a particularly interesting technology is the ability to develop complex, rough, complex applications that can work without the need for an Internet connection. It can be big.

+2
Feb 09 '12 at 15:56
source share



All Articles