Xamarin Review

In this post, we will be reviewing our experience with the Xamarin platform and IDE for building cross-platform (iOS and Android) applications, and the pros and cons we discovered while using the platform with its particular efficiencies and quirks.

*Note that this review is for a project we did in September when iOS 7 was about to launch, using Xamarin IDE version 4.0.11 and eventually doing a phase of maintenance using version 4.2.2.

App Background

We used Xamarin for a simple application that required 5-6 screens for displaying tabulated data and a form for user input. The application also involved a backend service hosted by Kinvey (as a mbaas), which received the user input and then would return a json object of results which we would then parse and create the views on the client side.

For the sake of reusing code as much as we could, we created a middle layer Datasource class that was pure C# and .NET, which communicated with the Kinvey backend and did most of the processing for making and receiving requests by handling authentication, serialization, url encoding, and asynchronous calls.

The Journey

For some context: I had never touched C# or .NET prior to this project, and my last run in with Java was back in high school. I also had not seriously developed for the Android platform at all or released an application (let alone manually codesign apk files), and I expected to have some challenges picking up and developing in C# as well as for Android.

All that said, overall, the experience of learning and building on Xamarin was relatively quick and easy considering I had to (re)learn two languages and two new platforms. There are plenty of tutorials and examples for C# online either on MSDN or StackOverflow, which helped greatly. Also, there were more targeted help resources on Xamarin’s developer portal in their Guides, Recipes, andSamples, that would help when I had an issue that was specific to Mono for iOS or say the C# port of ActionBarSherlock in Android. I can’t forget to mention that Android’s resources are all around and their official documentation and examples are great compared to what you sometimes get on the Apple Developer site.

As usual, it was random little quirks with the platform and small things that ended up being the larger bottlenecks for me on the greater timeline. For the large part, building up the UI and scaffolding up the application wasn’t a problem at all. The wrappers they have around everything are generally pretty intuitive and works just like you expect they would, with a few exceptions.

Here are some of the efficiencies and issues that we ran into during development that influenced our development time:

Efficiencies

Xamarin Studio’s autocompletion is amazing, or at least far superior to Xcode’s anyway. A nice feature is that it will search all properties and function calls on each capitalized word in camelcase (in context), so a search for “Normal” will get you “UIControlStateNormal” without you having to type the “UIControl…” part.

Xamarin and C# have some nifty features that make writing and hooking up handlers to events on objects incredibly easy and compact. For example, putting together a button click handler:

Android

			button = FindViewById<Button>(Resource.Id.emailButton);
			button.Click += (object sender, EventArgs e) =>
			{
				try {
					Intent intent = new Intent(Intent.ActionSend);
					intent.SetType(Constants.EmailType);
					intent.PutExtra(Intent.ExtraEmail, new string[] {Resources.GetString(Resource.String.AboutEmailAddress)});
					intent.PutExtra(Intent.ExtraSubject, Resources.GetString(Resource.String.AboutEmailSubject));
					intent.PutExtra(Intent.ExtraText, Resources.GetString(Resource.String.AboutEmailBody));
					StartActivity(intent);
				}
				catch (Exception ex) {
					Console.WriteLine(ex.Message);
					Toast.MakeText(this, Resources.GetString(Resource.String.ErrorEmail), ToastLength.Long).Show();
				}
			};

iOS

			button.TouchUpInside += (sender, e) =>
			{
				// Check to see if they can send mail
				if (MFMailComposeViewController.CanSendMail)
				{
					// Setup and present email composer
					MFMailComposeViewController vc = new MFMailComposeViewController {
						MailComposeDelegate = mailComposeDelegate
					};
					vc.SetToRecipients(new string[] {Constants.TextContactEmail});
					vc.SetSubject(Constants.TextContactEmailSubject);
					vc.SetMessageBody(Constants.TextContactEmailMessage, false);
					this.PresentViewController(vc, true, null);
				}
				else {	// Show error
					new UIAlertView(Constants.TextWarningTitle, Constants.TextErrorEmail, null, Constants.TextOkButton, null).Show();
				}
			};

In addition, Xamarin allows you to set up objects in a nice succinct manner. For example (iOS):

			UILabel label = new UILabel {
				Frame = new RectangleF( Constants.SizeUIMargin / 4, 0, 0, 0 )
				, BackgroundColor = UIColor.Clear
				, TextColor = UIColor.White
				, Font = UIFont.FromName(Constants.FontNameSubtitle, Constants.FontSizeSubtitle)
				, Text = data.ScreenSubtitle.ToUpper()
				, AdjustsFontSizeToFitWidth = true
				, MinimumScaleFactor = 0.5f
			};

When we were building our Datasource class, knowing that even this middle layer had to be cross-platform helped enforce a platform-agnostic approach and even more modularization in its implementation.

C#’s strongly typed language reduces the number of bugs, although also causes some frustration when I have to constantly cast enums to ints for use in iOS objects.

Xamarin has a number of free components that are supported by the community and Xamarin that make a number of normally tedious tasks relatively simple:

ActionBarSherlock Component to support the action bar in older versions of Android.
JSON.net for serialization and deserialization of json into C# objects.
System.Web.HttpUtility for url encoding and decoding of strings.

