Guide to Building iOS Applications with MonoTouch for the .NET/C# Developer

RELATED: "Build an iPad Application Using MonoTouch, C#, and .NET" and "Working with Images and Animation on the iPhone and iPad with .NET and C#: Part 1"

The Apple iPhone has taken the mobile world by storm since its original release in 2007. At that time, the only way to target the iPhonfie was either by writing a web application or by jailbreaking the phone. Neither was a good option. Writing a web application for the iPhone is not difficult, but it doesn't take advantage of the native capabilities of the device. Jailbreaking an iPhone relies on the owner of the device installing a piece of software that sidesteps the iPhone's security schemes and official distribution mechanisms. The process also raises several issues:

In 2008, Apple made it possible to run applications directly on the iPhone and introduced the App Store, opening the possibility of a development ecosystem that could target the device's capabilities. These capabilities include amazing graphics, sound, background processing, and other features that were, at that time, revolutionary in a mobile device. The iPhone is the leader of the smartphone pack in terms of integrating support for telephone service, apps, web access, and music in one consumer-friendly package.

How Do .NET Developers Fit into the Picture?

.NET developers, the largest set of developers in the general software development ecosystem, have looked at the iPhone with a high degree of envy. There are many stories about developers working a relatively short amount of time, submitting an application to the App Store, and quickly making hundreds of thousands of dollars. A recent report by the IT market research company Yankee Group states that sales of smartphone applications will increase from $343 million in 2009 to $4.3 billion in 2013.

In 2009, Novell announced a version of its Mono .NET-compatible open source development platform that's designed to run within the iPhone as a native application. This version of Mono, named MonoTouch, generated significant excitement within the .NET community. MonoTouch lets .NET developers take a portion of their existing development knowledge and use that to build applications that run on the iPhone. Although you can't take an existing .NET application and run that application on the iPhone, developers can apply their knowledge to building iPhone applications. I liken this to you, as an American, going to England and speaking the British dialect. You know the same basic language; but the accents, mannerisms, and certain terms are different.

When you build a MonoTouch application for the iPhone, you require a different set of tools:

Development Strategies

Several strategies are available for .NET developers to build applications for the iPhone. They are:

Web development by using ASP.NET. The iPhone is bundled together with the Safari web browser. The recent update to the iPhone/iOS 4.x OS provides iPhone users a mobile version of the Safari 4.x browser. Many .NET developers are working in ASP.NET. It is possible to build a web-based application in ASP.NET that directly targets the iPhone web browser. There are pros and cons to this strategy.

The major advantage is the deployment of new versions of the application. New versions are directly available to iPhone users the moment the deployment is made to a web server. There is no need to wait for an application to be accepted by the App Store and for users to download it. By making a web application directly available to users, the App Store can be bypassed. Developers can stay in their existing development environments and use the tools with which they are most familiar.

The major disadvantage is that a web application will have limited support for taking advantage of the app's native features. Whenever a user experiences a bad connection over the 3G network or loses a Wi-Fi connection, the user cannot load the full application. The Safari browser in the iPhone does offer offline support. But if the application does not take advantage of the offline features in the browser, the user is out of luck.

There are several levels to creating an ASP.NET application that targets the iPhone. At the basic compatible level, a web app is compatible with Safari on the iPhone. The next level is a web-optimized application to target Safari on the iPhone. An optimized app recognizes that it is running on Safari and can take advantage of Safari features when the browser is detected. Finally, a developer can build a web application that specifically targets Safari on the iPhone simply because Safari runs on the iPhone. However, this approach also requires the most development time of the options for ASP.NET web developers.

MonoDevelop and MonoTouch. When you develop by using MonoTouch, your primary tool will be MonoDevelop. MonoDevelop lets you build native applications that run on the iPhone.by applying your .NET development knowledge.

Visual Studio .NET and MonoDevelop. There is no getting around the requirement of using a Mac that has the iPhone SDK installed to deploy an application to the iPhone. At some point, the .NET developer must leave behind the Visual Studio development platform. A strategy for MonoTouch development is for developers to use Visual Studio for creating the non-UI of their applications, debug in Visual Studio, then use that code in their MonoTouch application. This strategy works well for reusing existing logic. This logic can be encapsulated into classes that can be carried over to MonoDevelop, recompiled, and deployed to the iPhone. There are several ways to handle this:

The only problem with this approach is that there’s a danger of implementing some code that is available in.NET but isn't available on the MonoTouch platform.

What Is MonoTouch?

The MonoTouch API is a combination of the .NET 3.5 Framework core features and the APIs on the iPhone. MonoTouch provides a bridge (interop) between the iPhone's native APIs, which are based on Objective-C and C-based APIs, to the .NET world to which C# developers are accustomed.

MonoTouch has the following components:

iPhone Requirements

iOS does not support just-in-time (JIT) compilation or the sharing of libraries between applications. The lack of support for JIT compilation occurs at the iPhone kernel level and is a technical limitation of the iPhone. This is a problem for .NET development. In .NET development, source code (VB, C#, or other languages) is compiled to Microsoft Intermediate Language (MSIL). After the executable is set to run on an actual system, the JIT process compiles the MSIL code into actual code that takes advantage of the hardware on which the code is running. The iOS also does not allow the sharing of libraries between different applications on the device. As developers almost certainly know, Apple is not shy about enforcement in regards to iOS, so developers must be vigilant to meet the company’s requirements.

MonoTouch meets these requirements by being a static compiler. MonoTouch emits executables that run as native applications. There is no JIT or scripting involved, so the contractual and technical requirements are met for running on the iPhone. MonoTouch does this by using the Mono Project's Ahead of Time compilation feature, which is beyond this general discussion.

MonoTouch does have several limitations, mostly centered on code limitations:

Using a Value type as a Dictionary Key can create issues. By default, a Dictionary constructor tries to use EqualityComparer.Default, which, in turn, uses Reflection to instantiate a new type.  This works for Reference types because the create step is not performed. For most value types, the creation is performed. The attempt at creation results in the error.

Additional limitations are listed at monotouch.net/Documentation/Limitations.

Namespaces and Classes

MonoTouch provides a rich set of namespaces and classes to support building applications for the iPhone. The most popular namespaces and classes are:

Introduction to Development on the Mac with MonoDevelop

Your process of building an application starts by using MonoDevelop, then running the application in the iPhone simulator, and finally deploying the application to an iPhone. MonoDevelop is the software development tool for Mono on the Mac. MonoDevelop is available for Windows, Mac OS, and several flavors of Linux; however, we will concentrate on MonoDevelop for the Mac.

MonoDevelop for the Mac is a new product. It was officially released with MonoDevelop 2.2. MonoDevelop is an IDE for developing by using Mono/.NET, C#, and other languages. MonoDevelop can be used to create iPhone applications, desktop applications, and web applications that use WebForms and the Model-View-Controller architecture. Currently, MonoDevelop is at version 2.4.

Because this is most likely the first time you are running MonoDevelop, I’ll explain the process in excruciating detail to address any questions that may arise. After you start MonoDevelop, create an iPhone application. To do this, point to New on the File menu, click Solution, and select an iPhone application to create. Figure 1 shows the process of creating an iPhone application.

Figure 1: Creating an iPhone application

By default, the new solution is displayed on the left side of MonoDevelop, as shown in Figure 2.

Figure 2: A newly created solution displayed in MonoDevelop

Figure 3 shows the MonoDevelop interface.

Figure 3: MonoDevelop Interface Builder design surface

The solution is displayed in addition to the following:

Interface Builder

Interface Builder is the development tool for creating the application interface (see Figure 3). When Interface Builder starts, a blank design surface is displayed. You can drag controls from the Library onto the design surface and arrange them to create the necessary UI. For Visual Studio developers, this is a familiar concept.

Outlets. The concept of outlets is particularly confusing for developers who are first learning about MonoTouch and building iPhone apps. This term is used throughout the Apple developer website and the MonoTouch website. An outlet is a private pointer to a UI object, and it’s visible only within the class in which it is defined.

After you arrange the controls on the design surface, you must define their outlets in the application delegate. To create the outlets, click the plus sign (+) button in the Outlets section of the App Delegate Connections window. This step is shown in Figure 4.

Figure 4: Creating outlets for the application delegate

Figure 5 shows the code for the MainWindow.designer.xib.cs file.

// ------------------------------------------------------------------------------// //   This code was generated by a tool.//   Mono Runtime Version: 2.0.50727.1433// //   Changes to this file may cause incorrect behavior and will be lost if //   the code is regenerated.// // ------------------------------------------------------------------------------namespace IntroToMonoTouch {// Base type probably should be MonoTouch.Foundation.NSObject or subclass[MonoTouch.Foundation.Register("AppDelegate")]public partial class AppDelegate {private MonoTouch.UIKit.UIWindow __mt_window;private MonoTouch.UIKit.UILabel __mt_TimesTouchedLabel;private MonoTouch.UIKit.UIButton __mt_TouchMeButton;#pragma warning disable 0169[MonoTouch.Foundation.Connect("window")]private MonoTouch.UIKit.UIWindow window {get {this.__mt_window = ((MonoTouch.UIKit.UIWindow)(this.GetNativeField("window")));return this.__mt_window;}set {this.__mt_window = value;this.SetNativeField("window", value);}}[MonoTouch.Foundation.Connect("TimesTouchedLabel")]private MonoTouch.UIKit.UILabel TimesTouchedLabel {get {this.__mt_TimesTouchedLabel = ((MonoTouch.UIKit.UILabel)(this.GetNativeField("TimesTouchedLabel")));return this.__mt_TimesTouchedLabel;}set {this.__mt_TimesTouchedLabel = value;this.SetNativeField("TimesTouchedLabel", value);}}[MonoTouch.Foundation.Connect("TouchMeButton")]private MonoTouch.UIKit.UIButton TouchMeButton {get {this.__mt_TouchMeButton = ((MonoTouch.UIKit.UIButton)(this.GetNativeField("TouchMeButton")));return this.__mt_TouchMeButton;}set {this.__mt_TouchMeButton = value;this.SetNativeField("TouchMeButton", value);}}}}

There are a couple of interesting items to note in the code:

Now that the basics of the application are set up, you can get down to writing the application logic. Figure 6 shows the code for the Main.cs file.

using System;using System.Collections.Generic;using System.Linq;using MonoTouch.Foundation;using MonoTouch.UIKit;namespace IntroToMonoTouch{public class Application{static void Main (string[] args){UIApplication.Main (args);}}// The name AppDelegate is referenced in the MainWindow.xib file.public partial class AppDelegate : UIApplicationDelegate{private Int32 count = 0;private string TouchString = "{0} Times Clicked";// This method is invoked when the application has loaded its UI and its ready to runpublic override bool FinishedLaunching (UIApplication app, NSDictionary options){// If you have defined a view, add it here:// window.AddSubview (navigationController.View);TouchMeButton.TouchUpInside += HandleTouchMeButtonTouchUpInside;TimesTouchedLabel.Text = String.Empty;window.MakeKeyAndVisible ();return true;}void HandleTouchMeButtonTouchUpInside (object sender, EventArgs e){count++;TimesTouchedLabel.Text = String.Format(TouchString, count);}public override void DidEnterBackground (UIApplication application){}public override void WillEnterForeground (UIApplication application){}public override void ReceiveMemoryWarning (UIApplication application){}// This method is required in iPhoneOS 3.0public override void OnActivated (UIApplication application){}}}

In the Main.cs code, the AppDelegate class is a partial class. This lets it be compiled together with the connections as created in Interface Builder. By compiling the separate .cs file definitions together, the resulting code runs as if it were originally from the same file. This lets multiple programs (Interface Builder and MonoDevelop, in this case) have the responsibility of file and code management without the possibility of the programs easily writing over each other.

The AppDelegate class inherits from the UIApplicationDelegate class. The UIApplicationDelegate defines methods that are called by the UIApplication singleton that is created by a running application.

The methods that Figure 6 shows are as follows:

Thankfully, MonoDevelop provides IntelliSense support in MonoDevelop. Figure 7 shows IntelliSense support for a button.

Figure 7: IntelliSense support for a button in MonoDevelop

Actions. Now that a UI is created, the application has to be able to respond to user events. For those familiar with Visual Studio, creating actions (also known as “handling events” in the Windows world) is a fairly easy concept. For a button in a WinForm or in a WebForm, double-clicking the button causes the following to occur: An event is defined in the control (WebForm) or in the Designer.cs file (WinForm), the source file opens, and the editor takes you to the click event. You can then add code to that event to perform whatever functionality is required. There is a similar, somewhat more manual process for doing this in MonoDevelop by using MonoTouch.

Creating outlets made the UI controls available to you and also available within the AppDelegate class. MonoDevelop allows the handling of user events; however, this is a manual process. To handle user events, open the Main.cs file and go to the FinishedLaunching() method within the AppDelegate class. To set up the touchdown event on a button (roughly the equivalent of a click event on a button in WinForms), add an event to the control's TouchDown property.

After you create the control event, you can build the application and deploy it to the simulator by pressing Command+B to build the application or Command+Enter to compile and deploy. Alternatively, you can click Build Menu, then click Run on the MonoDevelop menus. After the application is deployed to the simulator, you see a window that resembles the window in Figure 8.

Figure 8: The window you see after deploying an app to the MonoDevelop simulator

Deploying to an iPhone

Now that an application has been created and tested in the simulator, it's time to deploy and test the application on an actual device. This is a fairly short process, but it can be confusing. The key pieces of the process are as follows:

Figure 9: Setting up the MonoDevelop project to deploy an application to the iPhone

Apple provides the following resources for setting up the certificates and deployment setup for Mac developers. To access these resources, you must be a member of the Apple iPhone Developer Program.

To properly deploy an application to a local computer during development, the iPhone must be running an OS version that’s compatible with the iPhone SDK installed on your Mac. The OS version of the directly connected iPhone cannot be newer than the SDK version. For example, the deployment will work if the iPhone OS version is 4.0 and the SDK version is 4.2, but it will fail if the iPhone OS version is 4.2 and the SDK version is 4.0. If you are working with incompatible OS versions, you must upgrade the SDK on the development computer to a more recent version that supports the OS version of the connected iPhone.

Using the SearchBar

Now that we've looked at MonoTouch, MonoDevelop, and development for the iPhone for .NET developers, I wanted to give you one final short example in which we'll use the iPhone's SearchBar. Although search data is typically used to perform some type of search, in this example the code will use the user input value from the SearchBar to populate a label.

To get this functionality to work, put a SearchBar into a Window in Interface Builder, and create an outlet. Save the outlet, and add the following lines of code to the FinishedLaunching method:

search.OnEditingStopped += HandleSearchOnEditingStopped;search.OnEditingStarted += HandleSearchOnEditingStarted;

The two event handlers are then defined as shown in Figure 10, and Figure 11 shows the output of this code. From a .NET standpoint, these are commands that make sense and that are easily understandable.

void HandleSearchOnEditingStarted (object sender, EventArgs e){//perform some search.search.ShowsCancelButton = true;}void HandleSearchOnEditingStopped (object sender, EventArgs e){//do something on the final search.output.Text = search.Text;search.ShowsCancelButton = false;}

Figure 11: Output from the SearchBar event handlers executable code

Expanded Opportunities

By using MonoTouch, .NET developers can now take their skills to the iPhone and iPad. I hope that this short look at MonoTouch and MonoDevelop motivates you to get started developing for these products. Considering the number of Apple devices in use and the potential income that they represent, you should definitely take a look at developing for such a large market. In fact, there’s no excuse not to look at developing for iPhone and iPad devices. And please stay in touch with me as you progress! I want to hear about the apps that you create.

Wallace B. "Wally" McClure ([email protected]) is a Microsoft MVP, ASPInsider, member of the national INETA Speakers Bureau, author of seven programming books (including two about MonoTouch), and a partner in Scalable Development. Currently, Wally is in the final stages of writing an Android programming book. He blogs at www.morewally.com and co-hosts the ASP.NET Podcast.