GroupMe is a good example. I want to implement something similar to this..
when you press the top left icon it'll bring you to the view on the left hand side, and when you click the right hand side of that view (the chats) it will bring you back
As the documentation says:
Use segues to define the flow of your app’s interface. A segue defines
a transition between two view controllers in your app’s storyboard
file. The starting point of a segue is the button, table row, or
gesture recognizer that initiates the segue. The end point of a segue
is the view controller you want to display. A segue always presents a
new view controller, but you can also use an unwind segue to dismiss a
view controller.
As said by Apple© segues are for changing View Controllers only and cannot be used to move single views. I suggest using animations to achieve the effect you are searching, however segues are definitely not what you are looking for. Maybe this question on stackoverflow.com may help you.
And please be sure to check for information by yourself first, I got this information in less than 5 minutes by searching on Google.com.
Regards -Jorge
Related
After creating ViewController informational pages which use UISwipeGesture to swipe left and right between 4 different UIViewControllers, I first selected "Modal" as the segue animation. But modal animation is contrary to the left/right swipes which should have "Show" segues which better match the user action. When changing the segue types in Interface Builder to "Show" the animations did not change. When de-selecting the "Animates" checkbox, XCode WILL eliminate the animation entirely, but then when selecting "Show" it goes right back to a modal segue animation.
Would show a picture of the set-up, but don't know how in StackOverflow
Tried embedding whole stack into a NavigationController and that didn't work.
Tried deleting segue and reforming it as "Show" from the getgo, that didn't work.
Shut down XCode and Simulator and restarted-- that didn't work.
Yet in another part of the same storyboard, "Show" segue works fine.
The problem was my segues were selected with Show Detail (replace) instead of Show (eg Push). When in interface builder you'll see you get presented with both of those as the top two selections. When using a UINavigationController, it expects Show (eg Push) to be selected which will put a Navigation header at the top of your UIViewControllers with a back button. In the case above, I'll simply write a short amount of code to hide the nav-header at the top of all my informational pages. I will keep the UIGestureControl left/right swipe code as a novelty item, but there are other ways to allow the user to swipe left and right to new pages (lookup PageViewControllers).
UINavigationControllers and Show (eg Push) animation go hand in hand, and you have to be wary of Apple UX/UI guidelines which protect the sanity of users before you go getting experimental with animations in segues.
Show (eg Push) arranges previous, current, and future ViewControllers like a stack of pancakes, so when you move from one to another you're pushing the top off like the top card of a deck of cards. Whereas Show Detail (Replace) acts like you're removing the card and replacing it with the next card. Best way to think of the difference between those two segues.
Not sure why compiler kept the modal segue after I changed it to Show Detail (replace)-- could be a bug with UINavigationControllers?
I'd like to know the best way to handle view controllers when there are multiple ways for the user to navigate through an app. The problem is that the user might (for example) trigger a segue by selecting a table row, Then, from the presented view controller they might click a button in a custom toolbar to go somewhere else.
I'm pretty new at this, so while I understand using a segue to present a view controller, and then having to dismiss the presented view controller at some point, I'm less clear on how to manage things when a user has free reign to go wherever they want! I'm using container views to embed a header and a custom toolbar at the bottom of each view. Should I be using a container for each view controller as well?
If you are quite down the stack and you don‘t want to offer a back button for simplicity, then you go up the stack by calling dismiss and tell the delegate where you want to go until you reach the appropriate level which can move you up until you are where you wanted to go.
The alternative is to move up the delegate chain until you can move down again and from there call dismiss and then go down where you want to go.
Up to now, there is a button in a view controller (let's call it Main View Controller). What I want is: if it satisfies a certain condition, when I press the button, the segue would lead to View Controller A; if not, when I press the button, it would lead to View Controller B.
But it seems that one button can only have one segue from it, so I wonder whether what I want is possible to be achieved in storyboard???
Thanks in advance!!!
If this question is too basic for you, I am so sorry. I am still a very starter in iOS programming.
You need to create a segue from the viewController itself to the destination. You can do this for each viewController and give them appropriate identifiers.
Then you hook up your button with an IBAction and decide which segue to perform
Custom transitions are fairly new to me. I had to incorporate them into the last project I worked on and ended up using both the UIViewControllerAnimatedTransitioning protocol and custom segues.
Custom segues seem a bit cleaner/friendly in that you can choose them in a storyboard and be done with it. However there doesn't seem to be as-friendly way to set up a back/pop segue. I've read about unwinding segues but I can't seem to find anything around tying one to the back button of a nav controller.
The UIViewControllerAnimatedTransitioning protocol approach has a bit more set up but allows you to specify both the entering and exit of the views.
In the case of my app not being able to pop back with my custom segues wasn't an issue because the flow of the app doesn't allow you to go back to the previous views. Most applications though require this thus a custom segue seems worthless unless you subclass UINavigationController and allow for custom popping segues.
Am I missing something because it seems UIViewControllerAnimatedTransitioning is the best approach to take for animations between view controllers. Why would I ever want to subclass UIStoryboardSegue?
I agree that there is a lack of documentation on unwind segues compared to other types of segues, but after you get the hang of them, they are pretty straightforward. My understanding is that segues (including unwind segues) is the way that Apple intends you to transition between view controllers. Even when you create custom segues, the regular unwind segues should still function.
In my own work, I have subclassed a UIStoryboardSegue to execute a custom animation when transitioning between segues. Using a widely known app as an example, when you tap the menu button in Uber's app, the map view controller moves down, and a table view controller appears. And when you a tap a row in the table, the new view controller slides in from the right, but the map view controller is still visible on the screen. And when you tap the map view controller, it returns to its original position. For some reason, I believe that Uber actually didn't implement segues at all, but just place view controllers on top of view controllers, but I have implemented something similar in my own app with custom segues. These segues are difficult to replicate with Apple's default segues, so I used custom ones.
If you are tying an unwind segue to a back button, then you will want to override the normal unwind that comes along with the default back button in the uinavigationcontroller. I have found it very difficult to customize that segue. I would recommend hiding the default back button that comes with the uinavigationcontroller, adding your own bar button, and tying this new button to an unwind segue. I know that this is annoying, considering the default back button has some added functionality, such as using the title from the previous view controller as its text when the title is short enough. Unfortunately though, I think Apple really wants to discourage you from customizing the default button and makes it difficult to alter. I have left out how to replace the default back button with the custom one, so let me know if you have trouble.
Anyway, to create the unwind segue, you must first create a method in the class (or parent class) of the uiviewcontroller you are unwinding to (not from).
- (IBAction) methodName:(UIStoryboardSegue *)segueName
You can change the methodName and segueName to whatever you like. Now go to your storyboard, and go to the scene containing the uiviewcontroller you are unwinding from. If you now ctrl drag from this uiviewcontroller (the yellow button on the left side of the bar at the top of the controller) to the exit button (the orange button on the right side of the same bar) you will now see a menu popping up that contains the methodName above. Click that method, and your unwind segue will now be created.
After you have created the unwind segue, you now see it in the outline on the left of the storyboard. If you click the segue, you can inspect it and give it an identifier.
Now to deal with tying it to the back button...
Again, viewing the uiviewcontroller you are unwinding from , if you control drag from the custom back button (not the default back button) in the storyboard to the class of this uiviewcontroller, an IBAction will be created for you tied to the button. In this method, add in:
[self performSegueWithIdentifier: segueIdentifier sender:nil];
where segueIdentiferis the identifier you gave the unwind segue above. Now when you tap the back button, the unwind segue will be executed. You can also do some animations or what not before the unwind segue is executed.
I have actually done some complicated custom unwind segues dealing with animating both the source and destination view controllers. If you can be more specific regarding how you would like the unwinding to look, I can try to help you out.
This app provides 6 screens of detail form input that are accessed through a master table view using a UINavigationController.
So the user starts are the master screen used as a menu, and drills down each of the detail view in turn. The depth of the tree is 2: at level 1, there is the master view (the menu). At level 2, there are all the 6 detail views.
Now, the most common workflow is to go through each of the 6 detail screens in turn, in a linear fashion. Having to go back to the menu each time is cumbersome at best.
I would therefore like to offer the user the possibility to go from one detail screen to the next or previous with a swipe gesture.
How can I do that?
I can set up 2 UIGestureRecognisers. No problem. I even linked them to a push segue, and it works, but this is not the behaviour I'd like: I want the depth to stay at 2. In other words, I would like the segues to replace not push the view at the top of the navigation stack.
What would be the best way?
Second: the views switch one the swipe gesture is over. I would rather have the animation start during the swipe, with the user having the opportunity to change her mind when watching the next/previous view partially appear, exactly as the photo app handled swiping from one photo to the next/previous.
Is that even possible?
Thanks for any insight.
It looks to me that you are looking for something like UIPageViewController with UIPageViewControllerTransitionStyleScroll.
You can segue to that UIPageViewController from your master tableView and add your 6 detail VC to it as pages.
Here is a tutorial on how to use a UIPageViewController in a storyboard.
Please note that this scroll style is only available on iOS6.0+.