5 Things Apache Cordova Developers Need to Know When Switching to Xamarin

If you've decided to make a switch to Xamarin from Cordova for your cross-platform mobile app development, here are the top five tips you need to know.

While there is debate over whether the web-based programming model of PhoneGap/Cordova or the more native approach of Xamarin is the best "Hybrid" development model for mobile apps, this article will assume you've settled that debate for yourself and you're ready to make the leap to Xamarin. Here are some things you should know.

1. Xamarin and Cordova Solve Different Problems

To understand the differences and the similarities between Xamarin and Cordova, it helps to start with an understanding of the how the architectures relate to the mobile environments themselves.

Cordova based apps are built to run in a special wrapper around the HTML Rendering engine contained in the UIWebView (for iOS, WebView for Android) control. Think of it as a programmable web browser. Your HTML/CSS/JavaScript are all executed in that browser control. Cordova Plugins provide JavaScript wrappers around the native APIs exposed via the Objective-C Runtime or the Android Runtime. The Cordova Core plugins attempt to unify the features and functionality of all operating systems into a consistent API for your apps. Platform specific plugins are available for when you need to call OS or device specific APIs.

Xamarin apps are built to run in a version of the Common Language Runtime called Mono. Unlike Cordova Core libraries that attempt to hide the differences in the various OS APIs in a unified but often limited way, Xamarin exposes the native APIs directly with all features available to the developer. This also allows for Xamarin apps to be written against nearly any existing libraries for the OS platforms no matter what technology was used to create them.

For iOS apps running on an iPhone, the code is compiled into native binary libraries. This has some advantages and disadvantages and is described in detail here.

For example, here is Xamarin.iOS code used to initialize an app in iOS.

public partial class AppDelegate : global::Xamarin.Forms.Platform.iOS.UIApplicationDelegate
{
  public override bool FinishedLaunching(UIApplication app, NSDictionary options)
  {
    return base.FinishedLaunching(app, options);
  }
}

And here is the same code in Swift:

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
  func application(_ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    return true
}

Notice that the Xamarin app uses the NSDictionary object to hold the options. In this case, the NSDictionary object is a reference to an actual NSDictionary object from the Foundation APIs of iOS.

This is truly the core difference between Xamarin and Cordova. Cordova attempts to provide a unified JavaScript programming model for any mobile device while Xamarin is a programming model built to expose the features of the mobile platform in a way consistent for .NET developers.

2. Xamarin isn't Hybrid, Xamarin.Forms Is

You're right, it's not. At its core, Xamarin is a development environment built to allow .NET development on mobile devices with as little abstraction away from the platform as possible. You get the advantages of the .NET BCL libraries and Mono runtime along with the features of the underlying OS. If however you want to create apps that can run in multiple platforms, you would use a Xamarin Extension called Xamarin.Forms.

In a Xamarin.iOS or Xamarin.Android app, the UI elements are built using the same models as native development. That means iOS uses storyboards and views and Android uses .AXML files. Both Xamarin Studio and Visual Studio have great design time tooling for building user interfaces. Those files are then compiled into the app packages in much the same way as native apps, usually as embedded resources.

Xamarin.Forms is based on the XAML user interface programming model that has been around the .NET world for building Windows apps for quite a few years. As a matter of fact, Xamarin.Forms also works for building Universal Windows Platform apps as well which includes Windows 10, Xbox, HoloLens, Surface Hub, and others. XAML is a declarative model of building user interfaces, similar to HTML, but using well formed XML tags specific to the user interface controls for Xamarin.Forms. Here's an example of a basic UI defined in XAML.

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
                xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
                xmlns:local="clr-namespace:App2"
                x:Class="App2.MainPage">
  <StackLayout Orientation="Horizontal" HorizontalOptions="Center" VerticalOptions="Center">
    <!-- Place new controls here -->
    <Label Text="Welcome to Xamarin.Forms!"
              HorizontalOptions="Center"
              VerticalOptions="CenterAndExpand" />
    <Switch />
  </StackLayout>
</ContentPage>

This specification defines a simple page with a label in the center of the screen saying "Welcome to Xamarin.Forms" and a Switch control next to it.

While Xamarin.Forms controls are different from HTML controls, you'll find many of the same features are available and can roughly be grouped into the following categories.

• Pages: These controls represent the basic page types and include ContentPage, NavigationPage, TabPage, MasterDetailPage, and others.
• Layout: These controls manage the layout of other controls on the page and include things like StackLayout, ScrollView, and Grid.
• Views: These are the individual controls on a page such as Label, Button, Image, etc.
• Cells: These controls are used in ListView and TableView controls and are used to format the content of those controls.

We don't have time to cover all of these controls in this article, but you can read more about the various controls available and how to use them here. More importantly, these controls directly relate to UI controls on each of the mobile platforms.

Here is what the earlier example looks like in each platform:

Notice that each switch looks subtly different. This is because the platform itself determines how the control looks. This ensures that apps written for iOS look like other apps written for iOS, Android apps look like other Android apps, etc.

Xamarin.Forms pages and UI code is compiled into a library that is then included in a project for each platform, typically [App].iOS, [App].Android, [App].UWP. If you need to write platform specific code, you can add it to the platform specific projects. Xamarin.Forms also has ways to specify platform specific values, but mostly you'll want to keep your platform code in the platform projects.

