The Wonderful World of Xamarin.Forms

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

The base Xamarin framework gives you the ability to develop your models, service calls and general business logic using the same C# code. That code is shared with your Xamarin.Android or Xamarin.iOS projects.

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.

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

You can learn Xamarin.Forms without having to learn Xamarin.Android or Xamarin.iOS. You would only need to learn those if you wanted to do something that was platform specific. As always, it never hurts to familiarize yourself with the underlying libraries a framework is built on, but it is not required to get started. By far the biggest thing that makes starting with Xamarin.Forms easier than Xamarin standard is developing your UI layer.

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).

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

Xamarin.Forms is built on top of Xamarin.Android and Xamarin.iOS which means you still have access to each platform’s native API’s for more platform-specific code. This allows you to further enhance the end user’s experience on a particular device. Android and iOS have many differences in their native SDK’s to support competing features, device types, screen sizes, and peripherals.

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.

And So Much More

There is quite a bit more I could go on about why Xamarin.Forms should be an integral part of any Xamarin project. There are Custom Renderers, Behaviors, Data-Binding, and many other features that would require a more technical deep dive into each to fully appreciate. Which of course I plan to do! In my next post, I will go into more detail on one of those integral pieces and how it has helped me add some flare to my apps so stay tuned!