Mobile Development with C#

An Alternative Approach

What I am going to propose is an alternative approach where you can leverage the power of the .NET Framework, along with the powerful C# language, across all three platforms. While this may sound similar to “write once, run anywhere,” the key difference is that C# and the Base Class Libraries are used as a universal language and library where the device-specific and user interface-specific elements are not abstracted, but are instead exposed to developers. This means that developers build native applications using three different user interface programming models, one for each platform, while using C# across the board.

As mentioned earlier, .NET is exposed natively on Windows Phone, so there’s no friction there. However, we know that on both iOS and Android it is not, so how can we make this work? To help bridge this gap, a company named Xamarin has created two products, MonoTouch and Mono for Android. We will explore these products in more depth in later chapters, but the elevator pitch is that they allow for writing native applications in C# (see Table 1-2), providing bindings to the platform’s native libraries and toolkits so that you’re targeting the same classes you would in Objective-C for iOS or Java for Android. Because you’re working against the platform’s native user interface toolkits, you don’t need to worry about how to make your application look and feel native to the platform, since it already is.

Table 1-2. Native platform languages with Mono tools

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

Note

Apple is known for being strict about what gets into the App Store, so you might be wondering whether it will only accept applications written natively in Objective-C. There are actually thousands of MonoTouch applications in the store. In fact, iCircuit, a MonoTouch application, was shipped with their demo iPad 2 units that were sent out to stores.

As the names imply, MonoTouch and Mono for Android expose .NET on iOS and Android by leveraging Mono, an open-source, cross-platform implementation of the Common Language Infrastructure (CLI), an ISO standard that describes the virtual execution environment that is used by C#. Despite the fact that they are commercial products, both offer free evaluation versions that do not expire, and allow you to deploy to the iOS simulator or the Android emulator. There is no risk in taking them out for a spin. In the next chapter, we will explore how to get started with these tools, and build your first application along the way.

Note

Apple and Google release new versions regularly, so you might be wondering what that means for you if you’re using MonoTouch or Mono for Android. Generally, there is no waiting period here, as both products track the beta programs for iOS and Android. For example, MonoTouch typically releases the bindings for a new operating system within 24 hours of the official Apple release. In addition to the quick release cycle, Xamarin offers first-class support for its products, providing prompt responses through mailing lists and IRC, and maintaining thorough, user-friendly documentation. Even outside of Xamarin, the Mono community in general is very active and helpful as well. You can find information about the company and products at http://www.xamarin.com/.

If you’re already a .NET developer, you can immediately hit the ground running, still having the familiar namespaces and classes in the Base Class Library at your disposal. Since the Mono Framework is being used to run your code, you don’t need to worry about whether Objective-C or Java implements a particular C# feature you want to use. That means you get things like generics, LINQ to Objects, LINQ to XML, events, lambda expressions, reflection, garbage collection, thread pooling, and asynchronous programming features. Taking things even further, you can often leverage many existing third-party .NET libraries in your applications as well. You can turn your focus towards solving the business problem at hand instead of learning and fighting yet another set of new languages.

As great as this is, the bigger win with this approach is the ability to share a large percentage of your core application code across all platforms. The key to making the most out of this is to structure your applications in such a way that you extract your core business logic into a separate layer, independent of any particular user interface, and reference that across platforms. By doing so, each application essentially becomes a native user interface layer on top of that shared layer, so you get all the benefits of a native user experience without having to rewrite the application’s main functionality every time (see Table 1-3). In Chapter 3, we will explore some techniques available to help keep as much code as possible in this shared layer and maximize code reuse across platforms.

Table 1-3. Application layers

	iOS	Android	Windows Phone
Runtime	Mono	Mono	.NET
Business logic	C#	C#	C#
User interface	MonoTouch	Mono for Android	Silverlight

The classes and methods exposed by a framework make up what is referred to as its profile. The .NET profile exposed by both MonoTouch and Mono for Android is based on the Mono Mobile profile. The mobile profile is a version of the .NET 4.0 API that has some of the desktop and server features removed for the sake of running on small embedded devices, such as the System.Configuration namespace. This profile is very similar to the core of Silverlight, which is also a subset of the full .NET profile for the same reasons. Since Windows Phone is also based on Silverlight, there is a large amount of overlap between all three of these profiles, meaning that non-user interface code you write for one platform is very likely to be compatible with the other two.

Note

Technically, the Windows Phone platform supports developing applications using both the Silverlight and XNA frameworks. Since XNA is more suited for game development, this book will focus on building applications with Silverlight. By definition, games define their own user interfaces, so not all of the problems outlined earlier with regards to providing a quality cross-platform user experience will necessarily apply when developing games.

The MonoGame project provides an XNA 2D implementation that runs on both MonoTouch and Mono for Android. This is a third-party community project that is continuously evolving. More information about the MonoGame project can be found at http://github.com/mono/MonoGame.

In later chapters, we’ll explore various patterns and techniques to help maximize the amount of functionality that can go into the shared layer. After walking through the process of creating a simple application for iOS, Android, and Windows Phone, we’ll go through many of the common tasks you’ll want to perform in your applications, such as consuming data from the Internet, persisting data to the filesystem or a database, and accessing the device’s location information and mapping capabilities. As we go through these topics, we’ll discuss how you can achieve some code reusability there as well.

It’s also worth noting that since .NET is being used across the board, reusing code in this shared layer isn’t just limited to mobile applications, or even just Silverlight-based applications. Since the Silverlight profile is essentially a subset of the full .NET Framework, in addition to Silverlight for the web or desktop, the same code can be applied to applications written in ASP.NET, WPF, Windows Forms, or even a Windows 8 Metro application. Using Mono, you can also take your code onto Linux or even the Mac using MonoMac, which takes a similar approach to MonoTouch and Mono for Android. In the end, your code can follow you anywhere the .NET Framework goes. That’s pretty powerful.