Monthly Archives: September 2012

Semantic Zoom in iOS

One of the exiting new developer opportunities in Windows 8, is the semantic zoom UI design pattern.

As outlined in the Guidelines for Semantic Zoom,

Semantic Zoom is a touch-optimized technique used by Windows Store apps in Windows 8 for presenting and navigating large sets of related data or content within a single view …

To further borrow from the guidelines, this is what a Messages application could look like:

Now, if we were to do something similar in an iOS-app, we could do something like this:

  1. Create a UIViewController whose View is a UIScrollView.
  2. Configure the scroll view with a small zoom threshold, letting the zoom events swap views.

Not so bad, huh? Let’s start with creating a new Solution in MonoDevelop:

As stated in our checklist above, we will start out by creating a root view controller that inherits UIViewController and whose View is a UIScrollView. First up: Creating the controller:

To set the ViewController’s view to a UIScrollView, double-click on the SemanticZoomViewController.xib file it in your Solution Pad to open it in Xcode and then head over to the Identity inspector to set its class to UIScrollView:

Having done that, we can return to MonoDevelop to create our example views. We need an overview and a details view. Now, these views are to here to illustrate this example, so I won’t go into details on them (and, in all honestly, they don’t do much). Let’s start with the overview:

Add -> New File -> iPad View Controller -> OverviewViewController:

Add -> New File -> iPad View Controller -> DetailViewController:

With our SemanticZoomViewController and our two child controllers, we can start binding them together. Returning to MonoDevelop, let us open the SemanticViewController and add a few private fields:


Then, with our fields in place, we can do our magic in the ViewDidLoad method:




The code in ViewDidLoad uses a few helper methods to get its job done:



Now, to swap in the new view, we bring it to front, reset its zoom scale (since we don’t want optical zoom) and animate its opacity to get a nice fade-in effect:


And that, my friends, is all that is to it.

For a quick demonstration, see my Youtube clip:


Book review: Professional iPhone Programming with MonoTouch and .NET/C#

The Professional iPhone Programming with MonoTouch and .NET/C# book, which was first released in 2010, is an excellent starting point for .NET developers wanting to wrap their head around the iOS-stack and really getting started with MonoTouch development.

To quote its introduction,

This book is for .NET developers that are interested in creating native iPhone applications written in .NET/C# … [and] is designed to help you get up to speed with the iPhone, not to really teach you about the .NET Framework or C# language, which we assume you already know.

Since the book presumes that you already know your .NET and C#, it quickly gets you where you want to be, starting you off with a brief product comparison (.NET Framework, Mono and MonoTouch), followed by a walk-through of MonoTouch’s major components and its top-level namespaces.

Chapter 2 introduces you to your prerequisites to start developing, i.e. which SDK:s you need to install in what order, an introduction to MonoDevelop and to Xcode. Now, seeing as the book is a couple of years old by now, you wouldn’t recognise yourself in Xcode (Interface Builder) after reading the introductory chapter. The concepts are the same, though, and the book does a very good job staying on such an altitude that I still feel that its a good read. After you’ve read the introductory chapter, you can supplement your newly acquired knowledge by reading my blog post on XCode and MonoDevelop from a Visual Studio developer’s point of view to get up to speed.

The succeeding two chapters deal with the iOS interfaces, patterns and controls in a digestible manner, showing a lot of code and its result. That goes to say for the entire book, really – it contains a near perfect mix of imagery and code, letting you enjoy the book even when you are far away from your computer. I read this book whilst away on vacation and felt that I learnt a lot without coding a single example during the length of the book.

Chapters 5 and 6 walks us through working with, and displaying, data, teaching us how to access the SQLite database system on the iPhone, connecting to various types of web services and then displaying this data in iPhone’s ubiquitous tables. Here, the author also brings up various strategies for upgrading your data storage during upgrades of your application.

After learning to work with data, chapter 7 introduces us to both iOS’ location and mapping libraries, followed by chapters on application settings, working with the device hardware and its multimedia capabilities.

Chapter 11 teaches us how to integrate with the existing software – such as initiating Skype calls – on the device and also how to integrate with third-party Objective-C libraries (yeah, MonoTouch allows you to do that too!).

Localizing for an International Audience (chapter 11), I found extra interesting as I had recently implemented localization into a Windows Phone 7 application framework and because localization is something often brought up in Sweden, where I live. Not only just showing off the available APIs, this chapter discusses the localization files’ format, various presentation concerns when internationalizing an application and how to utilize .NET’s excellent globalization features to format dates, times, numbers and currencies. After reading this chapter, I got inspired to create a translation community where developers everywhere to help each other localize their apps, simply by crowd-sourcing their localization files. The community is available at

In chapter 13, the book brings up device concerns and which extra controls are available when you are targeting the iPad. It also details how to interpret gestures and how to build an app that works on both the iPhone and the iPad (an universal app).

By this point, the authors hope that you are so comfortable with them, that you will not instantly push the book away on the thought of talking about Objective-C. Thus, chapter 14 attempts to give you just enough knowledge about the native programming APIs to be able to digest code examples found on the internet.

As you have fought your way through chapter 14, the final chapter of the book teaches you all about how the App Store works, and how you submit your apps to it. As a bonus feature, it also brings up how to promote your app, leaving your with a sense completeness.


I found the book very approachable and a good start for any .NET developer wanting to learn iOS development. It’s almost-perfect balance of descriptive text, code-examples and imagery explaining the concepts, makes it ideal to read away from your computer – for example when you commute, or on your vacation!

XCode and MonoDevelop from a Visual Studio developer’s point of view

(This article pertains to Xcode 4 and MonoTouch 5)

