When I first started working with iOS, the most difficult thing for me to grasp was the UI of the application. Not necessarily the widgets themselves, but implementing the MVC based navigation patterns and populating the UITableView – which is the staple of iOS data display and app navigation. You may have expected me to say Objective-C, well yes, that was a challenge, but I now have Xamarin.iOS to deal with that, and all my iOS code can be written in C#.
Even with Xamarin.iOS and C#, populating a UITableView can be a daunting task, fraught with delegates (the iOS kind), datasources, and callbacks. Implementing a UITableView is a very non-linear, boilerplate, coding task, and it needs to be done over and over again. What our developer minds really desire is a clean, linear, declarative way to implement an iOS UI. Enter MonoTouch.Dialog, part of the Xamarin.iOS toolset.
MonoTouch.Dialog (MT.D for short) is an abstraction on top of the not-so-simple iOS UITableView/UITableViewController API and its’ related controls and navigation patterns. To be brutally honest, I have known about MT.D for quite some time, but I ignored it, thinking it was only something that a beginner would need. I was an Objective-C developer after all! Who needs that! It was not until recently, while working with a customer, that I discovered I was wrong. MT.D is great for beginners, and also packs enough punch to do some serious UI work. All very simply, exactly as iOS want’s you to do it. In my opinion it is hands-down the easiest way to build an iOS UI.
Let’s get started:
You will first need to make sure that the MonoTouch.Dialog assembly is referenced in your project, as shown here:
MonoTouch.Dialog offers a few different ways to define and populate the UI, but today we will be looking at the Element API. The element API offers a bunch of C# classes that can be constructed and contained within each other (in IEnumerables) to represent the UI structure. One of the most impressive things about this is that the abstraction will also handle the default navigation pattern found on iOS – without any additional work.
Let’s take a look, I have added the following method in my AppDelegate, which will build a multi-screen, navigable UI, in a straightforward declarative fashion – with hardly any code:
In the code above we are using collection initializers to populate a UI hierarchy with Element classes. The RootElement is the top level of the UITableView, it is then filled with Section elements to represent each section in a grouped UITableView. Within Sections, we can add things like BooleanElement (UISwitch), CheckboxElement (pick list), StringElement (simple text), and many more. Another RootElement contained in a Section will result in a new screen, and all of the navigation is handled for you – provided you wrap this in a UINavigationController.
All we need to do now is place this RootElement hierarchy in the UI, with a very simple line of code in the FinishedLaunching method of the AppDelegate:
Here, we are creating a DialogViewController, part of MT.D, passing it a RootElement (returned from our method above), this will represent our entire RootElement declaration in a UITableViewController. We then pass that DialogViewController to an iOS UINavigationController, having this at the top-level will allow the MonoTouch.Dialog Elements to handle all of the default navigation for us. Believe it or not this is all the code we need. Without further adieu, here is what we get:
1. The main screen
4. If we tap on the RootElement (Skills Group) that we added in Line #21, we get a separate screen, allowing multiple selection (CheckboxElement) with back button navigation.
5. Finally, tapping on the simple StringElement we added in Line #38. We constructed the StringElement with a lambda where we can specify code to execute when the StringElement is tapped. All we have done here is popped up a simple UIAlertView, but we could easily do more.
Latest posts by Falafel Posts (see all)
- Matching Complex Query String Rewrite Rule in IIS - March 22, 2017
- Using Google Services in UWP C# Apps – Part 2 - February 7, 2017
- Using Google Services in UWP C# Apps – Part 1 - February 6, 2017
- Redis Caching in the Google Cloud Platform - February 3, 2017
- Entity Framework with Google Cloud SQL - February 2, 2017