Codemash and Xamarin.Forms

Codemash is one of the largest tech conferences in North America and an event that I had always wanted to speak at. I was finally successful as they accepted my Intro to Xamarin.Forms talk which I got to give on Thursday (1/12). It went very well and generated a lot of interest. I thought it would be good to summarize the finer points here:

The mobile market has a lot of interesting situations that make it different from past platform races, such as the browser wars or the OS wars. The reason is that, while Android hold an 80% (or higher depending on who you ask) marketshare, iOS controls roughly 60% of the profits. So its a situation where there is not one clear favorite and you end up needing to support both.

Xamarin is good for this because its code sharing model means its easy to share business logic between the two platforms in a unified language. This is actually something many in the community are working on but, in my view, Xamarin has the best option at the present time. However, Xamarin is not a silver bullet and does suffer from many issues:

  • Because the bindings are written using Mono and Mono is sitting on top of iOS/Dalvik we have to recognize that we have duplicate memory management systems at work. To be clear, objects are not duplicated, but rather the disposal of the objects held in iOS (using ARC – Automatic Reference Counting) is initiated by the Generational Garbage Collector in Mono. Synchronization is therefore key and developers need to be aware of this so as to avoid strong reference cycles.
  • While Xamarin does offer the ability to bind Objective-C (no Swift yet) and Java libraries into Xamarin so they can be used, this is an extra step. And, we have seen that such bindings can be cumbersome and difficult to maintain. That being said, when using Xamarin developers get access to the wealth of packages available via NuGet. And with Microsoft progressively moving towards the idea of a standard for .NET we will likely see more projects become cross platform compliant in the future.
  • In any application the UI always seems to take the most work, it was true with Desktop apps, it is true with web apps and it is especially true with mobile apps. Even if you use Xamarin, you still have to create unique UIs for each platform.

With respect to the last bullet, this is the reason Xamarin created the Forms framework. It enables us to write a single UI Definition and then the framework renders this definition appropriately giving us a nice native look. This is where it differs from tools such as Cony  and Cordova/PhoneGap which employ a one UI for all. Effectively using Forms enables the creation of multiple UIs at the same time.

It is important to understand that Forms is not intended to replace general development for mobile and should generally be used for apps that can be generalized: POCs, Enterprise data apps, Data Entry apps for example. If your app will require a lot of UI customization it might be better to adopt traditional Xamarin instead of Forms. My rule of thumb tends to be:

If you are spending most of your time in traditional Xamarin, you should be using traditional Xamarin

What this means is, we often utilize things like Custom Renderers to take over the UI customizations with Forms. These renderers are often written within out platform specific projects because they are invoked when the parser wants to know to render a control on the current platform. If you find yourself in these a lot, I advise that you weigh whether you are getting true benefit from Forms.

At the end of the day, Forms is a tool and it is incumbent on us as developers to determine the appropriate utility of that tool. But, we are seeing people using the tool in interesting ways, one of the most impressive of which is the Hybrid App.

Because Forms enables us to quickly create a page for all platforms supported some have started to use it for only certain pages in their application, such as a settings screen. Usually for screens that maybe complicated due to the volume on the page, but not necessarily feature any customized UI that developing separate interfaces for each platform would yield a positive gain.

I plan to give the full talk again at the .NET Mobile User Group in Chicago in the near future. If you are interested please dont hesitate to ask me about it or Forms in general.


5 thoughts on “Codemash and Xamarin.Forms

  1. Great post and I’m sure it was a great talk. I’m wondering where I can read more on your first point:
    “Because the bindings are written using Mono and Mono is sitting on top of iOS/Dalvik we have to recognize that we have duplicate memory management systems at work”

    I’ve been using Xamarin.Forms to write a fairly complicated app, and I want to get to know how Xamarin works.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s