Xamarin also has a built-in visual UI editor for Android layouts that works pretty well, although with a little quirkiness. One of the biggest issues is that undoing structural changes in the layout hierarchy usually blows up in the visual editor.

Issues

Xamarin changed a lot of “getXXX()” function calls into direct properties on an object in both Android and iOS platforms, sometimes making things really confusing.

Xamarin’s website had incomplete documentation for a number of classes in their SDK, especially when it came to wrapper classes for system-level native functions. At the time, for whatever reason, do something as simple as getting the ‘CFBundleVersion’ just simply didn’t work and there wasn’t much documentation around it. This may be better now as the platform continues to mature and grow. For reference, I was trying to update the version number in the settings bundle for iOS:

			// Update version number - Does not work
			NSObject versionObject = NSBundle.MainBundle.ObjectForInfoDictionary("CFBundleVersion");
			if (versionObject != null) {
				NSUserDefaults.StandardUserDefaults.SetString(versionObject.ToString(), "version_preference");
			}

An interesting issue that came up on both platforms was that Xamarin’s compiler handled memory management rather aggressively, and certain conventional UI setups with reusable views would not work and crash the app because views would get destroyed too early. Specifically this happened with the UICollectionView and a reusable header view that had a button on it; when the button was clicked, it would dismiss the view, but then the view would crash because the button would go out of memory before the animation finished.

As mentioned earlier, Xamarin has an Android UI Editor, but it blows up when using undo/redo. Xamarin’s compiler also doesn’t warn or complain to you if you use certain classes that are not supported by your minimum OS version target, for example, using the Spacer layout object.

One problem that was unexpected was finding out that I could not pass any object I wanted in the bundle to an Android Intent. We built the iOS app first, where we passed C# custom JSON classes to the respective controllers from the Datasource. Due to this restriction in Android, we had to go back and rearchitect part of the iOS app to move the deserialization to another step that can be called at will, and we simply passed the pure json string to the Android intent instead.

For the iOS platform, the delegate pattern and categories don’t quite exist in Xamarin as they do on the native platform. Delegates are implemented as abstract classes in C# instead of interfaces, because interfaces don’t support optional methods. This changes the model slightly because proper implementation now usually involves making a private internal class that subclasses the “protocol class” instead. For more details, see the Xamarin guide.

Xamarin also requires Xcode to be installed on the machine to use Interface Builder, which is becoming more and more the Apple recommended standard.

Making and releasing an App Store build for Android and iOS turned out to be rather troublesome:

For Android, the IDE (v4.0.11) didn’t properly codesign the package. Turns out they were using the wrong hash algorithm at the time, although that seems to have been corrected by now in their documentation (after I let them know), and in their IDE. At the time, I had to manually create my own keystore, and then jarsign and zipalign it in command line. For your reference, make sure to use SHA1withRSA for the -sigalg when using the jarsigner.
For iOS, the IDE didn’t seem to integrate well with Xcode’s organizer and when I made an Archive with AppStore credentials for validation and upload, the Xamarin IDE couldn’t validate the build properly, and I had to switch to Xcode’s built-in organizer to manage the build and validate it. Strangely enough, there always seems to be an extra “failed validation” build that is made by Xamarin whenever I make an AppStore build, not sure why. Only through Xcode’s organizer was I able to finally validate and upload the final build to the store.

Wrapping Up

To wrap up this post: the general conclusion I came to was that Xamarin has use cases where it can be a better solution than building each app natively, especially with games or anything with heavy client-side or middle layer logic (physics engines, etc.); however, for the general app, you may be able to produce better quality and more scalable solutions by having dedicated developers to iOS and Android respectively instead.

Xamarin is still a maturing platform, and as it comes together and grows, I can certainly see it being the best cross-platform solution out there for app developers or firms who don’t have the expertise or resources to dedicate to each platform natively. Here’s my list of major advantages for developing with Xamarin or natively:

Xamarin

Code savings, especially in middle-layer logic that isn’t specific to a particular platform’s libraries. Great for say apps that require heavy client-side encryption / processing, physics / game engines, video or audio processing perhaps.
If you have someone who can comfortably develop in C# and has knowledge of one platform, picking up the other isn’t too difficult. Alternatively, if you have a developer who is well-versed in both Android and iOS, and can pick up C# pretty quick, that could save you in cost as well.
Performance is right on par with native implementations. Xamarin takes C# and compiles it to binaries that can be read on each platform, so the performance of applications doesn’t suffer whatsoever, or at least not in any way noticeable compared to native implementations.

Native

Xamarin is simply a wrapper around what Android and iOS provide, so it still requires an understanding of each platform. In that sense, using Xamarin means you will have to learn a second layer on top of what already exists, so if you have a native expert in Android or iOS, it may make more sense to go native.
Xamarin requires an extra annual cost, ranging from $300 to $2000, on top of what you’ll already have to pay to get a developer license to develop on the iOS and publish on the Google Play store. Note that this extra cost applies per platform, per developer. This can add up if you plan on having many people developing through Xamarin.

This sums up my review at this point. I’m certainly looking forward to some great things coming out of Xamarin, but its value-add does vary depending on the use case.

Filed under: Product Engineering | Topics: android, android app development, android development, developers, ide, iOS, iOS app development, ios development, platforms, xamarin