iOS Development with Xamarin Cookbook

We need to download all the necessary components on our computer. The first thing to do is register as an Apple developer on http://developer.apple.com. The registration is free and easy, and it provides access to all the necessary development resources. After the registration is confirmed through e-mail, we can login and download the iOS SDK from the address https://developer.apple.com/devcenter/ios/index.action#downloads. At the time of writing, Xcode's latest version is 5.0.1 and iOS SDK's latest version is 7.0.3.

To prepare our computer for iOS development, we need to download and install the necessary components in the following order:

Now that we have everything ready, let's see what each component is needed for.

Xcode

Xcode is Apple's IDE for developing applications for both iOS and Mac platforms. It is targeted on the Objective-C programming language, which is the main language to program in with the iOS SDK. Since Xamarin.iOS is an SDK for the C# language, one might ask what we would need it for. Apart from providing various tools for debugging iOS apps, Xcode provides us with the Organizer window. Shown in the following screenshot, we can use it to view a device's console logs, install and manage the necessary provisioning profiles, and even view the device's crash logs. To open the Organizer window, navigate to Window | Organizer on the menu bar, or press Cmd + Shift + 2 on the keyboard.

Applications developed with Xamarin.iOS have the same chances of making it to the App Store as all other applications developed with the native Objective-C programming language. This means that if an app does not conform to Apple's strict policy about app acceptance, it will fail, whether is written in Objective-C or C#. The Xamarin.iOS team has done a great job in creating an SDK that leaves the developer to worry only about the design and best practice of the code, and nothing else.

Now that we have all the prerequisites installed, we will discuss how to create our first iOS project with Xamarin Studio.

Start Xamarin Studio. It can be found in the Applications folder. Xamarin Studio's default project location is /Users/{yourusername}/Projects. If it does not exist on the hard disk, it will be created when we create out first project. If you want to change the folder, go to Xamarin Studio | Preferences from the menu bar. Select Load/Save in the pane on the left, enter the preferred location for the projects in the Default Solution location field, and click on OK.

The first thing that is loaded when starting Xamarin Studio is its start page. Perform the following steps to create an iOS project with Xamarin Studio:

That was it. You just created your first iPhone project. You can build and run it; iOS Simulator will start, with a blank light-gray screen nevertheless.

Let's see what goes on behind the scenes.

When Xamarin Studio creates a new iOS project, it creates a series of files. The solution files can be viewed in the Solution pad on the left side of Xamarin Studio window. If the Solution pad is not visible, it can be activated by checking on View | Pads | Solution from the menu bar.

The files shown in the following screenshot are the essential files that form an iPhone project:

using System;
using System.Drawing;
using MonoTouch.Foundation;
using MonoTouch.UIKit;

namespace MyFirstiOSProject
{
    public class MyFirstiOSProjectViewController : UIViewController
    {
        public MyFirstiOSProjectViewController () : base ("MyFirstiOSProjectViewController", null)
        {
        }

        public override void DidReceiveMemoryWarning ()
        {
            // Releases the view if it doesn't have a superview.base.DidReceiveMemoryWarning ();
            
            // Release any cached data, images, etc that aren't in use.
        }

        public override void ViewDidLoad ()
        {
            base.ViewDidLoad ();
            
            // Perform any additional setup after loading the view, typically from a nib.
        }
}
}

//
// This file has been generated automatically by MonoDevelop to store outlets and
// actions made in the Xcode designer. If it is removed, they will be lost.
// Manual changes to this file may not be handled correctly.
//
using MonoTouch.Foundation;

