One of the biggest issues facing any modern development project is the number of endpoints that need to be targeted.
Not long ago all we needed was a Windows Forms app, a set of Web pages, and maybe some WAP if we were feeling ambitious. Then along came mobile apps, and suddenly we had to produce native endpoint code for iPhones, iPads, Windows Phones, Android phones, and so on -- an explosion of code and an ever-growing collection of development tools.
Native applications are fast and efficient, and they access key device features in a way that’s impossible for Web apps. But if you’re building an application in C# for Windows devices, in Objective-C for iOS, and in Java for Android, there’s very little you can share among the different versions of your code, apart from graphical assets.
True, you could build a hybrid HTML5 app using tools like Apache Cordova, wrapping HTML and JavaScript in a native runtime. But there’s an alternative approach: Xamarin’s cross-platform native development tooling, which builds on the open source Mono implementation of Microsoft’s .Net framework.
Using Mono and the now open .Net, Xamarin is able to deliver a cross-platform development environment that uses either its own IDE or a Visual Studio plug-in. Code is written in either C# or F# and can be quickly shared across applications with support for Microsoft’s portable class libraries.
Building code using Xamarin’s tooling is much like building any application in any development environment. You write code, then compile and deliver it to test devices before deployment. You don’t even need to have a full set of test hardware: One advantage of Xamarin’s platform is its cloud-hosted test service, which lets you debug code running on devices hosted by Xamarin. With more than 2,000 devices currently in the Test Cloud, you’re likely to find your target device and OS combination ready to run. Calabash, an automated test framework, handles your applications, acting exactly like a user, and with access to low-level device features.
With Test Cloud, you can build device testing into your build process, integrating it into tools like Jenkins. Test reports include performance data, so you can compare different test runs to see the effects of changes in your code.
There’s a lot to be said for Xamarin’s original approach to user experience. You can write your core business logic in C# -- then drop out into native development tools to build the application UI using native UI components. An iOS app will look like an iOS app, sharing the bulk of its code with an Android app that looks like an Android app (Xamarin suggests you’ll get around 75 percent code reuse across versions). You’ll still need platform-specific skills, but only for building the UI. Design tools are built into the Visual Studio plug-in and into the stand-alone Xamarin Studio.
The recent release of Xamarin Forms simplifies development significantly. If you’re not building a complex, custom user experience, you no longer need to build a completely native UI. Instead, Xamarin Forms map common UI components to their native counterparts. The same code running on an iPhone, an Android device, or a Windows Phone will look very different on each platform, giving users a familiar look-and-feel without moving outside the familiar C# and XAML world.
If you’re bringing Windows developers into a cross-platform project, then Xamarin Forms make a lot of sense. There’s nothing new to learn, so you’ll deliver code faster. As developers become more familiar with Xamarin and its native UI tooling, it’s easy to mix and match Xamarin Forms with native components. In practice, though, you’ll find that Xamarin provides most of the UI components you’re going to need, from pages and layouts to a selection of standard controls. There are even third-party controls that can be used alongside the defaults.
You still get the option of using Xamarin’s native code features where you need to access services that can’t be used through Forms. Not every bit of functionality maps from platform to platform, so you will always be working with the lowest common denominator in Xamarin Forms. Even so, you’ll be able to build a well-designed, usable application with substantially more code reuse (if not all!).
As more and more applications take advantage of cloud back-end services, using a language that supports asynchronous operations becomes increasingly important. Xamarin includes full support for the async and await keywords in C#, letting you quickly take existing calls and using them to work asynchronously. All you need to do is write your methods as normal, treating them as promises that will eventually deliver results. If an asynchronous method is blocked, it can hand back control to the calling method, allowing work that doesn’t depend on the asynchronous call to continue while the system waits for a response.
It’s easy to get started with Xamarin’s tooling. A free starter edition introduces the basic concepts and lets you build simple, small applications that can be used to try out ideas before you invest in one of the more fully featured subscription services. Some features, like integration with Visual Studio, require higher tiers, though all get to use Xamarin’s own cross-platform Studio IDE.
The result is a set of tools and services that are familiar, at least to .Net developers, and that really deliver on the promise of cross-platform development. Having to develop separate UIs for different platforms is a small price to pay for a common codebase that’s easy to maintain and update.