Monotouch and iOS Storyboard limitations

Recently I’ve been doing MonoTouch research for iOS development.  While doing so I ran into a limitation when using MonoTouch and the new iOS Storyboards.  What I’ve found is that in general, MonoTouch and Storyboards play along really well together.  However, I found they only play nicely if you don’t need to create any custom controls that manage ViewControllers and navigation.  If you are just creating a simple application that has very straightforward navigation and uses only the standard iOS controls or subclassed controls, Storyboards are the way to go.  If you decide that you want custom controls that manage ViewControllers and want finer control over navigation, Storyboards are not for you.  What brought this about was I decided I wanted a neat UITabBar that would have an action button in the middle (similar to Instagram and other photo sharing applications).  I quickly realized this isn’t possible by subclassing the UITabBar without a lot of hackish techniques.  I decided I was going to create my own UITabBar.  In order to do this I needed to create a custom view to act as the tab bar and to manage the active ViewController.  This meant instantiating and managing the ViewControllers in code.  Now here is where Storyboards fail.  The problem I ran into was that the code generated by MonoTouch for my ViewControllers did not contain the proper constructors/bindings needed to instantiate them from code nor could I wire them up myself.  MonoTouch had generated some code to bind the ViewControllers’ classes to the Storyboard but it doesn’t allow access to it.  Now, sure, I know I could create a method to open the xib and search for the resource to bind to but that seems nasty to me and kludgy.  I wanted nice clean binding between my code behind and my xibs.  I found that the way to have clean bindings and be able to dynamically instantiate and manage ViewControllers from code was to keep them separate in their independent xibs.  Going this route allowed me  to use those ViewControllers in both ways, via code and via Interface Builder.  In short, if you plan on using MonoTouch to create an app that needs to be able to instantiate and show ViewControllers via code, do not use Storyboards.  Otherwise, go for it because Storyboards really simplify navigation and also give you an overview of your application flow.

2 thoughts on “Monotouch and iOS Storyboard limitations

  1. Hello Bret,

    The trick to be able to use Xcode to define your storyboard with your controls is to change the “Class” for the UITabBarController in Xcode to a custom name. When you save this, MonoDevelop will automatically create a stub class for you that will contain the proper constructors, like this:

    In this case, I changed the default which was “UITabBarController” to “MyViewController”, and I repeated that with the UITabBar, and renamed that to “MyTabBar”, this is what MonoDevelop generated for me:

    I added the “Console.WriteLine (“foo”);” just to show the constructor being invoked.

    You are right in saying that storyboards do not have a great pipeline to develop with, in particular for reusable component. They tend to be a grab bag of all the stuff that you will need in your application. The good news is that behind the scenes Xcode or MonoDevelop will generate XIB files out of the main storyboard file.

    Now my sample has a problem, it reuses the default TabBarController sample, and although I can change the UITabBar class to a subclass, I can not really replace it with another class that does not implement the same interface as a UITabBar, and this is where things break.

    If you wanted to roll your own UI, with your own model that merely happens to look like a UITabBar, you would need to implement UIViewController Containment. It would work, but you would not get much in the way of designer support for it. You could lay the controllers on the screen as UIViewControllers and change the “Class” to your own, but you would not get any visual feedback on what it would actually look like.

    Hope this helps,

    • Hi Miguel,

      First off, I am extremely humbled and grateful for you taking the time to read and respond to my post. I mean it’s not everyday you get “The Man” to comment on a post of yours. In response to your comments, you, obviously, are correct about how to subclass existing view controllers, etc. However, what I was trying to do was exactly what you stated about rolling your own UITabBar control from scratch. Also, I was trying to create reusable components which, like you said, storyboards are not really suited for. I didn’t want to subclass the existing UITabBar and just draw or add a view on top of it as most posts around the net suggest. That, to me, seems ghetto. I wanted a real control that behaves like a control and is developed in a clean reusable manner. I believe, ultimately, that we’ve come to the same conclusion that storyboards are nifty but they are not suited for complex applications that want to create custom, reusable controls. MonoTouch itself isn’t the issue, it was the use of storyboards that I was trying to shed some light on. Once again, thank you for your response, it is much appreciated!

      PS: MonoTouch is freaking awesome, keep up the amazing work!


Leave a Reply

Your email address will not be published. Required fields are marked *