Xamarin. Pros and cons

Probably every .NET developer, getting acquainted with monodroid and monotouch, wants to know what awaits him. Is it worth spending your time and energy on exploring the potential of the platform, will the development turn into testing the framework?

For more than a year, my main task has been developing in C # for Android and IOS, and I will try to answer the main questions that arise when choosing monotouch and monodroid. The article will have a lot of personal opinions and descriptions of crutches, since the answers on technical issues can be easily found on the official website Xamarin: docs.xamarin.com
')
Since Xamarin 3 was released only recently, I was not able to fully explore the new features and changes in the platform. However, almost all the “features” of development in monotouch and monodroid are still relevant.

Development

Interaction with the Android and IOS platform is implemented by means of Mono.Android and monotouch proxy libraries. Also, multiplatform is transparently implemented in System.IO, System.Net, System.Data, etc.

IOS developers have access to Xcode features for generating views. When developing for Android, you can use the features of Xamarin Studio and add-on to Visual Studio to generate Xml markup.

Due to the similarity of Java and C #, the use of standard patterns and language features does not lead to any difficulties. Development under IOS is not more difficult - ObjectiveC features are elegantly covered in the C # language, despite external differences.

It all works as beautiful as it sounds. However, there are a few comments:

• Almost all native classes implement the IDisposable interface. And this is not a simple formality: memory leaks are quite real.
• In monotouch, you may be surprised by the absence of such objects as GSize, CGRect, and so on. They are replaced by the corresponding structures and classes from the System.Drawing namespace.
• Of course, exceptions that occur inside the platform are thrown as MonoTouch.Foundation.MonoTouchException and Java.Lang.Throwable, but not always. The situation is quite real when an exception is raised in the code of the framework. Moreover: a stack overflow error often simply crashes the application, without raising any exceptions.
• Some API elements simply do not work. For example, AnimationStart, AnimationEnd events in ViewFlipper (Android). Monotouch also has an interesting feature: some methods have been renamed in accordance with the rules. NET. For example, the UIApplication method. didFinishLaunchingWithOptions has become a UIApplication. FinishedLaunching. You can live with all this, but StackOverflow programming is no longer rolling.
• Many elements in monodroid and monotouch are represented as proxies to native objects. And their life cycle is weakly connected with each other. Therefore, you should always remember about Dispose, otherwise memory leaks are possible.
• The debugger is quite slow and not always stable. However, developers are constantly improving it.

Support

In one of the comments I saw a complaint that there are very few monotouch posts on StackOverflow and even fewer monodroid posts. Frankly, it is. And there is nothing bad in it, because most of the questions on the API can be easily found in the topics on a specific platform and then translated into C #. In truth, you should at least read about ObjectiveC, since many features of the syntax may not be understandable "with a hitch." In this case, it is the monotouch community that shows serious activity. When developing for Android, you will often be left to yourself.

If you have a Business Edition license, you will receive “access to the body” of official technical support. It is quick and objective. Unfortunately, they could not help with any of my appeals.
Kinu a couple of stones in the direction of updates Xamarin: they are always full of surprises. For example, after the transition of the platform standard from Silverlight to pure .NET, the project simply stopped compiling. The development environment bugs introduced by patches are also common. There is only one advice: to coordinate updates in the team and not to update before the release of your application.

Conclusion

Is it worth it? There is no definite answer. Further, there will be exclusively my personal opinion, which does not pretend to be complete and objective.

You should try Xamarin if:

• Your application must contain a large amount of multiplatform code. Solving the problem of duplication of logic is often more important than the potential problems of working with monotouch and monodroid.
• You need to develop in a short time the application for several platforms. Again, reuse of code in various platforms speeds up development significantly. Nevertheless, it is worth remembering that dozens of man-hours can eat to solve many problems.
• You need to develop a small prototype application under iOS, but you don’t know ObjectiveC or Swift. When developing a prototype, the bill goes to the watch, which should not be spent on learning a new language.
• Are you a startup or indie developer. In this case, you can not implement problematic features, and multiplatform saves valuable time.

You should not use Xamarin if:

• You are developing a non-multi-platform application. No time saving on learning a new language is worth any potential problems.
• You are developing a GUI oriented application. Some interface patterns are hard to implement on monodroid and very hard on monotouch, since the default solutions for a particular feature rely on platform crutches, which may simply not work in Xamarin.
• Your application must meet specific stability requirements. Indeed, there are often problems with the mono, monotouch and monodroid platform. I would not advise taking risks.

Well, the answer to the classic question: if it were possible to go back and choose something else for our project, I would still choose Xamarin.