Starting Mono development can be challenging on many levels. One of these levels, is wrapping your head around each platform’s different user interface design paradigms: Whereas the Visual Studio developer will be used to UserControls and MVVM templates and bindings, User Interface is done slightly different in the Xcode world, which the MonoTouch framework integrates into.

Development on Macs has been done using the Model-View-Controller pattern since the early 80s. As such, when you are developing an iOS application using MonoTouch, you are generally compositing Controllers together. In the example below, we have a mapping application that consists of three significant views: The map itself, the settings dialog and the details dialog. As such, we compose the application of three view controllers:

  • UINavigationController (more on this later)
    • MapViewController
    • SettingsViewController
    • DetailsViewController
Main/Default View of the App
Settings dialog
Details view

Each ViewController is first created in MonoTouch, whereafter its XIB-file is opened in Interface Builder (simply by double-clicking it in the project listing).

MonoDevelop - Add - New File
New File Window

Now, here is where things get scary, if you are a Visual Studio developer!

Things are getting scary ...

Being presented to us, is a sheet onto which we can define views. The UIViewController we created from MonoDeveloper has a View property, which are represented as the iPhoneish rectangle. Now, as a Visual Studio developer, you might be tempted to drop some UserControls (there’s an Objects-library-thing at the bottom right that looks like Controls), double-click them and act on their default events. Not so in Xcode. Where it is true that the Objects-library-thing at the bottom right is in fact a library, it’s a library of Views. As such, we have to work with them a little differently. Let’s start by placing a map onto our view (it’s a MapView we’re building, after all): In the bottom-right, start typing map and see how the library finds your view for you:

Click-and-drag that view onto your view until and adjust its size as needed. Having a map in its place, we can start changing its attributes. Let’s have it show the user’s current location! To get to what we would think of as the property sheet, we first click the view we would like to modify (to focus it), and then lift our gaze to the top-right of the Xcode window, where we find the Inspectors panel.

In this panel, we click on the Attributes inspector to change this particular setting:

Alright! Let’s see where we are at! Switching back to MonoDevelop, we notice how it gets busy updating itself on our changes in Xcode (progress bar in the bottom-left). After MonoDevelop has completed that process, we can continue to wire-in our new ViewController by instantiating it in our AppDelegate:

When that is done, start your app by pressing CMD and ENTER and see that it happily starts, asks for permission to track you, and then show your location on the map:

Now, since we are running in the simulator, iOS has automatically teleported us to California! Yay us! On device, however, we are left where we started. Perhaps teleporting will work in a future version.

If you compare the picture above with the one earlier in this article, you will notice a few differences. For one, we are zoomed out something fierce! Second off, we don’t have any navigation controls. Let’s work on that first issue as it introduces us to several new concepts.

To zoom in on the user’s location, we need to manipulate the map during runtime. And to do that, we need a reference to it! Again, in Visual Studio, we would presume that the map was a property of the view that we created and thus would be available via a myMapViewController.View.mapView or something similar. Here, however, to get access to our map from code, we need to create an outlet. Returning to Xcode, we click our MKMapView instance once to focus it and then open the Assistant Editor (new in Xcode 4):

This causes XCode to change into a split-view where you see your view and your ViewController’s Objective-C interface declaration at the same time.

Using this layout, we can now CTRL-drag (or right-click-drag) our MapView into our interface declaration, thus creating an outlet:

An XCode outlet will end up as an accessible property in C# once we return to MonoDevelop.

Back in MonoDevelop, open your MapViewController and navigate to its ViewDidLoad-method. Here, after the call to base, reference your map instance and – it’s just C#, baby! Subscribe to the map’s DidUpdateUserLocation-event, calculate an appropriate visible region and go:

To recap: We design our user interface in Xcode, but to get a hold of the views we are laying out, we need to create outlets, which then will make properties available in our C# code. Our solution currently looks like this:

Now, for the navigation options. Instead of loading view directly onto our window, let’s utilise a UINavigationController to … control the navigation! In our AppDelegate, replace the reference to our MapViewController with a reference to UINavigationController and instead of adding our default (or root) controller’s View to the window, simply set the window’s RootViewController:

Running our app now, produces the following result:

To add the navigation buttons, we return to XCode by double-clicking on the MapViewController.xib. We want to add some sort of button, so we filter our Object Library by button, finding Bar Button Item:

Drag two of those onto the XCode’s dock, being the gray vertical bar to the left of the design view:

In the Attributes inspector (remember? Top-right), set the title of the two buttons and customise them to your liking:

Again, to get access to the button instances from code – so we can add them to our NavigationBar (more on that later) – we will have to create outlets for them. In Xcode, show the Assistant Editor by pressing option+command+return and right-drag the two buttons to the code, generating the following snippet:

However, we are not only interested in the instances themselves, but also one of their touch events, so we’ll demonstrate adding that using Xcode as well. Right-click on the top-most button in Xcode’s dock and under Sent Actions, click-and-drag from the empty circle to the code view on the right:

Give it a friendly name (demoButtonTapped, for example), and do the exact same thing with the settings button:

Being done with the Xcode for now, we can return to MonoDevelop to wire up the buttons to the UI. In our MapViewController.cs-file, after the point where we wired-up our map’s DidUpdateUseLocation-event, add the following code to add the buttons to their navigation controller:

So far, so good. However, clicking the buttons does nothing at the moment, since we have yet to handle their events. We *could* have wired up their events as we are used to:

… but as I am sure you remember, we already created action outlets for these in Xcode, so let’s use those instead:

When we created our action outlets in Xcode, MonoDevelop automatically connected those to partial implementations which we can choose to implement ourselves. Both ways work fine.

The SettingsViewController in this case is based on the MonoDialog assembly, which you can read more of here or sit back and enjoy here.

That’s the song and dance of working with XCode!


 Scroll to top