I recently decided to begin diving deeper into Xamarin for iOS. One of the big reasons I have focused so heavily on learning Objective-C and iOS is to ease this transition. I already possess very solid C# skills so the idea of being able to use C# over Objective-C and still create iOS apps was very appealing to me. However, I still felt that learning the patterns and paradigms of iOS would make it easier to use MonoTouch (the Xamarin product which allows iOS apps to be written using C#); this has proven true.

Xamarin applications are developed one of two ways: 1) through Visual Studio as a plugin or 2) using the Xamarin Studio development environment. In terms of the free trial you can only use Xamarin studio to develop iOS apps on Mac or use the Visual Studio plugin to develop Android apps on Windows. For this brief dive we will be focusing squarely on iOS development on the Mac.

You still need XCode

It doesn’t seem to matter who does what, we can’t get ride of Xcode (unless you build all views by hand).  It is no different with MonoTouch as it is still the easiest way to build the interface.  However, Xamarin does something pretty cool with this.  Open up your Storyboard file (double click) and it will launch Xcode.  Wireup the IBOutlets and IBActions as you would normally, however, notice the lack of a .m file.

Save the file and return to Xamarin studio and open your designer.cs file (below):

If you open this file you will see partial methods being used to bind the C# methods to the Objective-C methods they related to.  Here is a picture of mine as an example:

As with most files containing generated code you are not going to want to edit this file.  Instead you will want to define the actual implementations for these partial methods in the related class file (in my case GitHub.AppViewController), this is usually the file which the designer file is linked to.  Here is my implementation of sayHello.

You can see the usage of the AlertView class with the same name as its Objective-C counterpart.  This is done intentionally to ease the transition.  Notice in this case, I have defined the AlertView to use the PlainTextInput style which will give the popup a textfield for text entry (I am asking for the users name).

Feels like Android

Looking at the above code you notice that for the Delegate property I am assigning the variable _alertViewDelegate.  This class is of type MyAlertViewDelegate.  I am not sure the reason but the protocols for Objective-C were brought over as classes, instead of interfaces.  The Xamarin documentation recommends creating a subtype of any protocol you intend to implement.  This is not at all dissimilar from how Android developers approach this sort of situation with Adapters.

Here is the source code for MyAlertViewDelegate:

You can see the the constructor for this classes takes the ISayHello interface, this is so we have a way to call back to our view to update when the delegate method fires (very common paradigm in Android).  Notice the class declaration for the View Controller:

By doing this, I am able to assign this class to the delegate property of UIViewController so when the user presses the “OK” button the delegate method Dismissed is fired.  From that I can get the input the user provided and then call SayHello on the view controller because I know the class reference given to the constructor implements ISayHello which guarantees the method SayHello exists.  SayHello is defined in the view controller so it can then operate on associated views.

Note: The code I write here is demo code and not an example of production ready code.  It is rarely OK to have two methods with the same name in a class differentiated ONLY by their casing.

Some Closing Thoughts

Xamarin is a very nice platform that allows .NET developers to use their existing skills for popular mobile platforms.  With some basic understanding of iOS patterns and paradigms the transition is very easy and helpful.  You still need Xcode for interaction with storyboards and creating GUI elements (same as true when using AppCode from JetBrains) but I really like what Xamarin offers for those of us seeking to truly create unified code bases for all platforms (excluding view code)