Mobile Development with C#

Write Once, Run Anywhere

iOS, Android, and Windows Phone, despite the fact that they are all mobile platforms, have very distinct ways of doing things and their own required languages in which to do them. iOS applications are written in Objective-C, while Android makes use of Java. Windows Phone leverages the .NET Framework, where the primary languages are C# and Visual Basic .NET. You can also use C and C++ on iOS and Android, but they are not currently supported on Windows Phone (see Table 1-1). As developers, we dread the idea of having to repeat all of our work three times in three different programming languages. Aside from the upfront overhead of doing the work three times, bug fixes found later on will also likely have to be fixed three times. For any non-trivial application, the technical debt can add up quickly, so the natural response is to seek out some sort of cross-platform solution to minimize the cost of building and maintaining applications for these devices.

Table 1-1. Native platform languages

	iOS	Android	Windows Phone
C / C++	X	X
Objective-C	X
Java		X
C#			X
Visual Basic .NET			X

The promise of a “write once, run anywhere” solution is nothing new in the development world. It tends to come around whenever there’s a need to publish applications on multiple platforms, whether on the desktop or on mobile devices. The mantra was originally coined by Sun when it was pushing for Java to be the unifying language for all platforms and devices. The concept is certainly not unique to Java, though, nor was that the first time such a solution was proposed.

It has a natural appeal to us as developers. Who wouldn’t want a silver bullet like that at our disposal? We could write everything once, get it just the way we want it, and then instantly be able to target users on all platforms. Unfortunately, things that seem too good to be true often are; there’s a reason why Java, over a decade and a half into its life, has yet to become the common language for developing cross-platform desktop applications. I think Nat Friedman, CEO of Xamarin, put it best in an interview he did on the .NET Rocks! podcast:

“‘Write once, run anywhere perfectly’ is a unicorn.”

Now, let me take a step back for just a moment to provide some clarification here. I don’t intend for anything in this chapter, or this book for that matter, to be taken as a slight against frameworks that decided to take this approach to solving the problem. The silver bullet trap works in both directions. No matter the context, there is never a solution so perfect that it solves all problems. Instead, what I will outline in this book is meant to demonstrate only one approach to solving things. It’s another set of tools for your developer tool belt.

Having said that, let’s take a moment to think about who stands to benefit the most from the “write once, run anywhere” method. You could make the argument that the user benefits from you being quicker to market or supporting his platform, and though there is some legitimacy to that, I would tend to disagree. Instead, when all is said and done, it is we, the developers, who really benefit by cutting down the amount of time it takes to write and publish our applications. However, this reduced development time often involves making concessions that sacrifice user experience. Each platform has its own hardware configurations, with varying screen sizes, resolutions, and buttons. Each has its own set of user interaction metaphors and guidelines for how an application should look and behave. In order for your application to look and feel native, it should act like the other applications on that platform.

Writing to the lowest common denominator can end up making your application feel foreign to all of them. Applications on Windows Phone are designed to look and behave differently than those on iOS, and that is something that should be embraced rather than glossed over or abstracted away. The experience you present to your users should be the primary concern when designing your application’s interface. Ultimately, that is what will set your application apart from others who take shortcuts along the way.

By now, you’re probably thinking to yourself, “So if I’m not writing in the platform’s native language, and I’m not leveraging one of these cross-platform frameworks, how do you expect me to write my applications?”