In my first publish post I gave a very high level overview of what Xamarin is and what it isn’t. I then followed up with a post describing the nuts & bolts of Xamarin.iOS. In this article, I’ll be describing the nuts & bolts of Xamarin.Android. And as I started in my previous two posts, I think it is essential to understand what Xamarin.Android is, how it is compiled, and how it executes on your Android device. Though it is easy to jump right in and start coding, I believe it is essential to understand Xamarin.Android fundamentals, as well as the Android operating system fundamentals. In the long run, this will be beneficial when you have to start debugging your apps. It will also help you troubleshoot issues an understand what is happening between the Android operating system, Xamarin.Android, and your own code.
In the earlier days of Xamarin.iOS development (up to iOS 7), one of the more useful recipes from the Xamarin Documentation was the ActionSheet Date Picker. Adding a DatePicker as a subview of a
UIActionSheet was a very convenient way to display a DatePicker to the user. The Action Sheet would behave as it usually would, and you could modify it to slide from the bottom and only take up the bottom portion of the screen. After the user selects the date and taps on “Done”, the ActionSheet would then slide back down. Because of the behavior of the ActionSheet, this was a great way to provide a Modal Date Picker. However, this recipe no longer works on iOS 8 due to “misuse” of the
UIActionSheet. I created an alternative, with full source code and sample app that replaces the ActionSheet Date Picker that is free to use.
In my previous post I gave a very high level overview of what Xamarin is and what Xamarin is not. Though my post was more conversational and explained by example, I left out the technical details. In this post, I’m going to focus on the nuts & bolts of Xamarin.iOS. But before we start off coding a sample application, it is (in my opinion) essential to understand what Xamarin.iOS is, how it is compiled, and how it executes on your iOS device. Though it is easy to jump right in and start coding, I believe it is essential to understand the Xamarin.iOS fundamentals, as well as the iOS operating system fundamentals. In the long run, this will be beneficial when you have to start debugging your apps. It will also help you troubleshoot issues and understand what is happening between the iOS operating system, Xamarin.iOS, and your own code.
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.