How should I chain viewcontrollers in xcode storyb

2019-07-23 16:21发布

I would like to chain view controllers in a xcode storyboard to achieve the following effect:

A -> B -> C -> D -> E -> B -> C -> D -> E -> B -> ...

where the above letters represent separate view controllers (full sized scenes). I want to have a horizontal slide segue from right to left as I go between views and I do not want or need the state for previous views to be preserved (i.e. no push or modal segue). I do need to transfer some state between views though.

Any suggestions on how to best achieve this either using the storyboard editor, code, or some combination of the two?

1条回答
萌系小妹纸
2楼-- · 2019-07-23 16:43

A couple of options leap out at me:

  1. The easiest solution with greatest backward-compatibility with older versions of iOS is to use navigation controller, keep a reference to view controller B somewhere, and then you can, at E, have some IBAction that does:

    [self.navigationController popToViewController:B animated:YES];
    

    In this model, all of the segues would be represented in the storyboard, except the one from E to B, for which you would use the above code in an IBAction (or whatever).

  2. If you can jettison iOS 5 compatibility, you can also use the unwind segue. In this scenario, all of the segues would be represented in the storyboard. But many of us are not yet willing to give up on iOS 5 compatibility, so maybe you wouldn't want to contemplate this solution. But if you did want to use an unwind segue, you would just define an unwind action in B, such as:

    - (IBAction)backToB:(UIStoryboardSegue *)segue
    {
        // if you need to do any UI update because we got an unwind segue
        // back to this controller, do that here
    }
    

    Once you have this unwind action in B, you'll suddenly have a new segue type called backToB (though, I'd suggest you give it a better name than that) presented to you in IB, and you can use this to go from E to B. Obviously all the other push segues would be represented in your storyboard as usual.

  3. If you really don't want to use a navigation controller, but don't need iOS 4 compatibility, you could also achieve this with view controller containment, where you have a parent custom container controller, ParentVC, and A through E would be child controllers. You can then have custom segues to transition through the sequence of child controllers.

  4. One final variation might be the following:

    BABCDE

    In this scenario, like option 1, you're just using navigation controller, when B is first loaded, it would programmatically immediate do the following in viewDidLoad

    [self presentViewController:A animated:NO];
    

    Although B is the root view controller, it would feel like A was. When A is done it would dismiss back to B, at which point you could do your standard B-C-D-E push segue progression, but because we made B the root controller, E can just do popToRootViewControllerAnimated to get back to B, and you don't need worry about keeping a pointer to B around. This model makes a lot of sense if A is a login controller or splash screen, or something somewhat out of the normal flow.

Of these, 1 is probably easiest, 2 might be considered the most elegant (though you lose iOS 5 and earlier support), 3 is an option if you don't mind writing a little more (someone complicated) code and memory use is critical, and 4, like 1, is pretty easy, but it's just a question of whether the flow makes sense for your app. Personally, I'd lean to option 1 or 4, depending upon what view controller A was. And if iOS 4 compatibility was needed, those two options would work with NIBs, too.

查看更多
登录 后发表回答