3. Working with Images is More Complex

In web technologies, images are easily incorporated into applications with the WebView control doing most of the heavy lifting to translate the image to the screen resolution of the device. In native mobile apps and Xamarin, things are a bit trickier. Images are embedded into the app as resources and depending on the platform can require you to create multiple versions to allow for the differences in screen resolution.

For iOS, images are organized into Asset Catalog Image Sets and require a version of the image in different sizes to support the various resolutions and scaling of iOS devices. You then use a JSON file to specify which images work with which devices and resolutions.

For more information about using images with Xamarin you can read more here.

In Android, images are resources that are embedded into the application. While Android will attempt to scale the images to the device resolution, you can assist that by providing varying density bitmaps. You can use the Android Asset Studio to generate these images for use in your Xamarin apps. Resources are organized into folders and images are placed in folders that start with "drawable." Here's an example of the folder structure:

For more information on using images in Xamarin Android you can look at the documentation here.

4. C# and JavaScript Aren't that Different

If you're used to coding in JavaScript, you'll find C# a relatively easy transition. JavaScript is based on the Java language which itself is based on C which is also the basis for C#. So many of the same structural concepts such as control, branching, etc. are all very similar. What's more if you've been writing your JavaScript using the latest Angular framework then you are familiar with TypeScript. TypeScript is a strongly typed language that generates JavaScript.

C# and TypeScript were both designed by Anders Hejlsberg at Microsoft

Angular components and C# classes are actually quite similar. Take for example, these two classes:

Angular/TypeScript

import { Component } from '@angular/core';
import { NavController } from 'ionic-angular';

@Component({
  selector: 'page-contact',
  templateUrl: 'contact.html'
})

export class ContactPage {
  constructor(public navCtrl: NavController) {
  }
}

C#/Xamarin.Forms

using Xamarin.Forms;
using Xamarin.Forms.Xaml;

namespace HelloXamarin<
{
  [XamlCompilation(XamlCompilationOptions.Compile)]
  public partial class ContactPage : ContentPage
  {
    public ContactPage ()
    {
      InitializeComponent ();
    }
  }
}

Each class accesses code from other libraries via Imports or using, each has a constructor, both use the standard curly brace and semicolon that derive from the root C language. The biggest difference is that JavaScript allows you to swap variable types at will including assigning functions to variables. C# is a typed language and so you generally specify the specific types you want to use. For example:

var x = "1";
var y = x * 2;

In JavaScript this code will run fine and y will be assigned the value of 2. The JavaScript interpreter converts the string value of x to an integer at runtime and then multiplies by 2 and assigns the result to the variable y.

In C# this code won't even compile as you will get a compiler error saying "Operator * cannot be applied to operands of type 'string' and 'int'." This may seem like a limitation but what is happening is the compiler is forcing you to be explicit so that you can avoid errors at runtime. Bugs are always easier to kill before they get into production.

This specificity also means that more complex concepts in JavaScript such as Promises require a slightly different approach in C#. Variables that reference a function (or method in C#) are a specific type called delegates. The C# language has the ability to use anonymous delegates (aka Lambdas) so you can write your code in much the same way as you would in JavaScript. For example, this code is executed when the user clicks on the Switch control:

Switch.Toggled += (sender, e) => {
  // Switch Button Toggled
};

However, to truly implement JavaScript Promises, you'll need to use the .NET Task library in System.Threading.Tasks namespace. Here is an example taken from an excellent post on the subject by Matt Mazzola.

JavaScript

const GetNumberPromise = async (): Promise<number> =>
new Promise<number>((resolve, reject) => resolve(util.SimulateSynchronousApi()))

C#

public static Task<int> GenerateNumberAsyncTaskRun()
{
  return Task.Run(() => SimulateSynchronousApi());
}

5. Building Your App in Xamarin is Just Like Building it in Cordova

Xamarin and Cordova both rely on the native platforms to build the application for deployment. If you use the command-line "cordova build ios" or "cordova build android", it will launch a series of batch commands that will call the corresponding platform SDK to compile and package your app. This means for example that in order to build an iOS app, you need to be running in iOS because you need XCode. Many Cordova developers have worked around this requirement by using Adobe PhoneGap Build, an online tool that allows you to upload a ZIP of your project and they will compile it against the platforms of your choice.

Xamarin works in much the same way, locally you can build your apps against the various SDKs. Xamarin does allow for you to build your iOS apps from Windows if you have an iOS machine it can connect to. But Microsoft also has the Visual Studio App Center which will allow you to build your apps for any platform along with a ton of other features like automated testing on real hardware devices, beta test your apps without having to go through the respective App Stores, and also debugging and analytics.

If you have decided to make a switch from Cordova to Xamarin, these tips should help make the process easier for you. But of course, everything can't be covered in one post. If you've already switched, what other tips did you wish you knew? Feel free to share in the comments below.

And for those of you developing Xamarin apps looking for a comprehensive, modern set of UI components, don't forget to check out Telerik UI for Xamarin - download a free trial and build professional Xamarin apps fast.