Storyboard SplitViewController example

  • I am very new to Xcode and iPad development. I am trying to do the following:

    I have an initial NavigationController and ViewController. I am trying to go from a button on the ViewController to a SplitViewController using Storyboards but I can't seem to get it to work. Does anyone have an example of how to do it? Or an example of how to hand code it?

    Thanks,
    Jamie
  • On Dec 24, 2011, at 7:13 PM, Jamie Daniel wrote:

    > I am very new to Xcode and iPad development. I am trying to do the following:
    >
    > I have an initial NavigationController and ViewController. I am trying to go from a button on the ViewController to a SplitViewController using Storyboards but I can't seem to get it to work. Does anyone have an example of how to do it? Or an example of how to hand code it?

    The iPad-Specific Controllers section of the View Controller Programming Guide for iOS specifically says:

    "A split view controller must always be the root of any interface you create. In other words, you must always install the view from a UISplitViewController object as the root view of your application’s window. The panes of your split-view interface may then contain navigation controllers, tab bar controllers, or any other type of view controller you need to implement your interface."

    This topic has come up here in the past, so you may want to search the archives.

    Also, you cross-posted to the Xcode mailing list. This would be off-topic there so I removed it in this reply.
  • On Dec 25, 2011, at 12:00 PM, <cocoa-dev-request...> wrote:

    > I am very new to Xcode and iPad development. I am trying to do the following:
    >
    > I have an initial NavigationController and ViewController. I am trying to go from a button on the ViewController to a SplitViewController using Storyboards but I can't seem to get it to work. Does anyone have an example of how to do it? Or an example of how to hand code it?

    First of all you need speak accurately. There is no such thing as a NavigationController or a ViewController, and if you mean UIViewController there's no such as a button on one since a UIViewController is not a UIView. And then "go from" doesn't mean much either. Do you mean you want to draw a connection? Or that you'd like the user to be able to tap the button and cause a split view to appear?

    I'd avoid storyboards if I were you; they actually just make your life more complicated. And I'd avoid UISplitViewController! They are poorly written and rather inflexible. On iOS 5 if you want to split the view into two, you can easily do better than UISplitViewController, because you're now allowed to write your own container / parent view controllers. Here's an example modeled after the iOS 5 iPad Mail app:

    <https://github.com/mattneub/Programming-iOS-4-Book-Examples/blob/master/con
    vertedToIOS5/p560p575splitViewNoPopover/p560p575splitViewNoPopover/MySplitV
    iewController.m
    >

    m.
  • On Dec 26, 2011, at 4:18 AM, Matt Neuburg wrote:

    >
    > I'd avoid storyboards if I were you; they actually just make your life more complicated. And I'd avoid UISplitViewController! They are poorly written and rather inflexible. On iOS 5 if you want to split the view into two, you can easily do better than UISplitViewController, because you're now allowed to write your own container / parent view controllers. Here's an example modeled after the iOS 5 iPad Mail app:
    >
    > <https://github.com/mattneub/Programming-iOS-4-Book-Examples/blob/master/con
    vertedToIOS5/p560p575splitViewNoPopover/p560p575splitViewNoPopover/MySplitV
    iewController.m
    >

    I'll put one vote in defence of StoryBoards. I agree with many of the things you and Kyle have written about them recently, they don't feel finished and have some bugs, can be challenging to use on a small screen, may not be appropriate for large projects with many screens and the documentation is thin. But I do like the concept behind them and for simple apps they've allowed me to quickly hook up a framework for my concept, make sure the flow works properly, adjust it until it does, and then flesh it out. Perhaps if you're a good UI designer you can do that on a piece of paper, I am not a good UI designer at all and like to have a way to mock up the interface. I think also they fit nicely with iOS 5.0's improvements in UIViewController (especially containment which I think should have been there at the start) and are worth a look. I'm assuming Apple will continue to refine them and I keep filing bugs against them when I see them.

    Pet peeves of mine include the general bugginess (often making some kind of edit will cause all the view controllers and segues to disappear, requiring you to click on the list at the side to make them reappear, filed that one), my view that custom segues are only half thought-out and only half implemented, they should be called in both directions so the cute custom animation you write to put something on the screen can take it off again and the monolithic storyboard file is corruption waiting to happen in any shared project.  But I don't hate them and I have found a place for them in my workflow.
  • On Mon, 26 Dec 2011 09:07:33 +0800, Roland King <rols...> said:
    >
    > I'll put one vote in defence of StoryBoards

    I'm not saying they're completely bad; I do use them, especially for table view cells. But I think the overall design is just not finished; they should have spent less time coding and more time thinking. As I've said many times in public, the insight that the whole transition between view controller A and view controller B might be packaged up as an object (a segue) is potentially brilliant and might ultimate result in neater code. But it doesn't now, for many reasons (one of which, that you yourself grant, being the fact that you get no help whatever with the reverse of the segue).

    > I think also they fit nicely with iOS 5.0's improvements in UIViewController (especially containment

    But how can they, when they know nothing of your custom container controller??? If you're using custom container controller you *can't* use a storyboard.

    Indeed, it seems to me that just the opposite is true: the storyboard project doesn't "fit" at all - it feels like a skunkworks project that did a bunch of stuff without any communication to or from the rest of the company. It's totally gone its own way (else the table view cells stuff would have migrated back to the nib editor).

    m.

    --
    matt neuburg, phd = <matt...>, <http://www.apeth.net/matt/>
    A fool + a tool + an autorelease pool = cool!
    Programming iOS 4!
    http://www.apeth.net/matt/default.html#iosbook
  • On Dec 28, 2011, at 1:37 AM, Matt Neuburg wrote:

    > On Mon, 26 Dec 2011 09:07:33 +0800, Roland King <rols...> said:
    >>
    >> I'll put one vote in defence of StoryBoards
    >
    > I'm not saying they're completely bad; I do use them, especially for table view cells. But I think the overall design is just not finished; they should have spent less time coding and more time thinking. As I've said many times in public, the insight that the whole transition between view controller A and view controller B might be packaged up as an object (a segue) is potentially brilliant and might ultimate result in neater code. But it doesn't now, for many reasons (one of which, that you yourself grant, being the fact that you get no help whatever with the reverse of the segue).

    Full agreement - and the things you've said in public make lots of sense to me too, it's not finished and custom segues are currently half useless. I have filed a couple of radars with my comments on exactly that.

    >
    >> I think also they fit nicely with iOS 5.0's improvements in UIViewController (especially containment
    >
    > But how can they, when they know nothing of your custom container controller??? If you're using custom container controller you *can't* use a storyboard.
    >

    You can .. I do. You set the class of your view controller to be your custom container class and it you get one. What you can't do is storyboard the embedded viewcontrollers into it, you have to add them in code on creation. You can however set up those embedded view controllers in the same storyboard as standalone headless unconnected entities and instantiate them when you need and set them into your container controller. For the two cases I have thus far it's 2-3 lines of code in each. In both of those cases the entire container VC segues away to the next scene, I don't have anything like a split view controller where I want to change one pane during a segue, so I can still easily segue from the whole VC to the next. Limited, yes, much benefit gained from storyboard in that case, no, but it's not entirely orthogonal and when I have one such controller in an app with 30 .. doesn't really matter.

    It would be nice to be able to plug in to IB and tell it your custom controller is a container, in the way that the tab and splitview controllers were obviously hardcoded into the current IB .. given that you can't even write IB plugins for simple views anymore I fear that will not happen anytime soon and so yes, storyboarding will be limited with your custom VCs in the way IB is limited with your custom views.

    > Indeed, it seems to me that just the opposite is true: the storyboard project doesn't "fit" at all - it feels like a skunkworks project that did a bunch of stuff without any communication to or from the rest of the company. It's totally gone its own way (else the table view cells stuff would have migrated back to the nib editor).

    It fits, but, I feel like a lot of iOS 5, there were a load of new features slammed on the table and they all showed up a bit rough. Storyboarding is definitely a bit rough. ARC was awfully rough for the first few betas but got some serious love and is now very good. I really hope that storyboards, which capture 80-90% of the transitions people probably usually do, are improved to fit with the rest of the ideas in the release, I'd like the next n releases of Xcode to be more evolutionary than revolutionary and add more coherence for the new technologies.
  • On Dec 28, 2011, at 5:46 AM, Roland King wrote:

    > What you can't do is storyboard the embedded viewcontrollers into it, you have to add them in code on creation. You can however set up those embedded view controllers in the same storyboard as standalone headless unconnected entities and instantiate them when you need and set them into your container controller

    Yes, good point (and very well described). And this accords well with what others have said too - instead of one gigantic main storyboard for the whole app, a better approach might be multiple storyboards encapsulating short spurts of successive segues, as it were. (And of course, as I've said, I'm using storyboards as a source of UITableViewControllers, just to get the benefits of designing the prototype cell in same editor or of designing the whole table as static cells.)

    So, I think we agree, there's no point throwing out the baby with the bathwater. But I look forward to a better baby! :) m.

    --
    matt neuburg, phd = <matt...>, http://www.apeth.net/matt/
    pantes anthropoi tou eidenai oregontai phusei
    Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
    Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook
    RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
    TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
previous month december 2011 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Go to today