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?
A couple of options leap out at me:
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, atE
, have someIBAction
that does:In this model, all of the segues would be represented in the storyboard, except the one from
E
toB
, for which you would use the above code in anIBAction
(or whatever).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 inB
, such as:Once you have this unwind action in
B
, you'll suddenly have a new segue type calledbackToB
(though, I'd suggest you give it a better name than that) presented to you in IB, and you can use this to go fromE
toB
. Obviously all the other push segues would be represented in your storyboard as usual.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
, andA
throughE
would be child controllers. You can then have custom segues to transition through the sequence of child controllers.One final variation might be the following:
In this scenario, like option 1, you're just using navigation controller, when
B
is first loaded, it would programmatically immediate do the following inviewDidLoad
Although
B
is the root view controller, it would feel likeA
was. WhenA
is done it would dismiss back toB
, at which point you could do your standardB
-C
-D
-E
push segue progression, but because we madeB
the root controller,E
can just dopopToRootViewControllerAnimated
to get back toB
, and you don't need worry about keeping a pointer toB
around. This model makes a lot of sense ifA
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.