LAC06: Getting Started with Xamarin & Visual Studio for Android

0 Flares Twitter 0 Facebook 0 StumbleUpon 0 Google+ 0 LinkedIn 0 0 Flares ×

Getting up and running, developing inside Visual Studio with Xamarin is really where I want to be, so I thought I’d write a brief post about getting started with xamarin and visual studio. I know I could have used Xamarin Studio at a vastly lower licence cost, but I really wanted to be using Visual Studio with Resharper. I’m familiar and way more productive using these tools than I would be with Xamarin Studio, and whilst I may give it a try at some point, its not for this project!

xamarin-hero

Xamarin with Visual Studio

Getting up and running with Xamarin in Visual Studio couldn’t be easier. Assuming you already have copy of Visual Studio – its literally a case of downloading the Xamarin installer and off you go. One thing to note is that the Xamarin Visual Studio plug-in doesn’t work on express versions.

If I’m honest, the premium you pay for a Xamarin licence that supports the Visual Studio plug-in is pretty high, so this kind of seamless installation experience is what I’d expect, and the Xamarin team have really delivered on this front.

Once you’ve got everything installed you can pretty much launch up visual studio as you’d expect, and create a new project from a Xamarin template.

The Xamarin Templates

Xamarin adds a load of project templates – I’d go over them all in detail but the list would probably get out of date pretty quick! The first thing to understand though is that conceptually 2 types of project template:

Device Specific Templates

Device Specific Templates

These are the project templates within the folders such as iOS and Android, and are specific to a particular target environment. The code written in each of these projects will only be applicable to the device(s) they’re designated for, for example the ‘Android Application’ template is only for android devices, whereas the ‘iPhone – Empty Project’ is only for the iPhone. This may seem obvious, but I thought I should point it out!

The second thing to mention about these type of projects is that no matter how you’re developing, the minimum that it will have is one of these type of device(s) specific projects.

  • If you’re targeting iOS it’ll need an iOS project
  • Android will need an Android project
  • Both means you’ll need one of each.

They are essentially the project that represents the final deployment unit to the device.

Shared Library Templates

Shared Templates

Any kind of shared project in Xamarin is essentially code that can be accessed by multiple projects, and therefore provides the best unit of reuse for your code. Within this category there are however, 2 ways in which you can share code:

  1. Shared Asset Projects: These projects are a kind of container for your code, that essentially get picked up and compiled as part of device specific projects. The project allows compiler directives, so that sections can be catered for specific devices, but has no actual output (as it is compiled into you device assemblies).
  2. Portable Class Libraries: PCL projects are essentially a compiled unit that can be referenced by the various device specific projects. These projects can used across multiple projects (including standard .Net projects), but only a subset of the .NET framework is available however, as they’re designed to be portable.

I’ve summed up the main arguments for each in the table below:

Portable Class Library vs Shared Asset Project (Xamarin)
Shared Code Portable Class Library
Code shared across multiple projects Only Xamarin projects All Projects
Platform specific code Yes, via compiler directives No, can be achieved via class abstraction
Refactoring support No, code inside inactive directives will not be refactored Yes, all refactoring operations will work.
Xamarin.Forms XAML Support No Yes

Xamarin App Architecture

The second major consideration is how to approach the solution architecture. At this stage I really don’t want to get bogged down in too much architectural thinking, and given that this is the first MVP its really not required. That said I do want to learn some best practice whilst doing this, and there are a couple of things I’d like to cover.

Xamarin.Forms

Xamarin.Forms is probably one of the biggest features of Xamarin that I wanted to use, as it delivers the greatest degree of reuse. Without getting into too much detail, Xamarin.Forms is essentially an abstraction over the user interface layer, meaning that you can define a use interface once using Xamarin.Forms, and it will be translated into the target platforms’ specific implementation.

Example Xamarin.Forms App

This is great news because up until Xamarin.Forms existed the user interface would have to be written for each target environment individually (which you can still do if you like). Furthermore in the scenarios whereby you need to do something differently on a specific environment you can override those parts as and where you need.

XAML (eXtensible Application Markup Language)

Those of you familiar with WPF (Windows Presentation Foundation) or Silverlight will know what XAML is. For those that don’t, its basically a declarative XML syntax for creating your user interface(s). XAML is the syntax used for declaring user interfaces in Windows Phone / Windows 8 apps, and is at the core of WPF. Xamarin.Forms also allows you to define your user interfaces using XAML, which it then translates for the target environment.

The benefits of XAML are numerous, but the number one if that its declarative and the mark-up maps pretty clearly to what you actually see on screen. Coming from a web background, defining mark-up for your user interface feels far more natural than using custom designers, or writing imperative code.

General Architecture

As previously mentioned, I don’t want to get too deep into this at this stage, but there are a few things that I know I’ll want to do, such as:

  • Keep clean separation between the UI layer, application layer, the data access layer, the service access layer etc.
  • Use some form of dependency injection.
  • Use the Model-View-ViewModel (MVVM) patter wherever possible.

In further articles I may dive a little deeper into each of these subjects if it seems relevant.

Pulling it together

Pulling all of this together I’ve got the following decisions that I have made about my approach in using Xamarin:

  • I’ll be developing primarily for Android for my first MVP, but porting to iOS and Windows should be pretty straight forward.
  • I’ll be using Xamarin.Forms wherever possible, with XAML to define the user interface.
  • I’ll be approaching shared code using portable class libraries as it feels most natural to me, and provides the facility to reuse code to other projects (like maybe a web project). It is also a requirement when using Xamarin.Forms with XAML.
  • I will use the “Blank App (Xamarin.Forms.Portable)” project template for the reasons stated above.
  • I’ll try to keep clean separation of concerns and adopt the MVVM pattern.

,

The Essential App Marketing Kit
Subscribe To My Newsletter To Get an Entire Chapter From The Book for FREE
Never display this again
0 Flares Twitter 0 Facebook 0 StumbleUpon 0 Google+ 0 LinkedIn 0 0 Flares ×