During my first days of being a student at a Computer Science Faculty, I started to think of a lot of new ideas regarding Phone Development, being influenced by the simplicity of the development tools that I was exploring during my highschool years. I’ve started with Windows Forms, and then I’ve found out that Visual Studio can be used to develop mobile applications. So I bought a brand new Nokia Lumia 520 running Windows Phone 8.1 and I started to develop small (and some of them useless) mobile applications. The most complex one that I’ve managed to develop, was a simple accelerometer-based game where you need to tilt the phone to catch some random-falling balls with a pad that was moving according to your tilt angle. That is how I entered in the Microsoft Innovation Center team.
The satisfaction was overwhelming.
Now, after a year and a half with that passion a bit shadowed by the fact that Windows Phone wasn’t actually very popular, I’ve started to gain more interest in a very promising infrastructure, that seems to leverage the power of cross platform mobile development at a very high level: Xamarin
One of the most important advantages of using Xamarin as a mobile development platform consists of the fact that you can deploy apps on iOS, Android and Windows Phone using a single programming language (C#) and a single business logic codebase. That means that you can develop your app using a single team, you don’t need to have 3 different developer teams, each one specialized in a single technology. For a big company that invests a lot of time and effort in managing developer teams, it really means a lot!
The backbone of Xamarin consists of the following components:
- Xamarin.Forms – It allows the creation of cross-platform User Interfaces using XAML (eXtensible Application Markup Language). That means that you can create controls, layouts, pages, in a generic form which then (at deploy) translates to the native platform-specific equivalent code.
- Xamarin.iOS – A set of C# API wrappers over the Objective-C native platform specific ones as well as a set of compilers that translate the C# code to the native one. iOS doesn’t allow runtime code generation (for security purposes) so there are a few C# features, like Reflection.Emit, that are not supported by the platform.
- Xamarin.Android – A set of C# API wrappers over the Java native Android approach, that allows us to use all the features provided by Android API’s.
An important aspect to mention on Xamarin is the one that it is based on the Mono Project, the open source version of .NET Framework. Xamarin.Android is based on Mono for Android (or MonoDroid) and Xamarin.iOS is based on Mono Touch. Both of them derive from the Mono Project and, of course, their update level depend on the synchronization level that is maintained between Mono and the actual .NET Framework.
Understanding the things behind a specific technology is probably one of the most exciting steps in the career of a Software Engineer. So in order to see how the things actually take place when be build a Xamarin mobile project, we will start with Xamarin.iOS:
I need to mention that Xamarin.iOS is the first technology that makes possible the development of a native iOS application using almost entirely a non Apple development environment. There were a lot of interesting approaches of developing cross platform mobile apps but none of them was targeting a native final solution.
The journey of the C# code that we execute in a Xamarin.iOS application is the following:
As you can see, the code that we run on our Windows machine is executed by an AOT compiler that translates it to a system-dependent, native code that is run by the Mac OS Execution Environment in a specific virtual machine, known as iOS Emulator. That means that in order to develop iOS apps on Windows, we need a networked Mac that communicates with our Visual Studio Xamarin.iOS project. There is no workaround on this restriction because any iOS app developed with Xamarin needs to execute an OS X dependent code, so this can be achieved only by running it on a Mac with Xamarin and XCode installed.
The newest version of Xamarin.iOS includes an iOS Emulator for Windows which basically executes our application in our Windows machine, without the need of switching to the Mac to see how the app works.
On Xamarin.Android, the things are a bit simpler than the above situation, mostly because the entire process is done on the Windows machine that we use in order to develop our app:
The code that we run is translated into an IL code which then goes through the Mono VM and finally executes on the Android Runtime. The communication with the native API is made using the Java Native Interface.
There are a lot of Android Emulators available. The difference between all of them consists of their speed and their responsiveness. The best ones are those that are compatible with Visual Studio. They use Hyper-V as a Virtualization Supervisor and I think that they are the best solution when we talk about Xamarin.Android development.
In the case of Windows 10 Mobile apps the things are even simpler than the ones above, in the way that the code is executed entirely inside the .NET Framework. We don’t need any other external tools:
It behaves the same as any other C# code that we execute, except the fact that it runs on a special Hyper-V-based VM. We don’t need Xamarin libraries to develop Windows 10 Mobile apps.
Xamarin Solution Architecture
There are 2 IDE’s that we can use to develop Xamarin projects: Visual Studio and Xamarin Studio. We will mostly use the first one because it provides us a lot of useful features as well as extensibility.
When we develop a cross-platform mobile project, we actually want to create the same application on all 3 mobile platforms. However, we will not have a single project that runs on all platforms because each platform has it’s own starting processes, UI management systems and a few other specific features.
That means that we will have a solution that contains a project for each platform, and another special project which is referenced in all the other platform specific projects and which contains the common business logic code. The following diagram explains that separation in a visual way:
That approach will lead us to a very flexible development process and a simpler and effective architecture model. The Core Library project will contain all the common logic that can be executed on all the other projects, for example: data management, network communication, UI models, computation logic, etc. On the other hand, the platform-specific projects will contain mostly UI specific features as well as the startup processes for every platform which basically includes the initialization of the UI Controllers and the main windows (pages).
The Core Library project can be exposed in 2 separate ways:
- As a Portable Class Library which basically compiles the cross platform C# code and the resulting IL is binded at runtime in the platform specific DLL’s.
- As a Shared Project which compiles the common code in every platform specific project. Because of the fact that it doesn’t have any output (DLL), it behaves as the code was already present in the current project. That leverages the possibility of using compliation directives as #IF PLATFORM.
I hope that you have now a new vision about the way Xamarin works!