Introducing Xamarin Forms

Today I will introduce the basics of Xamarin.Forms as an alternative to creating user interfaces for mobile devices using C# language and the .NET Framework.

The Xamarin.Forms launched in 2014, and it's a platform that runs on Xamarin and was originally created as a kit of UI tools that allows developers to easily create user interfaces that can be shared across Android, iOS and Windows Phone.

Xamarin.Forms was written in the C# language, and allows for quick prototyping of applications that can evolve over time to complex applications. As Xamarin.Form applications are native apps, they do not have the limitations of other toolkits.

The applications written using Xamarin.Forms are able to use any of the features of the API or the underlying platform, such as CoreMotion, PassKit and StoreKit on iOS; NFC and Google Play on Android; Tiles and Windows Phone. It also means that you can create applications that have parts of your user interface created with Xamarin.Forms while other parts are created using the native UI toolkit.

The Xamarin.Forms applications are architected in the same way as the traditional multiplatform applications with the most common approach is to use Portable Libraries or Shared Projects and then create applications for specific platforms that will consume shared code.

There are two techniques to create user interfaces (UI) in Xamarin.Forms:

1. Create UI in source code using the API provided by Xamarin.Forms,
2. Using XAML (Extensible Application Markup Language), which is Microsoft's declarative markup language that is used to describe interfaces. The user's interface is defined in an XAML file using the XAML syntax, while the runtime behavior is defined in a code-behind file separately;

The advantage to reach multiple platforms with a single programming language is the ability to share code between applications. Before the code can be shared an application must be structured for this purpose and the pattern MVVM architecture helps the developer to separate the code for a view of a specific platform, the code that needs to interact with the platform's API and the Model and View-Model independent platform.

Part of the application which is platform independent and can be isolated in a context of Visual Studio or Xamarin Studio can be placed in a separate project as follows:

1. Shared Asset Project (SAP): that is simply code files and other available assets from other projects;
2. Portable Class Library (PCL): which includes all common code in a dynamic link library (DLL) and then can be referenced from other projects;

Regardless of the method used, this common code has access to the .NET Framework class library, so you can perform I/O operations with files, dealing with globalization, access web services, decompose XML, etc.

That means you can create a unique solution in Visual Studio that contains four C# projects targeted at the three major mobile platforms (all with access to a common SAP or PCL project), or you can use Xamarin Studio to target iPhone and Android devices .

Thus one Xamarin.Forms application is composed of three separate projects for each of the three platforms, with a fourth project that contains the common code. The following is the diagram depicting this scenario:



The projects of the 3 platforms in Xamarin.Forms application are small and consist often only initialization code. The Shared Asset Project or Portable Class Library contains most of the application code including the interface code to the user.

The Xamarin.Forms.Core and Xamarin.Forms.Xaml libraries implement Xamarin.Forms API. Depending on the platform, the Xamarin.Forms.Core library uses one of the Xamarim platform libraries.

These libraries are mostly a collection of renderer classes that transform the UI Xamarin.Forms object's to the platform specific user interface.

The Xamarin.Forms also support the XAML of Microsoft as a general-purpose markup language to instantiate and initialize objects. The following is an example of XAML code:

<?xml version="1.0" encoding="utf-8" ?>
    <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" x:Class="HelloXamarinFormsWorldXaml.StackLayoutExample1" Padding="20">
        <StackLayout Spacing="10">
            <Label Text="Stop" BackgroundColor="Red" Font="20" />
            <Label Text="Slow" BackgroundColor="Yellow" Font="20" />
            <Label Text="Go" BackgroundColor="Green" Font="20" />
        </StackLayout>
    </ContentPage>

However, despite the enormous help that the Xamarin.Forms can offer you in creating applications for platform independent, it is not a complete replacement for programming the native API. If your application relies heavily on native API features, such as certain types of controls or widgets, then you may need to use the Xamarin.iOS, the Xamarin.Android, or Windows Phone API.

You will probably also need to use the native APIs for applications that need vector graphics or interaction sensitive to the touch. The current version of Xamarin.Forms is not quite ready to offer these features to advanced level.

On the other hand, Xamarin.Forms is great for prototyping or to create quickly line of business applications. And once you have done this, you might just find that you can continue using the Xamarin.Forms resources to build the entire application.

Even if you start building an application with Xamarin.Forms and then implement large parts of it with platform APIs, you'll be doing it within a framework that allows you to share the code and offering structured ways to make specific visual for each platform.

How to know when to use Xamarin.Forms or Xamarin.iOS or Xamarin.Android ?

Xamarin.Forms platform is best suited for:

• Data Entry Applications,
• prototypes and proofs of concept,
• Applications that require little platform-specific functionality,
• Apps where the shared source is more important than the UI.

Xamarin.iOS or Xamarin.Android is best suited for:

• Applications that require specialized interactions,
• Applications with specific and specialized design,
• Applications that use many specific APIs of the platform,
• Apps where the custom UI is more important than the shared code.