The Wonderful World of Xamarin.Forms

Vito Vargas
Feb 3, 2019 · 5 min read

In my last post, I wrote about how Xamarin continues to be a relevant option when choosing a cross-platform mobile framework, especially if you are already familiar with the Microsoft .Net development stack. Ever since it was acquired by Microsoft back in 2016, Xamarin has become a well maintained and continuously evolving framework with input from the open-source community and backing by one of the biggest names in technology today. One of the solutions that have come out of this evolution is the Xamarin.Forms library which gives .Net developers a complete cross-platform UI toolkit to build the UI layer of their Android and iOS apps using a single C# code base. Today, I want to expand on these benefits and explain why it is an integral part of the Xamarin ecosystem.

More Code Sharing

Image for post
Image for post

These libraries, however, cannot be used on their own to do all the platform specific coding needed to create the UI layer of your app. With this approach, you have to develop each platform’s UI using the specific Android and iOS API’s. It may still be in C#, but it is more code duplication than one would expect from a modern cross-platform framework. This approach does give you the flexibility to develop the UI to meet each platform’s specific design guidelines, but often the overall layouts and interactions are the same. Wouldn’t it be nice if you could use a markup language and style sheets to create responsive UI’s and then used data-binding to handle interactions and UI updates? Well, Xamarin.Forms gives you exactly that and the ability to do much more with a little bit of extra effort. With Xamarin.Forms, you can share the entire UI layer while still maintaining the ability to write custom code for each platform.

Image for post
Image for post

If you are familiar with either Windows Presentation Foundation or Silverlight development then Xamarin.Forms will seem very familiar. Xamarin.Forms gives you more code sharing at the UI layer by allowing the developer to use XAML to define the view layout and the UI elements. With XAML, you can also declare styles explicitly, implicitly, or globally. All of this is backed by a C# code-behind to handle behaviors and interactions with the different UI elements and change their styles dynamically if needed. This code is shared across your platform projects allowing for much more code sharing.

Easier To Start With

With the traditional Xamarin approach, when you wanted to start working on your UI, you had to use the platform-specific tools. This approach meant you could only preview your changes using those same platform-specific tools which required you to run OSX and Xcode for iOS. Android has much more support in a Windows/Visual Studio environment, but unless you are only developing for Android, you have a bit more work cut out for you. The XAML approach in Xamarin.Forms not only unifies the language and developer tools needed to create and modify your UI’s but also has preview functionality built into Visual Studio for both Android and iOS (given you have a Mac paired or are using Visual Studio for Mac to preview iOS).

Image for post
Image for post

Xamarin.Forms saves you from having to build out to each device, emulator, or simulator to check every change you make. You should still do that once you are ready to release, but it can help you get to that point quicker. Preview tools and emulators are generally pretty good at rendering to device specifications, but there are many times I have noticed where one platform or the other comes out not proportioned to what I expected, so it is always a good idea to test on real devices at some point.

Another reason it can be easier to start with Xamarin.Forms than Xamarin standard is the documentation and examples are so much more readily available for Xamarin.Forms projects. The Xamarin team makes it very apparent that developers should start with Xamarin.Forms. It is becoming the standard way to build Xamarin apps so you can rest at ease knowing it will continue to be maintained. On the official Xamarin Documentation site, it even defaults to starting you off with Xamarin.Forms. You will only be making things harder for yourself by choosing not to use it, but it is still an option.

Individual Platform Control

Now, this completely goes against the narrative of code sharing I was describing earlier, but I think it is essential to have this sort of flexibility since the mobile app sphere can be very competitive. Perfect examples of this are the watchOS and Android Wear devices. If you want to stay competitive in a saturated app market, you have to take advantage of the latest features and fixes released to these smart wearables. They are implemented quite differently, but both are supported in Xamarin.iOS and Xamarin.Android respectively. So you can build your Xamarin.Forms app and then extend your app’s functionality with watchOS or Android Wear features. All still in C# and with a majority of your code shared cross-platform.

Image for post
Image for post

And So Much More

Archetypical Software

Open source framework components for a better development…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store