namespace MyFirstiOSProject
{
    [Register ("MyFirstiOSProjectViewController")]
    partial class MyFirstiOSProjectViewController
    {
        void ReleaseDesignerOutlets ()
        {
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using MonoTouch.Foundation;
using MonoTouch.UIKit;

namespace MyFirstiOSProject
{
    // The UIApplicationDelegate for the application. This classis responsible for launching the
    // User Interface of the application, as well as listening(and optionally responding) to
    // application events from iOS.
    [Register ("AppDelegate")]
    public partial class AppDelegate : UIApplicationDelegate
    {
        // class-level declarations
        UIWindow window;
        MyFirstiOSProjectViewController viewController;
        //
        // This method is invoked when the application has loaded and is ready to run. In this
        // method you should instantiate the window, load the UI into it and then make the window
        // visible.
        //
        // You have 17 seconds to return from this method, or iOS will terminate your application.
        //
        public override bool FinishedLaunching (UIApplication app,NSDictionary options)
        {
            window = new UIWindow (UIScreen.MainScreen.Bounds);
            
            viewController = new MyFirstiOSProjectViewController ();
            window.RootViewController = viewController;
            window.MakeKeyAndVisible ();
            
            return true;
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using MonoTouch.Foundation;
using MonoTouch.UIKit;

UIWindow window;MyFirstiOSProjectViewController viewController; 
//..
public override bool FinishedLaunching (UIApplication app, NSDictionary options) {

namespace MyFirstiOSProject
{
    public class Application
    {
        // This is the main entry point of the application.
        static void Main (string[] args)
        {
            // if you want to use a different Application Delegate class from "AppDelegate"
            // you can specify it here.
            UIApplication.Main (args, null, "AppDelegate");
        }
    }
}

Application.Run(new Form1());

Info.plist

The Info.plist file is basically the app's settings file. It has a simple structure of properties with values that define various settings for an iOS app, such as the orientations it supports, its icons, supported iOS versions, what devices it can be installed on, and so on. If we double-click on this file in Xamarin Studio, it will open in the embedded editor specifically designed for this file. Our file in a new project looks like the following screenshot:

We can also access Info.plist through the project's options window under iOS Application.

Xamarin Studio provides many different project templates for developing iOS apps. Here is a list that describes what each project template is for:

These templates are available for the iPhone, iPad, and Universal (both iPhone and iPad) projects. They are also available in Interface Builder's storyboarding app design.

Let's take a look at Interface Builder by performing the following steps:

Now that we have loaded Interface Builder with the view controller of our app, let's familiarize ourselves with it.

The user interface designer is directly connected to an Xcode project. When we add an object, Xcode automatically generates code to reflect the change we made. Xamarin Studio takes care of this for us, so that when we double-click on an XIB file, it automatically creates a temporary Xcode project. This allows us to make the changes we want in the user interface. Therefore, we have nothing more to do than just design the user interface for our app.

Interface Builder is divided into three areas. A brief description of each area is given as follows:

We saw what an XIB file looks like in Interface Builder, but there is more as far as these files are concerned. We mentioned earlier that XIB files are XML files with appropriate information readable by Interface Builder. The thing is that when a compilation is done in a project, the compiler compiles the XIB file converting it to its binary equivalent, the NIB file. Both XIB and NIB files contain the same information. The only difference between them is that XIB files are in a human-readable form while the NIB files are not. For example, when we compile the project we created, the MyFirstiOSProjectViewController.xib file will become MyFirstiOSProjectViewController.nib in the output folder. Apart from the binary conversion, the compiler also performs a compression on NIB files. So, NIB files will be significantly smaller in size than XIB files.

That's not all about XIB files. The way a developer manages the XIB files in a project is very important in an app's performance and stability. It is better to have many small-sized XIB files, instead of one or two large ones. This is because of the way iOS manages its memory. This can be accomplished by dividing the user interface into many XIB files. It may seem a bit difficult, but as we'll see later in this book, it is actually very easy.

When an app starts, iOS loads the NIB files as a whole in memory, and all the objects in it are instantiated. So, it is a waste of memory to keep objects in NIB files that are not always going to be used. Also, remember that you are developing for a mobile device whose available resources are not a match against that of desktop computers, no matter what its capabilities are.

As of iOS 5, Apple introduced storyboarding, which simplifies user interface design.

Let's add a few controls in an interface. Start by creating a new iPhone single view application project in Xamarin Studio. Name the project ButtonInput. When it opens, double-click on ButtonInputViewController.xib in the Solution pad to open it with Interface Builder.

Now that we have a new project, and Interface Builder has opened the ButtonInputViewController.xib file, we'll add some controls to it.

As you can see, although some concepts of Interface Builder seem difficult, it is quite easy to use. It also provides a lot of feedback. When we drag objects, guidelines that basically act as snap points for positioning the control properly, appear. Also, when we resize a control, we see its dimensions next to it.

You can also resize and position the controls by modifying the values in the Size tab of the Inspector pane. Another useful feature in the Size tab is Autosizing. Autosizing provides layout options for the controls, and it can be very useful when we want our app to support different device orientations. You can select a control you want, and then click on the lines that are outside or inside of the square on the left in the Autosizing section. The image next to it animates to give you an impression of how the control will behave when the layout changes.

Now, let's try running the app on iOS Simulator. Back in Xamarin Studio, select the project configuration Debug if it is not already selected. Depending on the version of iOS SDK you have installed, the following screenshot shows the available options of debugging targets:

Select your preferred target and click on the Run button. When the compilation finishes, iOS Simulator will automatically start and run the app we just created. You can even tap on Button by clicking on it with the mouse, and see it responding. Of course, our app does not have any other functionality right now.

In the previous recipe, we learned how to add controls to form a basic interface for our app. In this recipe, we will discuss how to access and use these controls in our code. Launch Xamarin Studio and open the project ButtonInput we created earlier. Open the project's ButtonInputViewController.xib in Interface Builder by double-clicking on it in the Solution pad.

Perform the following steps to access the UI with Outlets:

That was it! Our app is now ready with functional controls. Compile and run it on the simulator. See the label changing its text when you tap on the button.

The Outlet mechanism is basically a way of connecting Interface Builder objects with the code. It is necessary since it is the only way we can access user interface objects that we create with Interface Builder. This is how Interface Builder works, and it is not just a Xamarin.iOS workaround. An Outlet of an object provides a variable of this object so that we will be able to use it in a project. Xamarin.iOS makes a developer's life much easier because when we create Outlets in Interface Builder and connect them, Xamarin Studio works in the background by autogenerating code regarding these Outlets. This is what the ButtonInputViewController.designer.cs file has added to provide us access to the controls we created:

[Outlet]
MonoTouch.UIKit.UILabel labelStatus { get; set; }

[Outlet]
MonoTouch.UIKit.UIButton buttonTap { get; set; }

These are the properties which provide us access to the controls. They are decorated with the Outlet attribute. You can see that the names of the properties are exactly the same names we entered for our Outlets. This is very important since we only have to provide names once for the Outlets, and we do not have to worry about repeating the same naming conventions in different parts of our code. Also, notice that the types of variables of the controls are exactly the same as the types of controls we dragged-and-dropped in our user interface. This information is stored in the XIB file, and Xamarin Studio reads this information accordingly.

To remove Outlets, you first have to disconnect them. For example, to remove the buttonTap Outlet, press Ctrl and click on the button. In the panel that will appear, click on the x button next to the Outlet, as shown in the following screenshot. This will disconnect the Outlet.

After this, delete the following code from the Objective-C source file:

@property (retain, nonatomic) IBOutlet UIButton *buttonTap;

When you save the document, the Outlet will be removed from the Xamarin Studio project.

Adding Outlets through code

Another way of adding Outlets is to create a property in your C# class and decorate it with the Outlet attribute:

[Outlet]
UIButton ButtonTap { get;	set; }

When you open the XIB file in Interface Builder, the Outlet will be added to the user interface. However, you would still have to connect it to the corresponding control. The easiest way to do this is to press Ctrl, click on the control the Outlet corresponds to, and click-and-drag from New Referencing Outlet to the File's Owner object on the left of the designer area, as shown in the following screenshot:

When you release the cursor, select the ButtonTap Outlet from the small context menu that will appear.

Note

Note that it is Xamarin Studio that monitors for changes made in Interface Builder, and not the other way around. When making changes in the Xamarin project, make sure to always open the XIB file from Xamarin Studio.

In this recipe, we will discuss how to use Actions with the controls of the user interface.

Adding Actions to interface objects is similar to adding Outlets, as follows:

The app is ready! Compile and run it in the simulator. Tap on the button and see the text in the label change, just like in the previous app we created.

Actions in Objective-C are the equivalent of control events in C#. They are responsible for delivering notification signals of various objects. In this example, instead of hooking up a handler on the TouchUpInside event of the button, we have added an action for it. As you may already have noticed, the method we added to act as a handler for the action was declared as partial; this is because Xamarin Studio already declared a partial method declaration for us. This is the code that was produced when we saved the document in Interface Builder:

[Action ("OnButtonTap:")]
partial void OnButtonTap (MonoTouch.Foundation.NSObject sender);

The partial declaration of the method is marked with the Action attribute. This is another attribute from the MonoTouch.Foundation namespace that allows us to expose methods as Objective-C Actions. You see that the string parameter passed in the attribute is exactly the same as the action name we entered in Interface Builder, with only an appended colon (:) to it.

The colon at the end of the action name indicates that there is one parameter, in this case, the parameter MonoTouch.Foundation.NSObject sender. This is what our app looks like when we have tapped on the button in the simulator:

The example in the preceding section was created just to show how to implement actions in Xamarin.iOS projects. Replacing an event with an action is basically at the discretion of the developer.

Xamarin Studio provides many different options for compiling. In this recipe, we will discuss these options. We will be working with the project ButtonInput we created earlier in this chapter.

Perform the following steps to compile an iOS project with Xamarin.iOS:

We have set up some options for our project. Let's see what these options provide for compilation customization:

There are two more option windows. These are iOS Bundle Signing and iOS IPA Options. They will be discussed thoroughly in the recipes in Chapter 14, Deploying.

Xamarin.iOS, in combination with Xamarin Studio, provides a debugger for debugging apps either on the simulator or on the device. In this recipe, we'll see how to use the debugger for debugging Xamarin.iOS apps. Open Xamarin Studio and load the ButtonInput project. Make sure to set the project configuration to Debug | iPhone.

Perform the following steps to debug your application:

The debugger that is used is called soft debugger. It is called so because it depends on both the runtime and Xamarin Studio, combined to provide one unified debugging platform. When the debugging process starts, Xamarin Studio begins listening for debugging information from the app. The same applies for debugging on both the simulator and the device. When the app executes, it starts sending information back to Xamarin Studio. It then displays that information in the Application Output pad, which is automatically activated. A typical application output when debugging is the information on the assemblies that are loaded, the threads that begin execution, and the breakpoints, if any, that are available.

The Console.WriteLine() method can also be used for debugging purposes. The debugger takes care of this and redirects the output of the method to Xamarin Studio's Application Output pad.