Xamarin for the non-xamarinist

 A Xamarin introduction

This is a post about some facts you need to know to get started with Xamarin development. It's not code centric so the target audience would be someone who's interested in the basic Xamarin facts.

We assume that the target platforms are iOS and Android. It’s worth pointing out that Xamarin (and especially Xamarin Forms) can target Windows Phone, Windows Desktop Apps and Mac OS X apps as well.

Specific requirements for iOS

Apple requires that all iOS apps are built on OS X which in turn only can run on Apples hardware. This means that you must have a Mac to build iOS apps. Xamarin also uses the XCode toolchain for compiling the app,
There are some approaches to this:

• The first hand recommendation is to use a MacBook (Air/Pro) with Parallels Desktop (virtualization software) to run Windows on the same machine. This allows for a seamless transition between OS X and Windows, enabling the developer to use Visual Studio to develop iOS apps.
  
• The second hand recommendation (perhaps in combination with the first recommendation) is to acquire a Mac Mini as a local build server. A windows client can connect to this build server and send all iOS builds to it. There is also the possibility to remote access the simulator directly from within Visual Studio. If you have a Windows computer (like a SurfaceBook) you also get multipoint touch in the simulator.
  
• Another option for build is to use Visual Studio Mobile Center (currently in preview) to take care of the builds for you. It’s a wrapper on top of multiple Azure services.

 Xamarin Forms or Traditional Xamarin development

One thing you have to do early in the project is to get a good grip of the difference between Xamarin Forms and Traditional Xamarin development.

Xamarin Forms is a GUI abstraction that renders fully native user interfaces. It allows for a shared GUI codebase with the drawback of pixel perfect designs.

Traditional Xamarin Development is best if you have a lot of differences between the platform user interfaces or simply like storyboarding and axml.

Regardless of which approach you take you should strive for moving as much of the logic away from the GUI and into shared code base as possible.

Xamarin Forms

Xamarin Forms is a platform on top of Xamarin that abstracts the GUI-code (Xaml or C#) but still renders 100% native user interfaces.

It is very possible to make beautiful apps in Xamarin Forms but it still requires that you have knowledge about the underlying platform. You also have to ability to drop down into platform specific code at any moment. Especially through the user of Dependency Injection which plays a vital role in a cross platform mobile architecture . You also have the ability to create separate views for each platform even if you declare them in the shared library.

The most common architecture to use when writing a Xamarin Forms application is MVVM. There are a lot of tooling and resources available.

The basic idea in forms is that you declaratively define you UI using XAML or C#. Most common is to use XAML. For example, a button in XAML could look like this: <Button Text=”My Button” />. When this renders (or compiles if you use Compiled Xaml) this is turned into a UIButton on iOS and a Button on Android. The conversion between abstract and concrete classes is done by the concept of Renderers. Every renderer can be extended or replaced. You can also write your own renderer. There is no hidden magic.

And it’s all open source.

Traditional Xamarin Development

In traditional development you define the GUI in the same way that you do it when developing apps using the vendor specific tooling. (Java in Android Studio or Swift/Objective-C in Xcode). On iOS that usually means Storyboarding and on Android you are most likely defining the GUI in axml-files. You could also write it using C#, but it tends to be a lot of code to write.

You can still (and should) choose to use an MVVM-framework to move all the common code out of the views.

UI Testing

When it comes to Android specifically, UI Testing is a must and it’s highly recommended that you find some tooling that helps you with this.

Xamarin Testcloud is one of those tools/services that allows you to run your app on thousands of hardware devices with the weirdest combination of OS versions installed. You simply cannot do this in an affordable way yourself.

You author your tests locally first, in code or with a test recorder. Then you submit the tests and a build to TestCloud and select what devices you want to run it on. You pay by the device minute used.

It also works perfectly for iOS and even for apps that aren’t written in Xamarin at all.

The other great benefit of Testcloud (or services like Testcloud) is that you can recreate bugs on the actual device/OS combo that the bug was spotten on without having to buy that specific device.

Architectures and plugins

This is the current list of components/nuget-packages/services that I currently recommend using in a Xamarin App.

·       Autofac – Dependency injection.

·       MVVM – I often use Vanilla MVVM with a simple base class for the most common stuff..

·       PropertyChanged.Fody – IL injection (weaving) of INotifyPropertyChanged. ViewModels get’s a lot smaller and code readability increases.

·       Acr.Dialogs – An abstract way to use common system dialogs (think UIAlert etc.)

·       Akavache – Cache amd SQLite databas packaged for Xamarin. Also supports secure and encrypted app based storage.

·       HockeyApp – Error tracking and usage tracking.

·       Newtonsoft – Json serializer

·       TinyPubSub – Very simple PubSub handler for internal communication.

·       Xam.Plugin.Connectivity – Plugin for handling network changes

·       Xam.Plugin.Geolocator – Plugin for handling GPS

·       Xam.Plugin.Media – Plugin for handling camera and media

·       Xam.Plugin.Settings – Cross platforms settings

·       Xam.Plugin.Vibrate – Plugin for handling vibration

·       ZXing.Net.Mobile – Bar code scanner if one should be needed.