Introduction To Xamarin: What It is & What It Isn’t
As of this writing, I have been actively developing for iOS and Android with Xamarin for almost 2 years. In that short time, the platform has grown rapidly and has matured quite a bit. I’ll be the first to admit that there still is some work to be done. But I’m confidant that by this time next year, the platform will have matured even better. It certainly has since I first started.
As a software engineering consultant for a firm, my colleagues often ask me what my current engagement is and what type of applications am I developing. When I mention that I’m developing iOS and Android apps using Xamarin, the majority have them have heard the term, and read about what it does. My current employer is a Microsoft Partner and one of 34 Microsoft National Systems Integrators. So naturally, the majority of my colleagues are .NET Developers. And some of the best I’ve worked with I might add.
But regardless, during our conversations about technology, specifically mobile development using Xamarin, I find that there are a lot of common misconceptions on what Xamarin is and what Xamarin isn’t. There are a good number of tools that help you write cross platform mobile apps that share a common architecture. However, I think that Xamarin is unique enough on their approach and philosophy on cross platform mobile development that they often unfairly get associated with other tools. So the purpose of this article is to explain what Xamarin is, and what Xamarin is not.
Approaches To Mobile Cross Platform Development
In order to understand, and even appreciate, what Xamarin is I must first explain the different approaches to mobile development. If you’re new to mobile development, even if you’re an experienced .NET developer, I think it is essential to understand these different approaches in order to have a complete understanding on why Xamarin is designed the way it is.
The Silo Approach
The silo approach is the most common method of building mobile applications. Each platform is built independently of each other. Each platform is written in a separate programming language, using their own native tools, and contains their own suite of libraries and unit tests. For iOS, a developer uses Apple tools such as XCode, and Objective-C or Swift as the programming language. For Android, developers can use any number of IDEs such as Android Studio or Eclipse, but the main programming language for Android is Java. Both platforms are usually written by separate teams.
Platform Code Independent Of Each Other
For iOS, a typical iPhone/iPad application, one would have to write the following:
- Main UI App (Objective-C)
- Models & Entities (Objective-C)
- Data Layer, Business Logic, etc (Objective-C)
- Unit Tests for your Core Logic (Objective-C)
- Unit & Functional Tests for User Interface Layer
For Android, a typical Android application looks similar, but you would have to re-write everything you wrote in Objective-C into Java. The Main UI App is a given, but you have two different code bases for your Models, Entities, Data Layer, Business Logic, etc. In addition, you also have a different Unit Test suite to test your applications core logic.
One advantage of using the silo approach are you are using native controls, and you get native performance. Now this makes the assumption you follow coding best practices of course. But an iOS app will always behave and look like an iOS app, and an Android app will always look like and behave like an Android app. Though using this approach is the most common, and seems like the only way to do it, it does provide some disadvantages in regards to application development and maintainence.
One disadvantage is that significant overhead and cost is added because you’re essentially are building and maintaining the same application, two times (or three of you want to support Windows Phone). Let’s take business logic for example. Let’s say you have a set of validator classes that help you validate data that a user inputs into a field. The user enters in an e-mail address, and you must validate the field to ensure what the user entered is an e-mail address. Android and iOS would both have different code bases for this, potentially written by different developers. And each developer would also create unit tests for this business logic.
If an iOS project takes about 400 man hours to build (not including back end web services), most likely an Android project would roughly be the same amount of hours in theory. So in total, you have about 800 man hours for building your app on two different platforms. Now multiply that by the hourly rate of each developer, and you get your actual cost for the labor of your app. Is this approach good or bad? It depends on your situation and application requirements. But most clients I have worked with usually want to keep costs down as much as possible.
The Black Box Approach
The black box approach is different from the silo approach in that you usually have one code base to rule them all. Opposite of the silo approach, you have one code base for your models, entities, data layer, business logic, and even your user interface! Many of these tools and frameworks utilize web technologies such as HTML 5, CSS 3, and JavaScript. Much like a web page, you use these technologies to create your application. In addition, if you need to access device level APIs (such as GPS, Camera, Contacts, etc), there are JavaScript bindings that allow you to do so. At a high level, your HTML, CSS, and JavaScript get packaged into an actual Native Application, and gets installed on a device as a native application. However, this native application is nothing more than a WebView (a web browser controller) that renders the application you built. This is a called a hybrid application. You basically build a touch friendly mobile web site that is rendered by the operating system’s Native Web View.
Write Once, Run Anywhere
The obvious major advantage to this is that you can create your entire application one time, and it will run on multiple platforms such as iOS, Android, Windows Phone, Blackberry, etc. In addition, if you have web developers on staff who already know HTML, CSS, and JavaScript, there is less of a learning curve for them to develop mobile apps. Though this sounds like the magic silver bullet, this approach does have disadvantages that are very worth considering.
One disadvantage is, that your user interface frame work only supports the least common dominator. For example, if you decide to use JQuery Mobile for your UI, it generally supports any browser or webview that supports compliant HTML 5 and generally is not as performant as native or other touch friendly frameworks. Other types of frameworks tend to support the more popular browser engines, such as WebKit, but wont fully support other browser engines. In addition, in the case of Android, it can be difficult to account for the different browser engines that Android manufactures implement. In many cases, as any experienced web developer will know, your app may not perform, or look like the way it is intended due to these differences. I won’t get into too much detail on this, but viewing the link below will give you an idea on potential challenges. **evil laugh**
http://slides.com/html5test/the-android-browser#/
The Xamarin Approach By Example
When one reads or hears about Xamarin for the first time and the ability to “build cross platform mobile apps using C#”, it is easy to categorize it in the black box approach. And if you’re already an experience .NET developer, it is also tempting to assume that all your current C# code can port over. At first glance, you write C# like you normally would, it goes into a black box, and then out comes an iOS and Android app. Yay!! Well, unfortunately, if it sounds too good to be true……. Rather than explain what Xamarin is, let’s think of this in another way.
Let’s say you decide to take the silo approach and learn Objective-C to build iOS apps. You fire up your search engine of choice and find a tutorial. In this tutorial, you are learning how to programmatically create a button, set it’s title, and act on an event when the button is tapped. So your Objective-C code can look something like this:
- (void)loadView
{
//create the button
UIButton *button = [UIButton buttonWithType:UIButtonTypeRoundedRect];
//set the position of the button
button.frame = CGRectMake(100, 170, 100, 30);
//set the button's title
[button setTitle:@"Click Me!" forState:UIControlStateNormal];
//listen for clicks
[button addTarget:self action:@selector(buttonPressed) forControlEvents:UIControlEventTouchUpInside];
//add the button to the view
[self.view addSubview:button];
}
-(void)buttonPressed
{
//Button has been pressed
}
Let’s not worry about the semantics. If you’ve never used Objective-C before, but have experience with C#, you look at the above code and think….ummm…..wut!?!? I certainly did! But if you read the comments, you can follow along on what the code is supposed to do. To a .NET developer, the syntax seems odd. But if you read carefully, you can see a UIButton class is being created. A UIButton class defined in UIKit. UIKit is part of the iOS SDK that contains classes to create iOS user interfaces. So if you’re a .NET developer think of UIKit as a namespace such as System.Windows.Controls for Windows Phone. It’s now obvious that in Objective-C, you’ll use many other parts of the iOS SDK to create your app. UIKit for the user interface, MapKit for maps integration, etc.
Now your going through this tutorial and think to yourself, “If only I could do this in C#”. Well, now you can! What Xamarin has done is to create a C# binding to the iOS SDK. There’s a little bit more to this than what I can explain in this article, but for now think of Xamarin.iOS as a C# wrapper around the iOS SDK. You can now use the iOS SDK via C# instead of Objective-C. So here’s how the C# version of the Objective-C code looks like.
//create the button
UIButton button = new UIButton(UIButtonType.RoundedRect);
//set the position of the button
button.Frame = new RectangleF(100, 170, 100, 30);
//set the button's title
button.SetTitle("Click Me!", UIControlState.Normal);
//listen for clicks
button.TouchUpInside += ButtonPressed;
//add the button to the view
this.View.AddSubview(button);
private void ButtonPressed(object sender, EventArgs e)
{
//Button has been pressed
}
Now, does that look a lot better? Are you more familiar with what’s going on? It looks very similar to any other .NET application you would write. But you’re not writing a .NET application. You’re writing an iOS application that will run on iPhones and/or iPads using Apple’s iOS SDK! Go ahead, compare the Objective-C version and the C# version line by line. Makes sense now? We’re using the same UIButton class as in the Objective-C code, but using the C# syntax. Now this was a direct port. Let’s take the C# code and “.NETify” it just a little bit.
var button = new UIButton(UIButtonType.RoundedRect)
{
Frame = new RectangleF(100, 170, 100, 30)
};
button.SetTitle("Click Me!", UIControlState.Normal);
button.TouchUpInside += (sender, e) =>
{
//button has been pressed
};
this.View.AddSubview(button);
Pretty neat! Now we’re starting to look like a .NET app. (But it’s not!) Just for kicks, let’s look at the same example, but for Android using Java.
Button button = new Button(this);
button.setText("Click Me!");
button.setOnClickListener(this);
public void onClick(View view) {
//button has been pressed
}
The Java syntax closely resembles more to C#, than Objective-C does. Again, we won’t worry about the semantics, I’ll get to that in another article. But Button is a class defined in the Android.Widget namespace. This namespace contains all UI related controls used by an Android application. It’s similar to UIKit and System.Windows for WPF. So in C#, it would look like this:
var button = new Button(this);
button.Text = "Click Me!";
button.Click += (sender, e) =>
{
//button has been pressed
};
Pretty slick huh? Impressed yet? We’re using the same Button class that’s defined in the Android.Widget namespace in Java. Don’t worry, we’ll get into a real application later, but for now that’s beyond the scope of this article. The main purpose of this article is to help you understand what Xamarin is and what it isn’t.
Why Is This Unique?
This approach is a rather unique approach because Xamarin has created C# bindings for Xamarin.iOS and Xamarin.Android to the iOS and Android SDKs respectively. You are using the same classes and APIs to create an iOS app as an Objective-C programmer would to create an iOS app. And you’re using the same classes and APIs a Java programmer would use to create an Android app. But what about performance? From my experience, on most applications you do get native performance or very close to native performance. Assuming you follow best programming practices, performance on Xamarin applications are negligible to their native counterparts. If you do some Googling, you can find some benchmarks that compare Xamarin apps to their native apps. In the case of Android, the most noticeable lag is start up time. This is because the Mono runtime must start up, as well as the Dalvik runtime. This is a known occurrence, but in my experience this does not degrade the user experience. Now that we have a 10,000 foot overview of what Xamarin basically is, let’s go over what it is not.
What Xamarin Is Not
WriteOnce, Run Anywhere (Well, Maybe)*
Prior to Xamarin Version 3, Xamarin was often mistakenly considered a write once, run anywhere* framework. Though you can share non platform specific code between iOS, Android, and Windows, you still have to create an iOS project, and an Android specific project in order to create your user interfaces.
Noticed the asterisk (*)? I put the asterisk on the heading because starting with Xamarin 3, Xamarin has introduced Xamarin.Forms. Xamarin.Forms is basically an API abstraction layer that allows you to create a User Interface using either code or XAML. Note, that this is not the same XAML implementation you see in WPF or Windows Phone development, so they are not compatible. However, the syntax and implementation is very similar. A User Interface created using Xamarin.Forms does compile down to the native SDK implementation. For example a Xamarin.Forms Button will compile into a UIButton on iOS, a Android.Widget.Button on Android, and a System.Windows.Controls.Button on Windows Phone.
Just like how Xamarin.iOS and Xamarin.Android are C# bindings to iOS and Android SDKs respectively, Xamarin.Forms is a cross platform User Inter face framework that abstracts common user interface controls among iOS, Android, and Windows Phone. But when compiled, it uses the Native user interface control. So you get native performance because your Xamarin.Forms app IS a native app using the native SDKs. Now, you have the ability to create common user interfaces in a Shared Library or Portable Class Library and use them in your Xamarin.iOS or Xamarin.Android application. This topic does deserve it’s own blog post, so I’ll be posting that soon!
Xamarin Turns .NET Apps Into Mobile Apps
A common misconception is that you can open your current WPF, ASP.NET, or Windows Phone app with Xamarin and it will automatically convert your .NET application into an iOS or Android application. This is not the case. Xamarin is not a converter. However, if you architected your application correctly, as in defined your models, business logic, and data layers in separate class libraries, you may be able to use that existing C# code with Xamarin. You may have to make slight modifications here and there, but it will certainly be easier that a complete re-write in Objective-C or Java!
If you have an existing C# library, you can upload your *.dll to http://scan.xamarin.com. This is a tool that Xamarin developed to help you understand which parts of your code are not compatible with iOS, Android, and/or Windows Phone. If you have existing code you want to port over, then this is the best place to start.
Xamarin Uses The .Net Framework & C# Code Is C# Code
It is true you use C# to write cross platform apps with Xamarin. But, Xamarin only runs C# that is platform independent. I place heavy emphasis on platform independent. As stated earlier, Xamarin does not use the Microsoft.NET Framework runtime. It uses the Mono runtime. The Mono runtime is the open-sourced implementation of the .NET Framework. It’s not the same, but it looks and behaves mostly the same.
For example, let’s say you have existing C# code that uses System.Drawing.Bitmap. It’s a common library you wrote that multiple Desktop apps reference. A possible method looks something like this:
using System.Drawing;
public Bitmap GetBitmapFromCache(string fileName)
{
return (Bitmap) Image.FromFile(fileName);
}
If you were to compile this method in a Xamarin.iOS or Xamarin.Android app, you would get a compile error. Huh? Upon further investigation, you would see that System.Drawing.Bitmap and System.Drawing.Image are not define. What!?!? That’s valid C# syntax! Upon further investigation, you only see a few classes in System.Drawing are actually defined (RectangleF, PointF, etc). Where the heck is Bitmap and Image? Well, there is a good reason these classes are not implemented in the Mono Framework. It’s because they are not cross platform compatible.
What does that mean exactly? Let’s take a look at the System.Drawing documentation on MSDN. It states, “The System.Drawing namespace provides access to GDI+ basic graphics functionality.”. What is GDI+? GDI+ (Graphics Device Interface) is a graphics library (Win32) that is specific to the Windows Operating System. So underneath the hood of a System.Drawing.Bitmap, is a Win32 implementation that ties into the Windows Desktop/Server Operating systems. That means System.Drawing.Bitmap and System.Drawing.Image are platform dependent, and only work on Windows Desktop/Server apps. You will not be able to use these classes on iOS app, Android apps, or even Windows Phone apps. So how can you use this current C# code in an iOS or Android app? With a slight modification like this:
public byte[] GetBitmapFromCache(string fileName)
{
return File.ReadAllBytes(fileName);
}
iOS and Android have no concept of GDI+ bitmap (System.Drawing.Bitmap), however, each platform knows how to convert an array of bytes into their own implementation of a bitmap. Using iOS, you can create a UIImage from an array of bytes, and in Android you can create an Android.Graphics.Bitmap from that same array.
So I hope you set expectations accordingly. There are many parts of the .NET Framework that are platform specific to the Windows OS. Those parts won’t be available to you in Android or iOS, just be aware of that.
Summary
I hope this gives you a brief introduction on what Xamarin is, and how their approach is different than from other cross platform tool and pure native development. Believe me, there’s a lot more detail on how Xamarin.iOS and Xamarin.Android work under the hood. Each of those topics deserve their own article, so I’ll be posting those up soon. Here are a few bullet points I want you to walk away with:
- Xamarin.iOS is a C# wrapper (bindings, specifically) around the iOS SDK. A compiled Xamarin.iOS app is a native app.
- Xamarin.Android is a C# wrapper (bindings, specifically) around the Android SDK. A compiled Xamarin.Android app is a native app.
- Xamarin uses the Mono Framework, not the Microsoft .NET Framework. Mono is the open sourced implementation of the .NET Frameworkl.
- You can share C# code (that is not platform specific) between an iOS, Android, and Windows Phone app.
- Not all of your current C# code may port over to iOS or Android, you may have to make some adjustments.
- Xamarin’s general philosophy is to not be a Write Once, Run Anywhere platform. Though it is very close to one with Xamarin.Forms, but not quite. And that’s intentional.
I hope you found this article informative. And as always, feel free to leave a comment below.