I'm building an app with an MKMapView as background, and I would like to have a "slide-up/down"-view, just like in Google Maps or Spotify (example.gif), that can be dismissed by dragging it down.
The 'slide-up/down-view' will hold quite a lot of info, including a UITableView, so I would probably like it to have its own ViewController, instead of just a UIView alone. What could be a good approach for this?
Is it possible "just" to add a childViewController/ContainerView and give it a UIPanGestureRecognizer? All help is appreciated!
These view controller transitions are, sigh, unfortunately very complicated to do but there are lots of good tutorials online about them. You are correct in putting the subview into its own view controller. There are several other moving parts required. Fully detailing them would be enough material to write a book on the topic, but the high level overview is this:
Chapter 1: The Container
Think of the view controller with the map view as view controller A. Think of the slide-up/down view as view controller B. We want to transition seamlessly from A to B (and B to A). Cocoa provides an API for doing this, but first you'll need a container view controller that contains both A and B as a child view controller. This could be a navigation controller or your own custom container controller.
Chapter 2: Noninteractive Custom Container View Controller Transition
Once you have the container view controller, code it up so that you can go from A to B and back by pressing a button. (Throw a debug button somewhere into your app.) So you tap a button and you go from A to B and then you tap it again to go from B to A. To do this, there are the noninteractive custom container view controller transition APIs (it's a mouthful). This will require implementing an animation controller and a transitioning delegate, as detailed in that excellent objc.io tutorial and its corresponding GitHub repository.
Chapter 3: Interactive Custom Container View Controller Transition
But, of course, you want users to swipe up and down to trigger the transition. This will take you into the world of interactive blah blah blah APIs, where you implement an interaction controller and connect it to a pan gesture recognizer. The corresponding GitHub repository to that blog post actually uses a pan gesture like you would. This is particularly finicky work, as you would want the transition to be canceled should the user decide to stop panning midway through, but all that is detailed in the code and article.
Chapter 4: View Sharing
I'm actually not sure what this is called. The problem here is that you want the Google Maps / Spotify look and feel where a part of view controller B's view actually is visible while you're in view controller A. And the pan gesture recognizer is attached to B's view so that when you slide it up, B's view gets bigger and bigger until the interactive animation finishes and you've transitioned from A to B. Is there a good tutorial on this? I haven't found one, but it's becoming more and more common as an iOS UX idiom.
I myself have a small demo project illustrating how to do this. What I do is I have a navigation controller as my container view controller. The navigation controller's root view controller is my home view controller (view controller A). In view controller, I have view controller B as a child. So that's navigation controller owns A owns B.
When the user taps on B, I push B onto the navigation stack, thus reparenting it. At that point, my noninteractive animation controller kicks in as a custom navigation controller push animation. And so it looks like B is smoothly transmogrifying from its small bounds to its larger bounds. (I recommend running the xcodeproj to see the effect as I have done a terrible job of describing it.)
This technique would work just as well for an interactive animation. As to whether it's the best technique, I think that's up for debate — there are lots of ways of doing what you see in the Google Maps and Spotify apps. Apple could certainly do a lot better job of documenting the APIs for complex, interactive animations.
I would caution you to avoid using Auto Layout until you have your animations tweaked and ready, as it doesn't really interact well with your animation controllers. Good ol' frame rectangle math is best here until you find your bearings. Auto Layout is magic and, as you might be able to tell from how exhaustingly long this answer is, there's already enough magic to go around.
See Also
Session 803 from WWDC 2015: Designing with Animation
Session 214 from WWDC 2014: View Controller Advancements
Session 218 from WWDC 2013: Custom Transitions Using View Controllers
You can click on the purple Apple logo in the top right of asciiwwdc.com pages to watch the videos of the talks or grab the PDFs from the Resources tabs. Some of the best documentation for iOS is locked up in these WWDC talks.
Related
(I have read other questions and answers on this topic, but most are very old and do not relate to iOS 9 or 10.)
The app design calls for the top half of the display to always contain the same content. (An image being edited by the user.)
The bottom half of the display needs a UITableView. When a UITableViewCell is tapped, the bottom section needs to transition to a new UIViewController with slide-on animation, similar to how UINavigationController push segues work.
Problem: only the bottom view needs to transition to the new view controller(s), and back again. The upper half of the view hierarchy needs to remain unaffected. For this reason, I can't place everything inside a UINavigationController, and I can't have a UINavigationBar at the top of the screen.
Question: what approach should I take in such a situation, where I need only one UIView hierarchy to transition in push-segue fashion, but not anything else? Thanks.
Edited with Solution
Solution follows, for those following along at home.
Yes, you can actually use a UINavigationController for the bottom half.
If you are using Storyboards, the easiest way to do this is to use a container view for each part of the screen which you then can embed a UIViewController in for the top part and a UINavigationController in for the bottom part. If you are doing this programmatically, just add the view controllers as child view controllers to your app's initial view controller (see this answer for more info) which is essentially what the Storyboard will do for you automatically when using a container view.
As a child view controller, the UINavigationController will act independently from the top UIViewController and should behave as expected.
I recommend the programatic approach for the following reasons:
It helps you understand the inner workings of child/parent view controllers much better which will likely save you a significant amount of debugging time down the line.
It makes adding/removing/swapping child view controllers as simple as a few lines of code. Trying to do this with Storyboards is notoriously hacky and cumbersome.
It's much easier to keep track of changes using GIT (most mid-size/larger companies actually prohibit Storyboards for this very reason)
If you want change in part of the screen you can use container view. For details refer Swift - How to link two view controllers into one container view and switch between them using segmented control?
You can use multiple view in one view controller and can give animation like push or pop to show or hide it.
Second approach is you can use Container View which will give exact effect like navigation stack.
I am subclassing UIApplication to intercept and display touches in my TouchDisplay view. I would like to extend the Application, Window, Delegate or Main ViewController in order to keep my TouchDisplay view on top of all other views. As my and most other applications work, views and controllers are added and removed all the time. I figure the correct answer will be able to deal with these additions and removals and stil keep the TouchDisplay view on top.
Thanks for your help,
Joe
Here are a few approaches you could take for this:
If you're targeting iOS 5+ and iPad only, you can make a top-level view controller which has two contained view controllers. The first would be a view controller for your "TouchDisplay" view. The second would be the application's normal root view controller. (i.e. your existing main view controller; you'll need to set definesPresentationContext to YES on this view controller) Since you're writing the container view controller, you can order those two subviews however you like. There is a WWDC 2011 Talk on view controller containment that goes into great detail about this. This is the most "correct" approach IMHO, because it gives you a view controller for your TouchDisplay view, handles rotation and generally plays nice with others. (This only works on iPad, because on iPhone a new modal view always covers the full screen.)
A more straight-forward approach is to simply add your TouchView to your existing top-level UIWindow as a subview with addSubview:. Most applications don't actually remove the top-level view controller or add new top-level ones; they just present other view controllers from it. A view you add in the top-level window will stay above those. Of course, your app may not follow this rule, in which case you might try option #3 instead. This has rotation gotchas (your view will not auto-rotate when the device rotates, so you need to do this yourself.) You could also force your view back to top, say, on a 1-second timer, if you are having issues with other things covering it. This is also not as nice as option #1 because you don't get a UIViewController, just a UIView.
The most extreme approach is that you can create another UIWindow and give it a higher window level, such as UIWindowLevelAlert and put your TouchDisplay view in that. You can then make the window background transparent, and it will stay above your normal app content. There are lots of gotchas here, especially about auto-rotation and which window is the keyWindow (which is why you should use #1 or #2 instead if you can).
After some time I was able to get my app working. I have made an easy to use overlay that shows touch feedback over your existing application.
You can download the project here:
https://github.com/megaplow/FingerTracks/tree/master/FingerTracks
Happy coding,
Joe
I want to handle transitions between two instances of the same view controller class, using pan gestures.
I've read almost every transitions can be handled by segues, but is it the same when using pan gestures?
Segues don't seem to be a good fit for this kind of transitions.
For the moment, I have a master view controller which instantiates to sub view controllers. The gesture related code resides in the master view controller.
It works well, but I believe there has to be a solution where all the controller management stuff is done in the storyboard.
What is the best place in my code to handle this kind of transitions?
It sounds to me like what you want is a UIPageViewController set up to scroll instead of page curl (That's a settable property) A page view controller would do all the work for you.
There is a sample app in the Xcode docs called PhotoScroller that shows how to set this up. It does lots of other stuff too, (pinch to zoom and image tiling) but you can ignore that.
If you can't get a UIPageViewController to give you the transition you want then you might need to build your own custom parent view controller class. Embedding a single child using a container VC and an embed segue is trivial. I haven't tried to embed multiple children in the same container yet. using embed segues yet. I've done transitions between child VCs using the "manual" parent/child VC calls that were added in iOS 5
I've found a really great article on the way to implement custom transitions with iOS 7, whether they're interactive or not: http://www.captechconsulting.com/blog/tyler-tillage/ios-7-tutorial-series-custom-navigation-transitions-more
It comes with a very detailed demo.
Animations should be classes implementing the UIViewControllerAnimatedTransitioning or UIViewControllerInteractiveTransitioning protocols.
The code using the gesture recognizer can reside in those classes.
The animation can then be returned in the following methods of your navigation controller delegate:
navigationController:animationControllerForOperation:fromViewController:toViewController:
navigationController:interactionControllerForAnimationController:
This way I can plug the animation to whatever controller I want to.
I hope it could help someone.
I am subclassing UIApplication to intercept and display touches in my TouchDisplay view. I would like to extend the Application, Window, Delegate or Main ViewController in order to keep my TouchDisplay view on top of all other views. As my and most other applications work, views and controllers are added and removed all the time. I figure the correct answer will be able to deal with these additions and removals and stil keep the TouchDisplay view on top.
Thanks for your help,
Joe
Here are a few approaches you could take for this:
If you're targeting iOS 5+ and iPad only, you can make a top-level view controller which has two contained view controllers. The first would be a view controller for your "TouchDisplay" view. The second would be the application's normal root view controller. (i.e. your existing main view controller; you'll need to set definesPresentationContext to YES on this view controller) Since you're writing the container view controller, you can order those two subviews however you like. There is a WWDC 2011 Talk on view controller containment that goes into great detail about this. This is the most "correct" approach IMHO, because it gives you a view controller for your TouchDisplay view, handles rotation and generally plays nice with others. (This only works on iPad, because on iPhone a new modal view always covers the full screen.)
A more straight-forward approach is to simply add your TouchView to your existing top-level UIWindow as a subview with addSubview:. Most applications don't actually remove the top-level view controller or add new top-level ones; they just present other view controllers from it. A view you add in the top-level window will stay above those. Of course, your app may not follow this rule, in which case you might try option #3 instead. This has rotation gotchas (your view will not auto-rotate when the device rotates, so you need to do this yourself.) You could also force your view back to top, say, on a 1-second timer, if you are having issues with other things covering it. This is also not as nice as option #1 because you don't get a UIViewController, just a UIView.
The most extreme approach is that you can create another UIWindow and give it a higher window level, such as UIWindowLevelAlert and put your TouchDisplay view in that. You can then make the window background transparent, and it will stay above your normal app content. There are lots of gotchas here, especially about auto-rotation and which window is the keyWindow (which is why you should use #1 or #2 instead if you can).
After some time I was able to get my app working. I have made an easy to use overlay that shows touch feedback over your existing application.
You can download the project here:
https://github.com/megaplow/FingerTracks/tree/master/FingerTracks
Happy coding,
Joe
I'm executing a segue like so;
[self performSegueWithIdentifier:#"showSecondView" sender:self];
But the behavior is that it will always "load" the new view rather than show the existing view if it was already loaded.
My question is, how can I keep a view in memory once I've loaded it, so that future segue calls will simply "show" the existing view?
Thanks
EDIT:
Here is my user interface design. It's essentially a custom side tabbar view controller with a UIView (the big gray block) where all of the subviews are placed.
The short answer is that iOS isn't well suited for that, but you might be able to do so. It depends.
The question is how is that view's controller represented in the view controller hierarchy. The standard options are pushViewController (a push segue) or presentViewController (a modal segue). You might be able to do a custom segue that takes advantage of view controller containment (see WWDC 2011 session 102), but I'd be surprised if that would be something you'd want to pursue. Usually when you hear people talking about the frustration of creating new views is a result of their wanting to return to some main view, but neglecting to popToRootViewController and instead having a segue back to that root scene.
A wholly theoretical (and probably impractical) answer that might come up is to use a singleton and do some slight of hand to transition views, but after watching WWDC 2011 session 102 on view controller containment in which they belabor the importance of keeping one's view hierarchy synchronized with the view controller hierarchy, so I don't think that makes sense.
I might be able to make a more meaningful suggestion if I understood your desired user interface. For 99% of apps, they are geared around pushing/popping views, presenting/dismissing modal views, or using some container (e.g. a tab bar container or some custom container) for jumping between sibling views. What is your user interface flow?